Can you switch to a new ATS in a weekend?
Yes, for a modest database with standard fields and no custom integrations: export Friday, clean Saturday, import and verify Sunday, go live Monday.
On this page
Yes, many teams can switch ATS in a weekend. It is realistic when three things are true: a candidate database in the thousands rather than the hundreds of thousands, standard fields, and no custom integrations to rebuild. The plan is export on Friday, clean on Saturday, import and verify on Sunday, then repoint job posts and email before Monday’s standup. The import itself takes minutes; what fills the weekend is cleaning data and deciding what not to bring.
When is a weekend switch realistic?
Honest sizing matters more than enthusiasm. A weekend cutover works when the move is mechanical: one source system, fields any ATS recognises, and integrations you can reconnect with a login rather than a developer.
| Factor | Fits in a weekend | Plan two to six weeks |
|---|---|---|
| Candidate database | Thousands to low tens of thousands, one system | Hundreds of thousands, or merging several sources |
| Fields | Standard: contact details, CVs, notes, stages | Dozens of custom objects and required fields |
| Integrations | Job boards and a mailbox you reconnect by signing in | Custom API work, HRIS sync, BI pipelines |
| Team | A handful of seats, one workflow | Multiple teams with different processes to align |
| Mid-flight hiring | A few live roles you can brief on Friday | Dozens of active pipelines and booked interviews |
If you land in the right column on two or more rows, do not force the weekend. Take the slower route in switching ATS: a practical checklist, which adds field mapping, a parallel-running period, and contract timing to the picture.
What does the Friday-to-Monday plan look like?
Friday afternoon. Take a full export from the old system: candidates with files, notes and interview feedback, jobs including closed ones with placements, and consent records. Then declare the old system read-only and tell the team. Anything that changes after the export needs a second pass on Sunday, so the freeze matters more than it feels like it should.
Saturday. Cleaning day, the real work. Deduplicate, fix broken email addresses, collapse the fourteen pipeline stages you accumulated into the seven you actually use, and apply the leave-behind rules below. Write the stage map down: one page, every old stage, where it lands.
Sunday. Import and verify. Run a dry run first if your new system offers one; Recruitifly’s importer always starts with a dry run, deduplicates by email on the way in, preserves original timestamps, and keeps a rollback in case something looks wrong. After the real import, check record counts against Friday’s export and open ten candidates you know well. If their notes and dates are right, they are probably right everywhere. The deeper craft of keeping history intact is its own topic, covered in how to migrate ATS data without losing history.
Sunday evening. Repoint the outside world: publish your live roles from the new system, switch the application links on your careers page, and connect the mailbox so replies land where the team now works.
What actually takes the time?
Not the technology. A full export takes an hour and an import runs in minutes. The weekend goes to two human jobs: cleaning and deciding.
Cleaning is duplicates, dead email addresses, half-filled records from a sourcing sprint two years ago, and stage names only one ex-colleague ever understood. Deciding is harder, because every old record triggers a small “but what if we need it” reflex. The fix is to decide by rule, not by record: agree thresholds once, on Saturday morning, and apply them mechanically. Teams that triage record by record are still triaging in week three.
What should you leave behind on purpose?
A migration is the rare moment when deleting feels free, so use it:
- Candidates past your retention period. Importing them recreates a GDPR liability you had already aged out, and re-importing anyone you previously erased undoes a deletion you were legally required to make. Import from a fresh export and let retention rules apply on arrival.
- Dead jobs. Keep closed roles that ended in placements, because they are your track record. Drop drafts and roles that fizzled without a hire.
- Unused custom fields. If a field is empty on most records, it was a wish, not a process. Do not rebuild it in the new system.
- Old reports and dashboards. They never transfer. Archive final exports in case of audits and rebuild the two reports you actually read.
Every row you leave behind is a row you never clean, never store, and never have to explain to a data protection authority.
The Monday morning checklist
Before the team starts working, confirm six things:
- Live jobs are published from the new system and visible on the boards you use.
- A test application you submit yourself arrives as a candidate.
- Email is connected and sends from the right addresses.
- Every team member can log in and find a candidate by name.
- The old system is read-only, with a calendar note for when the contract lapses.
- Anything that changed after Friday’s export is in: take a small delta export and import the stragglers.
If all six hold, you have switched. Expect a week of small questions, “where do I find this”, rather than a week of firefighting.
Does the tool you are moving to matter?
More than the tool you are leaving. Any mainstream system, whether you are coming from Workable, Recruitee, Teamtailor or a spreadsheet, will give you an export of some kind; what decides the weekend is how much the receiving system helps. Look for an importer with a dry run and rollback, deduplication by email, and a vendor that does not require an implementation project just to start, then check the day-one workflow against the features you actually use.
Recruitifly was built for exactly this kind of cutover. The published tiers carry no implementation fee and a 7-day trial, which is long enough to run the dry run and the real import before paying anything, and every tier includes unlimited jobs, so reposting all your roles on Monday costs nothing extra. After the move, the Fly assistant can draft the follow-up work, like outreach to candidates whose process continues in the new system, always proposing for your confirmation rather than acting on its own.
The honest footnote: Recruitifly is in private beta. If your weekend is coming up, talk to us and bring Friday’s export; the dry run will tell you by Saturday whether Monday is realistic.
Frequently asked questions
How long does an ATS migration really take?
A clean cutover for a small team takes a weekend: export Friday, clean Saturday, import and verify Sunday. Larger databases, heavily customised fields, or custom integrations stretch that to two to six weeks. Almost none of either timeline is the import itself, which usually runs in minutes; the time goes to cleaning data and getting people aligned.
What data should I not migrate to a new ATS?
Leave behind candidates past your GDPR retention period, draft and fizzled jobs that never produced a placement, custom fields nobody filled in, and old reports, which never transfer cleanly anyway. Migrating everything copies your mess into a clean system. A switch is the one moment deleting feels free, so set rules first and apply them before import.
Will I lose candidates when switching ATS?
Not if you verify. Names, emails and CVs survive almost any switch; the real risk is losing notes, original timestamps and stage history, which naive imports drop. Protect yourself with a full export before you cancel, a dry run that previews the result, a count check against that export after import, and spot checks on ten records you know well.
Can I run two ATS systems in parallel?
Yes, briefly. One to two weeks on a couple of live roles is enough to confirm applications arrive, email sends correctly, and the team can find what they need. For a weekend cutover, parallel running shrinks to keeping the old system read-only as a reference while the new one takes all live traffic from Monday.
Recruitifly Editorial
Editorial
Related reading
Adding LLM screening to your ATS without creating duplicate records
Layer LLM screening over your ATS without splitting your candidate data: one source of truth, stable ID sync, scores written back as fields, not copies.
Sourcing with adjacent job titles and skills
Searching one job title misses most of the market. A worked SRE example plus a repeatable method for mapping adjacent titles and skills for any role.
AI Act candidate disclosure: notice template
What to tell applicants when automated screening is used, under the EU AI Act and GDPR Articles 13, 14 and 22, plus a copy-paste disclosure notice template.
Want to see how this looks on your own data?
No hard promises. Just a straight conversation about exports, stages, and your current stack.
Contact us