Start with a small, inspectable move.
A migration should preserve the information your team needs to run hiring: the person, the role they applied to, the application’s current state, and who owns the next action. This kit gives you a starting structure to adapt before transferring real information.
- Synthetic candidate applicationsFive fictional applications, including one person applying to two roles. Reserved example.com email addresses.
- Field mapping worksheetSource columns, destination concepts, transformations, and acceptance checks.
- 30-day rollout scheduleWork packages, suggested owners, evidence, and release gates.
- Migration checklistAn editable plain-text checklist for preparation, pilot, cutover, and reconciliation.
All sample people, applications, and identifiers are synthetic. Adapt the worksheets locally. This page does not upload or process candidate files.
Choose a first dataset you can reconcile.
Begin with one active role and a small set of applications whose current state a recruiter can explain. Decide which columns are needed for the first workflow. Keep an untouched source copy and a written record of the rows included, excluded, or awaiting a decision.
The sample file uses five application rows for four fictional people. Candidate SYN-C001 appears twice because they applied to two jobs. Their candidate identifier is stable; each application has its own identifier and stage. Use that relationship to check whether your transfer method preserves one person with two distinct applications.
Do not bring across every historical note simply because it exists in the spreadsheet. Ask the owner to review what remains relevant, who should see it, and which records belong in the migration under your organisation’s data-handling process. Resolve those decisions before the cutover.
For TiLab Free, plan within two operators and five concurrent jobs. See what Free includes in the Free ATS guide. However large the spreadsheet, confirm the transfer method for its records before planning the cutover.
Map meanings before copying values.
The field map names destination concepts so it can work across systems. Replace those concepts with confirmed destination fields after you inspect your chosen transfer method. Do not rename columns and assume the result is import-ready.
| Source information | Decision to make | Acceptance check |
|---|---|---|
| Candidate and application IDs | Keep a stable crosswalk to the destination’s identifiers. | One person with two applications remains one person with two separate job histories. |
| Job reference | Map to a confirmed destination role. | Every application belongs to the intended job; unknown roles are held for review. |
| Application stage | Agree a stage map with the recruiter. | No unfamiliar label silently becomes an active or rejected stage. |
| Dates | Identify source format and time zone before conversion. | The destination shows the intended event date, including around midnight. |
| Owner | Map to a current authorised team member. | The owner can find the application and perform the expected next action. |
Handle exceptions explicitly. If an email is missing, do not fabricate one. If duplicate rows disagree, retain both in the working file until the record owner resolves them. If a stage is unclear, ask what work actually happened. Keep the explanation with the mapping decision.
Test with the synthetic file first. After the transfer, compare row counts, distinct candidate counts, job assignments, stage counts, and representative record details against the source. A successful upload message alone does not establish that the hiring record is correct.
A 30-day rollout with a decision at every stage.
This is a planning schedule for a small team, not a promised implementation time. Expand a stage when your data, access, or transfer method needs more work.
- Days 01–05
Inventory and define.
Name the owner, choose the first role, inventory source fields, and confirm the transfer method. Exit with an agreed scope and a protected source copy.
- Days 06–10
Map and rehearse.
Agree field and stage maps. Exercise synthetic records, multiple applications, missing values, and access roles. Resolve mapping gaps before a real pilot.
- Days 11–15
Run the small pilot.
With the appropriate internal approval, move the agreed pilot records. Reconcile counts and details; ask the future operators to perform a complete handover.
- Days 16–20
Train and prepare.
Document the working workflow and exceptions. Assign the cutover owner, agree a source-edit freeze, and rehearse the recovery plan.
- Days 21–25
Cut over and reconcile.
Transfer only the approved scope, validate the destination, and communicate where new work belongs. Keep unresolved exceptions visible.
- Days 26–30
Stabilise and review.
Review pending actions, fix mapping exceptions, and confirm ownership. Decide the source archive and retention process through your internal policy owner.
Before you call the move complete.
- Scope: the owner can identify every included role and application, and explain exclusions.
- Source: the original file is recoverable and later edits are accounted for.
- Identity: candidates and job-specific applications were reconciled separately.
- State: job, stage, dates, and next-action ownership match the agreed mapping.
- Access: intended operators can work; excluded users cannot reach the restricted records in your test.
- Workflow: a future operator has completed review, handover, and decision recording on the agreed sample.
- Recovery: the team knows when to pause, which system remains authoritative, and how to avoid duplicate communications.
- Sign-off: the business owner has accepted remaining exceptions and knows where new applications will be managed.
Keep the signed-off mapping and reconciliation notes with your operational documentation. If a future stage count looks wrong, this record makes it easier to distinguish a migration issue from a later process change.
You can print this page as a working guide or download the checklist to assign owners in your own tools.