An ATS or recruiting CRM holds more than candidate profiles. It holds who spoke to whom, which client saw which resume, why someone was rejected and which placements are still in their guarantee period. When an ATS migration goes badly, recruiters do not just lose data. They lose the context that lets them pick up a relationship where they left it. This guide covers how to move between Bullhorn, Loxo, Recruit CRM, Greenhouse, Lever and Ashby without that happening.
Agency and in-house migrations are different
Agency systems like Bullhorn, Loxo and Recruit CRM sit on both sides of the market: candidates and clients. They carry client companies, contacts, job orders, submittals, placements and often billing details. In-house systems like Greenhouse, Lever and Ashby are built around jobs, applications, interview stages, scorecards and offers. Moving within one group is simpler than moving across. If you are going from an agency tool to an in-house ATS (or the reverse), expect some data to have no natural home and plan where it goes before you start.
What candidate history actually means
Before you export, list every type of record your recruiters rely on. A typical list:
- Candidate profiles and custom fields (skills, availability, rate or salary expectations, work authorization).
- Resumes and attachments, with the link to the right candidate.
- Notes and activity history, including call notes and who wrote them.
- Email history, which may live in the ATS or in a synced mailbox.
- Jobs, pipelines and stage history, with dates.
- Submittals, interviews, offers and placements (agency) or applications, scorecards and offers (in-house).
- Client companies and contacts (agency).
- Tags, hotlists, saved searches and talent pools.
- Consent and data retention fields.
Then ask each recruiting lead which of these they actually open week to week. That answer shapes what you move in full, what you move as read-only notes and what you archive as a file.
Step 1: Get a complete export
Getting data out of an ATS is often the slowest part of the project. Some vendors give you a full export through support, some through an API and some through both. Attachments are frequently a separate step from records. Ask your current vendor early:
- Does the export include notes, activities and attachments, or only core records?
- Are resume files delivered with an ID that links each file to its candidate?
- Is API access included on your plan, and what are the rate limits?
- How long does a full export take, and is there a cost or a contract notice period?
Step 2: Map stages, statuses and fields
Pipeline stages almost never match one to one. One firm has "Submitted to client" and "Client interview 1", another has a single "Client review" stage. Write the mapping down and get recruiters to agree on it, because historical reports depend on it.
| Old system | New system | Decision |
|---|---|---|
| Status: Placed | Placement record | Create placement with start date and fee fields |
| Stage: Client interview 1 and 2 | Stage: Client interview | Merge, keep original stage name in a note |
| Custom field: Notice period | Custom field: Availability | Convert free text to a date where possible |
| Hotlist: Senior Java London | Talent pool or tag | Recreate as a tag |
Also map users. Notes, activities and placements are tied to a recruiter. Create every user in the new system before import, including people who have left (as inactive users) if you want their history attributed correctly.
Step 3: Deduplicate and clean
Recruiting databases collect duplicates faster than most systems. The same candidate applies twice, gets sourced by two recruiters and is imported from an old spreadsheet. A migration is the best chance you will get to fix that.
- Match on email first, then phone, then LinkedIn URL, then name plus current company.
- Decide a merge rule before you run it. Keep the newest contact details, but keep all notes and history from both records.
- Review uncertain matches by hand. A wrong merge is worse than a duplicate.
- Drop or archive records that your retention policy says you should no longer hold.
Step 4: Run a full test migration
Import into a sandbox or trial account in dependency order: users, client companies and contacts, jobs, candidates, then applications or submittals, then notes, activities and attachments. Keep a map of every old ID to its new ID so later records can find their parents. Run the whole dataset, not a sample. Resume files in particular cause problems at scale: unusual formats, very large files and names that do not match the candidate.
Step 5: Verify with recruiters, not just counts
- Compare counts per record type between old and new. Every gap should have a reason.
- Ask each recruiter to pick five candidates they know well and check profile, resume, notes and pipeline history.
- Check a sample of placements or offers, including dates and fee or salary fields.
- Run a search the team uses daily and confirm the results make sense.
- Rebuild the core reports (placements per recruiter, time in stage) and compare with the old system.
Step 6: Cut over without stopping the desk
- Pick a cutover date away from month end and busy hiring periods.
- Freeze the old system, run a final delta import of anything changed since the test run.
- Reconnect the rest of the stack: job boards, sourcing tools, outreach tools, calendars and email sync.
- Keep the old ATS read-only for as long as your contract allows.
Reconnecting the stack is often where agencies find extra value. If candidates already move by hand between your sourcing tool, outreach tool and ATS, the migration is a good moment to fix that. We wrote about it in connecting your recruiting tool stack.
Pitfalls we see most often
- Resumes imported but not linked to the right candidate.
- Notes imported with the migration user as the author, so nobody knows who wrote what.
- Stage history collapsed into current status, which breaks time-to-fill reporting.
- Email sync turned on before import, creating new duplicates from inbox history.
- Consent and opt-out fields left behind, so candidates who asked not to be contacted get emailed again.
How Remqa handles ATS migrations
We move ATS and recruiting CRM data for agencies, RPO firms and in-house teams using the same process every time: map, test run, verify, cut over. Duplicates are merged, every file is linked to the right candidate and the old system stays read-only until you sign off. Once the data is in, our AI recruiting agents can take on sourcing, outreach and scheduling on top of the new system. See how we run ATS migrations, or start with the map of where recruiter hours go.