Switching ATS: a practical checklist

Switching ATS safely comes down to five moves: export everything while you still have access to the old system, map fields and stages before importing, run both systems in parallel on a couple of live roles, cut over on a quiet day, and keep a rollback path until the new system has earned trust.

How do you export data from your current ATS?

Do this first, before you give notice on the contract, because access and goodwill both shrink after cancellation. Export:

1. Candidates with contact details, CVs, and attached files.
2. Notes, emails, and interview feedback, the history that makes records valuable.
3. Jobs, including closed ones, and their pipelines.
4. Consent records and deletion logs, which you must keep honoring in the new system.
5. Any reports or snapshots you may need for audits later.

Check the export format while you are at it: a full CSV-plus-files export or API access is what you want. If the self-serve export is partial, ask support for a complete data extract; your processing agreement almost certainly obliges the vendor to return your data, and most comply when asked plainly. Note your contract’s notice period and renewal date now, because badly timed switches pay for an extra quarter.

How do you map fields and pipeline stages?

Old and new systems never share a schema. Before importing anything, write a one-page mapping: every old field and stage, and where each lands.

The principle: never delete meaning during mapping. Where a stage has no equivalent, carry the original name along; Recruitifly’s importer keeps original stage names as tags, so nothing is silently lost. The data mechanics, deduplication, dry runs, and GDPR deletions are covered in how to migrate without losing data.

Should you run the old and new ATS in parallel?

Yes, but briefly and narrowly. Pick two or three live roles, run them end to end in the new system while everything else stays in the old one, and use that week or two to verify the things that matter: applications arrive, emails send from the right address, scheduling works, and the team can find what they need.

Resist the urge to run everything twice for a month. Double entry exhausts the team and produces two half-true databases. Parallel running answers one question, whether the new system works for you in production, and it should end the moment that question is answered.

What does a clean cutover look like?

1. Announce the cutover date and freeze changes in the old system from that morning.
2. Take a final delta export of everything that changed since the main migration.
3. Import the delta, then verify counts: candidates, jobs, and open applications should match across both systems.
4. Repoint your careers page, apply flows, and job board accounts at the new system.
5. Switch the old system to read-only and keep it through your notice period as a reference.

Cut over midweek, when people are around to notice problems, rather than before a weekend. Tell everyone who touches the pipeline, including hiring managers and any external agencies, which system is live from when, because the most common cutover incident is simply a note written in the wrong place.

What is a realistic rollback plan?

A rollback plan is what lets you cut over calmly, and it has three layers:

1. The old system stays read-only and paid through the notice period, so nothing is ever unreachable.
2. Your full export from step one is archived somewhere independent of either vendor.
3. The import itself is reversible. Recruitifly’s migration runs a dry run before committing and offers one-click rollback after, so a bad import is an undo, not an incident.

If you are still choosing the destination, the implementation timeline guide helps you plan the calendar, and the comparison pages for Greenhouse and Recruitee show how Recruitifly lines up feature by feature.

Recruitifly is in private beta, and migration is part of the product: one click, dry run first, rollback after. Talk to us if you want to rehearse your switch with your real data.