ATS migration checklist: the agency control pack

An ATS migration is one of the few projects where a quiet week is a win. Nobody praises a switch that went smoothly. They only notice the one that lost a client’s shortlist or dropped two years of candidate notes.

That risk is real, but teams can control several common causes. Data may not be fully mapped. Nobody may own the cutover. No one may check the record counts on the other side.

This guide fixes that with a control pack, not a pep talk. It gives you the reusable artifacts an agency needs to run a migration against any target ATS: an entity and field map, keep-delete rules, a pilot sample, an owner matrix, acceptance tests, and clear rollback conditions. Work through it in order and the quiet week takes care of itself.

Start with your renewal date, not your go-live date

It is easy to plan backward from a launch date picked because it feels clean. That is the wrong anchor. Anchor to your current contract instead.

Find your renewal or notice date and count back. You want the new system live and tested with room to spare, not a scramble in the final week. Set the runway from your record volume, integration count, migration risk, and acceptance criteria rather than adopting a fixed duration.

Renewal timing also protects your leverage. If you export and cut over with weeks to go, you can walk away calmly if something is wrong. If you leave it to the last day, you are negotiating from a corner. Ask your current vendor two questions early: is there a fee to export your data, and in what format do they deliver it? The answers shape your whole timeline.

Avoid launching in a high-volume week. A cutover that lands on top of final interviews or an offer deadline turns a calm project into a crisis. Pick a quieter stretch, even if it means moving the date.

Build an entity and field inventory before anyone exports

Before a single file leaves the old system, list what you actually have. Migrations go wrong when teams export first and think later. The inventory is your map. It heads off nasty surprises halfway through.

Work through your data by entity. In a recruiting agency, the main ones are candidates, projects or jobs, companies or clients, contacts, deals or placements, and the notes, tasks, and attachments tied to each. For each entity, note the record count and the fields in use. Add anything custom your team built over the years.

A short inventory table keeps this honest:

Entity	Approx. records	Custom fields	Attachments	Migrate?
Candidates	count from old ATS	source, availability, salary	CVs, notes	documented need
Projects / jobs	count	client, fee, stage set	job specs	open + documented need
Companies / clients	count	terms, sector	contracts	documented need
Deals / placements	count	placement fee, start date	offer letters	documented reporting need
Notes, tasks, history	count	linked to above	files	keep for kept records

This inventory does two jobs. It tells you the true scope of the move, and it becomes the checklist you validate against later. Save it. You will compare against it on the other side.

Keep, archive, or delete: document the rule for every record

Not all data deserves a seat in the new system. Carrying it all across is costly. For some records, it is also a compliance risk. Decide the rules now, in writing. Then the export is a clean cut, not a snap call under pressure.

A three-way review can help. Keep a record only when it is still needed for a documented purpose and has a lawful basis. Consent is one possible basis, not the only one. Archive it only while that purpose, basis, and a set retention period remain valid. Consent may be withdrawn or expire. If no other lawful basis applies, erase the record securely instead of archiving it.

Consent and retention deserve real attention here. GDPR Articles 5, 6, and 17 cover storage limitation, lawful bases for processing, and erasure rights. A migration is a natural moment to review those requirements, since you are touching every record anyway.

Retention rules vary by country and by your legal basis. So check your own obligations rather than copying a generic number. And remember that a checklist does not make you compliant on its own. It just makes the compliant path easier to take.

If your database is messy, clean before you move. Moving duplicates and dead records into a new tool just relocates the problem and makes it harder to spot what is real. Our guide on how to clean your recruiting CRM walks through the audit and merge you should run first.

Map each field from your old ATS to the new one

Field mapping is a core part of the work. Standard fields are usually straightforward. Name, email, phone, and current company often have an obvious home. The effort is in the fields that do not line up.

Export a complete field list from your old ATS. Then decide where each one lands in the new system, field by field. Three cases come up again and again. A field has a direct match, so you map it. A field has no match, so you create a custom field for it or fold it into notes. A field is legacy clutter you agreed to drop, so you leave it behind on purpose.

Pay special attention to pipeline stages, tags, and custom fields, because these carry your agency’s own logic. If your old system used ten pipeline stages and the new one starts with five, decide the mapping before you load, not after. A modern ATS usually lets you define custom fields and pipeline stages that mirror how your desk actually works, which makes the mapping easier.

Record the map as a table so anyone on the team can read it:

Old ATS field	New ATS field	Type	Notes
Candidate status	Pipeline stage	select	remap 10 stages to your new set
Source	Custom field: source	select	keep values as-is
Owner	Owner	team member	match by email
Rate / salary	Custom field: salary	currency	confirm currency per record
Freeform notes	Notes	text	preserve timestamps if possible

Write it down before you load anything. A mapping held only in one person’s head is the fastest way to lose data in translation.

Clean duplicates and attachments before they multiply

Duplicates are bad in one system and worse across two. Say your old database has three versions of the same candidate. The migration will faithfully create three in the new one. Now your fresh start is already cluttered.

Merge before you export. Search by email, phone, and name to surface likely pairs, then merge rather than delete so you keep the richest record and fold in notes from both. A platform that deduplicates candidates on entry will also keep the cleaned data clean once it lands, instead of letting the mess creep back.

Attachments need their own check. Resumes, offer letters, and signed terms are easy to overlook because they live beside the record rather than inside it. Confirm your export includes files, not just their filenames, and confirm the new system accepts them at the volume you hold. Test with a handful before you trust the full load.

Preserve your LinkedIn Recruiter projects, notes, and history

Important recruiting context may sit outside the old ATS. LinkedIn Recruiter can hold projects, saved candidates, pipeline stages, and the notes your team wrote against each person. A migration that ignores this may leave useful context behind.

Plan for it deliberately. Decide which Recruiter projects matter, and check how the new platform brings them across. One detail matters most. The import must run under your own authorized Recruiter account, and it must respect LinkedIn’s rules and limits. No tool should promise to reach around a provider’s permissions or quotas. Be wary of any that claims to.

Leonar handles this with a scheduled backfill you trigger yourself. It imports your LinkedIn Recruiter project history into matching projects, including the project structure and Recruiter-side notes. Imports run on a daily schedule designed to respect LinkedIn provider limits. A larger history may therefore land across several days rather than in one burst. The result is that the context your recruiters built stays with them after the switch.

Run a pilot migration on a sample first

Never make the full load your first attempt. Run a pilot on a representative sample, check it against your acceptance criteria, and only then scale up. This gives you a controlled chance to find mapping or attachment issues before the full load.

Pick a sample that stresses the mapping. Size it from your record volume, integration count, risk, and acceptance criteria. Include records with custom fields, attachments, different pipeline stages, and at least one known edge case. Load them into the new system, ideally a staging or sandbox space if the vendor offers one.

Then inspect the sample against your field map. Did every field land where you intended? Did stages remap correctly? Did the CVs come through and open? Did owners and dates survive? Log every issue you find, fix the mapping, and run the sample again. Repeat until a clean pilot run produces zero surprises. Only then do you load the full database.

Decide whether to run both systems in parallel

A parallel run keeps the old ATS available, usually read-only, while your team works in the new one. It is a safety net: if something looks wrong, you still have a source of truth to check against. It is not free, though, because it can mean double data entry for a stretch.

The decision comes down to risk and volume. Higher stakes point to a parallel run: large databases, many integrations, or a busy desk that cannot afford a bad surprise. Lower stakes point to a clean cutover: a small, well-mapped database with a confident pilot behind it can often switch in one move.

If you run in parallel, keep the window short and dated. Set its length from your record volume, integration count, migration risk, and acceptance criteria. Agree the end date in advance. This stops the parallel run from quietly becoming permanent and defeating the purpose of the switch.

Assign a cutover owner matrix so nothing slips

Migrations fail in the gaps between people. The old vendor assumes the new vendor has it. The recruiter assumes the admin checked it. Nobody owns the final count. An owner matrix closes those gaps by naming a single person for each task.

Keep it simple and visible. One task, one owner, one backup:

Task	Owner	Backup
Data export from old ATS	CRM admin	Ops lead
Field map sign-off	Ops lead	Agency owner
Keep-delete decisions	Team leads	Ops lead
Pilot validation	CRM admin	Recruiter lead
LinkedIn history import	CRM admin	Ops lead
Cutover go / no-go	Agency owner	Ops lead
Post-migration acceptance tests	Ops lead	CRM admin

The point is not bureaucracy. It is that when a question comes up mid-cutover, everyone knows exactly whose call it is. Clear ownership reduces avoidable confusion on launch day.

Cutover day: the order that keeps desks working

Cutover is the moment you switch the team’s daily work to the new system. Done in the right order, it is calm. The order matters more than the speed.

Start with a final export from the old system, taken as close to the switch as practical so you capture the latest changes. Load it, run a fast reconciliation against your inventory, and confirm the headline counts match. Then point your team at the new tool, with the old one available read-only if you chose a parallel run.

Brief the team before, not during. Recruiters should know where their projects live, how the new pipeline stages map to the old ones, and who to ask when something looks off. Use a short walkthrough sized to the workflow changes, and confirm that the team can complete the key tasks. Keep a shared log open for early issues so nothing gets fixed twice or forgotten once.

Validate the migration with acceptance tests

A migration is not done when the data loads. It is done when you have proven the data is right. Acceptance tests turn “it looks fine” into “we checked, and it reconciles.”

Run two layers of checks. First, reconcile the counts. Candidates, projects, companies, and deals in the new system should match the old ones, minus whatever you dropped on purpose. A gap here means records were lost or filtered wrongly. You want to know that before sign-off, not after.

Second, spot-check a sample in the new interface. Size it from your record volume, integration count, risk, and acceptance criteria. For each selected record, confirm the fields and stage are correct. Check that the notes are present, the owner is set, and the attachments open.

Write your tests as plain pass-or-fail checks:

• Candidate count reconciles with the inventory, allowing for deliberate deletions.
• Project and company counts reconcile the same way.
• A sample of records shows correct fields, stages, owners, and dates.
• Resumes and attachments open and belong to the right person.
• LinkedIn Recruiter projects and notes appear where expected.
• No kept record has a blank owner or a broken stage.

If every check passes, you have earned your sign-off. If one fails, you have a specific, fixable problem rather than a vague worry.

Set rollback conditions and sign off before you commit

Before you cancel the old contract, agree what would send you back. Rollback conditions are the line you draw in advance, while you are calm. That way you are not making a snap call in the middle of a bad day.

Keep them concrete. A rollback is warranted in a few clear cases. Record counts do not reconcile and the gap is real data. A critical entity, such as active candidates or open roles, did not migrate correctly. Or attachments are missing at scale. Minor cosmetic issues are not rollback events; they are week-one fixes. The distinction matters, because rolling back over something small costs more than it saves.

Sign-off is the mirror of rollback. It is a short, explicit yes from a named owner, recorded once the acceptance tests pass. Only after sign-off do you decommission the old system and end the old contract. Keep the final export only for the period set in your retention schedule. Limit access to named owners, then delete the file securely when that period ends.

How Leonar fits an agency ATS migration

Leonar is an ATS and CRM in one platform built for recruitment agencies. The parts that matter for a migration are the ones that keep your data under your own control. There is no managed-migration service and no promise of a fixed timeline here, just workflows you run yourself.

On the data side, you import contacts and companies by CSV. You define the custom fields and pipeline stages that mirror your old setup. And you rely on built-in deduplication, so a clean import stays clean. On the LinkedIn side, the scheduled Recruiter backfill brings your project history, structure, and Recruiter-side notes across under your own authorized account, respecting provider limits. That combination covers the two data classes agencies most fear losing: their CRM records and their LinkedIn context.

If you are scoping a switch, the honest next step is to see whether the fit is real for your desk. Compare the workflows against your own field map, check the transparent per-seat pricing, and if it looks right, start a free trial and run your pilot sample through it. That is a far better test than any migration promise.

Your ATS migration checklist, in one line

A clean ATS migration is not luck. It is an inventory, a field map, documented retention rules, a pilot, an owner matrix, acceptance tests, and rollback conditions agreed in advance. Run those artifacts in order and the switch becomes the quiet week it should be.

Start with your renewal date, protect your LinkedIn history, and validate before you sign off. Apply the same documented schedule and access controls to the old export as to the personal data it contains. Delete the file securely when that period ends.

Frequently asked questions

Can we keep using our current ATS during the migration?

Usually yes. Keeping the old system read-only while your team works in the new one is called a parallel run. Set its length from your record volume, integration count, migration risk, and acceptance criteria. The trade-off is double data entry, so set a clear end date and close the old system only after the agreed checks pass.

Do we need to migrate everything, or just active records?

Rarely everything. Migrate only records that remain necessary for a documented purpose, have a lawful basis, and sit within your retention schedule. Consent is one possible basis, not the only one. Archive a record only while that purpose, basis, and retention period remain valid; otherwise erase it securely. Decide and document these rules before you export.

How do you map fields from the old ATS to the new one?

Export a full field list from the old system, then match each field to a home in the new one. Standard fields like name, email, and stage map cleanly. The work is in custom fields, tags, and pipeline stages, which rarely line up one to one. Where the new ATS has no matching field, create a custom field or fold the data into notes. Write the map down before you load anything.

How long should you run both systems in parallel?

Long enough to pass your acceptance criteria, short enough to limit double entry. Set the window from your record volume, integration count, and migration risk. Use it to run acceptance tests, confirm record counts, and let recruiters work real desks in the new tool. Set the end date in advance so the parallel run does not drift and defeat the point of switching.

What should you validate after an ATS migration?

Start with counts: candidates, projects, companies, and deals in the new system should reconcile with the old one, minus whatever you deliberately dropped. Then spot-check a sample of records for correct fields, stages, notes, and attachments. Confirm resumes open, LinkedIn links resolve, and no owner or stage is blank. Only sign off once counts reconcile and the sample passes.

Can you preserve LinkedIn Recruiter project history when you switch ATS?

You can, if the new platform imports it under your own authorized account. Leonar backfills your LinkedIn Recruiter project history into matching projects, including project structure and Recruiter-side notes, on a daily schedule designed to respect LinkedIn provider limits. That keeps the context your recruiters built inside Recruiter instead of leaving it behind when the ATS changes.