How to Switch Recruiting CRM Without Losing Candidate Data

To switch recruiting CRM without losing candidate data, export everything before you give notice, confirm exactly which parts of your data your current system includes in an export, map the fields you care about to the new system before the import runs, and verify the result with a sample check rather than trusting it. The records that usually survive are candidates, clients and jobs. The ones at risk are notes, attachments, email history and custom fields, so those are where to concentrate.

Key takeaways

• Candidate and client records almost always transfer cleanly. The things that get lost are notes, attachments, activity history and custom fields, so check those specifically.

• Run a pre-export audit first: know what you have, what you actually need, and what your current system will and will not export.

• Export everything before you give notice, not after. Access can end with the contract, and a full export is your safety net.

• Verify the import with a sample check rather than assuming it worked. Pick 20 records across different types and confirm each field arrived.

• Keep your consent records and communication history intact for UK GDPR purposes; a migration does not reset your obligations to candidates.

Why agencies stay put, and why the fear is mostly misplaced

For a 3-to-10 seat UK agency, the database is the business. Years of conversations, notes on who is worth calling and who is not, the context that makes the next approach credible rather than cold.

So the fear of losing it is rational. What is not rational is the conclusion agencies draw from it, which is to stay on a system they have already decided is wrong.

The reality is that a well-run migration loses very little, and the parts that are genuinely at risk are known in advance. You can plan around them. What causes actual data loss is not the migration itself, it is going into one without checking what your current system exports and without verifying what arrived.

The rest of this article is the checklist for doing it properly.

Step 1: Audit what you actually have

Before touching an export button, work out what is in your system and what matters.

Record types. Candidates, clients, contacts, jobs, placements and applications are the standard set. List them and note roughly how many of each you hold.

The attached layer. This is where value hides: call notes, email history, CVs and documents, interview feedback, activity logs, and any custom fields your team built over the years. These are attached to records rather than being records themselves, which is exactly why they are the most likely to be left behind.

What you actually need. Not everything deserves to move. If you have 4,000 candidate records and 1,200 of them are five years stale with no contact detail, a migration is a reasonable moment to leave them. Decide deliberately rather than by accident.

Compliance records. Note where your consent records and communication history live. Under UK GDPR you need to keep track of the lawful basis on which you hold candidate data, and a change of system does not reset that. Those records need to move with everything else.

Step 2: Find out what your current system will export

This is the step most agencies skip, and it is the one that determines how much you keep.

Export capability varies enormously between recruiting systems. Some produce a complete package including notes and attachments. Others export the core records cleanly but treat notes as a separate export, or omit activity history entirely, or export attachments only through a different process.

Ask your current vendor directly, in writing, three questions. What exactly is included in a standard data export. Are notes, attachments and email history included, or do they need a separate request. Is there any charge for the export.

That last question matters. Some agencies report being charged to retrieve their own data on the way out. Whatever the answer, you want it before you give notice rather than after, because your negotiating position is stronger while you are still a paying customer.

If the answer to any of these is unclear, escalate until it is clear. An ambiguous answer here becomes missing data later.

Step 3: Export before you give notice

The sequence matters more than people expect.

Take your full export while your account is active and in good standing. Do not wait until notice is served, and certainly not until the final weeks of a contract, because access can end when the term does, and a support team helping a departing customer is rarely as fast as one helping a current one.

Store the export somewhere safe and keep it after the migration completes. It is your fallback if something turns out to be missing three weeks later, and it costs nothing to retain.

A practical note on format: request the most complete and open format available, usually CSV for records plus a separate archive for documents. Proprietary formats that only the original system can read are not a backup, they are a dependency.

Step 4: Map the fields before the import runs

Data loss at import is usually not dramatic. It is quiet: a field arrives in the wrong place, or does not arrive at all, and nobody notices for a month.

The fix is mapping. Before the import, agree which field in your export corresponds to which field in the new system. Standard fields (name, email, phone, current employer, job title) map without thought. The ones needing attention are:

• Custom fields. Anything your team built for your niche. These have no automatic equivalent and need a deliberate decision: recreate them in the new system, fold them into an existing field, or drop them.

• Status and stage values. Your pipeline stages may not match the new system's, so agree the translation rather than letting it default.

• Dates. Date formats differ, and a misread date field can silently reorder your entire activity history.

• Notes with structure. If your team followed a note-taking convention, say so, so the import preserves it rather than flattening everything into one text blob.

A good migration partner will ask you these questions unprompted. If nobody asks, ask them yourself.

Step 5: Verify with a sample, not a glance

When the import finishes, the temptation is to open the system, see thousands of records, and assume it worked. Resist that.

Take a structured sample of about 20 records and check each one properly. Choose deliberately across different types:

• Your oldest record, to confirm history survived.

• A record with a long note history, to confirm notes came across in full and in order.

• A record with attachments, to confirm documents are attached and open.

• A placed candidate, to confirm the placement history and any linked client record.

• A record using your custom fields, to confirm the mapping worked.

• A few ordinary recent records, as a baseline.

For each, check the fields you rely on daily. If all 20 are clean, the import is almost certainly sound. If two are wrong, you have found a pattern worth fixing before your team builds a month of work on top of it.

Also run a count check: does the number of records in the new system roughly match the export. A large gap is worth investigating before anyone starts working.

Step 6: Time the switch around your contract

The data side is only half the switch. The other half is the contract.

If you are on an annual term, find out when your cancellation notice window opens, since many recruiting CRM contracts require written notice well before the term ends. Missing that window usually means renewing by default for another year.

If you are mid-term, you have two realistic options. Wait until the notice window opens and time the migration to land just before the term ends. Or start on the new system now and accept an overlap, in which case ask your new vendor about a bridge rate covering the overlap months so you are not carrying two full subscriptions at once.

Either way, do the data work first. A migration completed while you still have access to the old system is far less stressful than one attempted after it is switched off.

What usually gets lost, and how to protect it

Four things account for most migration disappointment.

Call notes. Often stored separately from the candidate record and omitted unless specifically requested. Ask explicitly whether notes are in the export.

Email history. Frequently held in an integration with your mail provider rather than in the CRM itself, which means it may not be in the export at all. Check where it actually lives.

Attachments. CVs and documents usually export as a separate archive that has to be relinked to records during import. If nobody plans that step, the files arrive as an unattached folder.

Custom fields. No automatic equivalent in the new system, so they need explicit mapping or they vanish.

None of these are inevitable losses. They are all avoidable with one question each, asked before the export rather than after the import.

How Shortlists handles migration

Shortlists is a recruiting CRM built for 3-to-10 seat UK agencies, and migration is included rather than sold.

It is free, run by the Shortlists team rather than an external migration partner, which means one point of contact and no third party handling your candidate data. You send your export from your current system, a spreadsheet, or a contact list, and the team maps your fields, cleans duplicates, and runs the import. Most agencies are live within 48 hours.

The team will tell you exactly what to include in your export before you start, which is the step that protects notes, attachments and custom fields. Enrichment runs on import, so contact details are refreshed as records land.

That is the principle the whole product runs on: the software carries the admin so your team keeps the work that wins placements. AI takes the admin. The craft stays with you.

Once you are in, your data stays exportable at no charge, at any time. That matters beyond convenience: the reason this article exists is that leaving a system can be hard, and the honest position is to make sure the next move is always yours. Billing is month to month at $120 per user a month, so there is no annual term to plan around either. If you are still mid-contract elsewhere, you can use Shortlists at $40 per user a month until your existing contract ends, so the overlap does not mean paying twice. Shortlists is used by 55+ UK recruitment agencies. (See how migration works, the pricing page, and the candidate database.)

FAQ

Next steps

If you have decided your current system is not working, the data is not the reason to stay. Audit what you have, confirm what your vendor exports, take the export while your account is active, and verify the import with a proper sample.

Shortlists is built for 3-to-10 seat UK agencies, and used by 55+ of them.

• Try it free for 14 days and see how your data would sit in it.

• Book a Demo and we will map out your migration, including timing if you are mid-contract.

• See how free migration works, the pricing page, and the comparison against other recruiting CRMs.