ATS migration checklist: field mapping, retention dates, in-flight offers and cutover day
On this page
- What data has to move, and what can stay behind?
- Phase 1: inventory and decisions
- Phase 2: the field mapping sheet
- How do you carry over consent and retention dates?
- What happens to open requisitions and in-flight candidates?
- Phase 3: test migration and a short parallel run
- Cutover day checklist
- The post-migration audit
- Common mistakes
- Questions people ask
An ATS migration has six phases: inventory and cleanup, field mapping, a test migration, a short parallel run, cutover day, and a post-migration audit. The data most often lost or damaged is not the candidate record itself but what hangs off it: notes and attachments, stage history with original dates, consent and retention dates, open requisitions, and offers that are out when the switch happens. As of October 2026, records your policy or the law requires you to keep, such as US hiring records inside the one-year federal minimum (29 CFR 1602.14), must survive the move with their original dates, and records past their deletion date should be deleted before it.
Choosing the system comes first; our ATS RFP template covers that, including the export questions to ask before you sign. Cleaning the database before you move it is the ATS data hygiene checklist. This page is the move itself.
What data has to move, and what can stay behind?
| Data | Move? | Watch for |
|---|---|---|
| Candidates inside the retention period | Yes | Duplicates; merge before, not after |
| Applications and stage history | Yes, with original dates | Stage names that do not exist in the new system |
| Notes and scorecards | Yes | Author and date lost; formatting stripped |
| Attachments (resumes, offer letters) | Yes, or archived with a link | File size limits; files linked to the wrong person |
| Consent, privacy notice and retention dates | Yes, into dedicated fields | Import date overwriting the original dates |
| Open requisitions and job templates | Yes | Approval chains rebuilt by hand |
| Email templates and scorecard templates | Rebuild, do not import | Old merge fields that no longer exist |
| Records past their deletion date | No; delete under policy first | Unless under a legal hold |
| Agency: clients, contacts, job orders, placements, fees | Yes | Ownership windows and guarantee dates |
Phase 1: inventory and decisions
[ ] Record counts by object from the old system: candidates,
applications, jobs, notes, attachments, users, [clients, placements]
[ ] Written list of what moves, what is archived, what is deleted
[ ] Retention schedule applied: records past deletion date deleted and
logged before export
[ ] Legal holds listed (open charges, lawsuits, audits) and flagged
[ ] Full export requested from the old vendor: format, delivery date,
cost, what is excluded
[ ] Contract end date for the old system confirmed, with read-only
access after cutover if needed
[ ] Integrations to rebuild listed: HRIS, job boards, calendar, email,
single sign-on, background checks, [others]
[ ] Freeze date and cutover date agreed, away from peak hiring
[ ] Owner named for each phasePhase 2: the field mapping sheet
Every field in the export gets one row. Most migration problems trace back to a row nobody filled in.
FIELD MAPPING SHEET
Old object.field New object.field Transform rule Owner Tested
candidate.email candidate.email lowercase, trim [ ] [ ]
app.status app.stage map: "Phone Scrn" -> Screen [ ] [ ]
app.created app.applied_date keep original; no default [ ] [ ]
note.body note.body keep line breaks [ ] [ ]
note.author note.author former users -> "[name] (former)" [ ] [ ]
source source map to new source list [ ] [ ]
reject_reason reject_reason map to new reason list [ ] [ ]
consent_date custom.consent keep original [ ] [ ]
[ ] [ ] [ ] [ ] [ ]The traps that show up in almost every mapping:
- Picklists. Stages, sources and rejection reasons rarely match one to one. Map each old value to a new one in writing; never let the import create new values on the fly.
- Dates and time zones. Check the export's format and zone, especially for interview times.
- Former users. Notes written by people who have left need an author that is not "unknown", or the history becomes unreadable.
- Free text into structured fields. Do not try to parse years of notes into fields during the move; carry them as notes and structure new records going forward.
How do you carry over consent and retention dates?
This is the step most migrations get wrong without noticing. If the import date becomes each record's created date, every retention clock resets to the cutover day, and records are kept far longer than your policy says. Carry these as their own fields, with original values:
- original application date and last activity date;
- consent or privacy-notice date, and any consent expiry;
- deletion-due date, if your old system calculated one;
- legal hold flag, with the reason.
The rules behind those dates do not change with the software, as of October 2026: the one-year federal minimum and the until-final-disposition rule once a charge is filed (29 CFR 1602.14); two years for federal contractors with 150 or more employees and a contract of at least $150,000, including records of resume database searches (41 CFR 60-1.12); and for EU and UK candidates, data "kept ... for no longer than is necessary" (GDPR Art. 5(1)(e)). State minimums are listed in our candidate data retention policy template. This is general information, not legal advice.
What happens to open requisitions and in-flight candidates?
[ ] Freeze date: no new jobs opened in the old system after [date]
[ ] Candidates at offer or final stage: finish in old system, then
moved with outcome; owner: [name]
[ ] Earlier-stage candidates: moved with stage, notes, next step
[ ] Scheduled interviews in the cutover window: listed, owner named,
calendar invites checked to still work
[ ] Outstanding offers and background checks: listed with status
[ ] Candidate-facing emails paused for 24 hours around cutover so no
one gets a duplicate from both systems
[ ] Agency: open submittals, ownership windows and guarantee periods
carried with their datesFor agencies, the submission record is evidence in an ownership dispute; losing its date in a migration loses the argument. See how to avoid double submissions and candidate ownership disputes.
Phase 3: test migration and a short parallel run
- Test import a sample into a sandbox: a few hundred records chosen to include edge cases (long notes, many attachments, merged duplicates, former users, every stage).
- Check by hand 25 records against the old system, field by field. Fix the mapping, then repeat.
- Full test import and reconcile counts by object.
- Parallel run: a few days where the new system is live for a pilot team and the old one is read-only for them. Long parallel runs where both systems take new data create double entry and conflicts; keep it short.
Cutover day checklist
[ ] Old system set to read-only at [time]
[ ] Final delta export (records changed since the full test import)
[ ] Delta imported and counts reconciled
[ ] Integrations switched: job boards, careers page, HRIS, calendar,
single sign-on
[ ] Careers page apply links tested end to end
[ ] Candidate emails re-enabled from the new system
[ ] Every scheduled interview in the next 7 days checked
[ ] Users can log in; hiring managers see their jobs
[ ] Help channel staffed for the first weekThe post-migration audit
Day 1-7
[ ] Counts match by object (or differences explained in writing)
[ ] 50 random records checked against the archive
[ ] Every open job has its pipeline and owner
Day 30
[ ] Retention and deletion rules running on original dates
[ ] A test access request answered from the new system alone
[ ] Reports tie out against last quarter's numbers from the old one
[ ] Old system: export archived, access ended, vendor deletion
confirmed in writingCommon mistakes
| Mistake | What happens | Fix |
|---|---|---|
| Migrating everything "just in case" | Records past deletion date move into a new system | Apply the retention schedule before export |
| Import date as created date | All retention clocks reset | Original dates in dedicated fields |
| Merging duplicates after the move | Notes and history split across two records | Merge in the old system first |
| No owner for in-flight offers | A finalist hears nothing on cutover week | Named owner and a list |
| Old system switched off on day one | Nowhere to check a record that did not move | Read-only access for an agreed period |
Questions people ask
How long does an ATS migration take?
It depends on the number of records, how much history you move and how many integrations need rebuilding. The critical path is usually getting a complete export from the old vendor and agreeing the field mapping, not the import itself. Ask both vendors for a written estimate based on your record counts, and plan the cutover away from your busiest hiring weeks.
Should you migrate all historical candidate data to a new ATS?
No. Move what you are allowed and need to keep: records still inside your retention period, anything under a legal hold, and candidates you may contact again with a lawful basis. Records past their deletion date should be deleted under your retention policy before the move, not carried into a new system.
What happens to candidates who are mid-process during an ATS switch?
Pick a freeze date. Candidates at offer or final stage usually finish in the old system so nothing changes for them mid-decision; everyone earlier moves with their stage, notes and scheduled interviews. Scheduled interviews and outstanding offers need a named owner on cutover day so no candidate falls between systems.
Do retention periods restart when data moves to a new ATS?
They should not. If the import date becomes each record's created date, every retention clock silently resets and records are kept longer than your policy says. Carry the original application date, last activity date, consent date and any deletion-due date into dedicated fields, and check them in the post-migration audit.