How long does it take to move to a new recruitment CRM?
Vendors commonly quote six to twelve weeks for a basic implementation and three to six months for a complex one. Very little of that is moving data, which is usually a matter of days. Most of the time goes on configuration workshops, field mapping decisions and training, which is why the quote often arrives with a services invoice attached.
It is worth separating the two things that get bundled together. Exporting candidates, clients, contacts, notes, jobs and pipeline from one system and loading them into another is a technical task measured in hours or days. Deciding what the new system should look like, and teaching everyone to use it, is a project measured in weeks.
The second is where implementations stall, and it is not really a data problem. A configuration workshop asks an agency to specify its process in the abstract, before anyone has used the tool, which is the worst moment to be asking. Decisions get made that get revisited three months later.
The other thing that slows migrations is the state of the data. Every agency database has duplicates, half-filled records and columns that fit no standard field. Treating that as a cleanup project to complete before go-live is how a migration turns into a quarter.
The alternative is to do the mapping and the deduplication during the import rather than before it, and to let the system propose the mapping rather than asking the agency to specify it cold. The owner's time then goes on checking the proposal was read correctly, which is a review task rather than a workshop.
What drives how long a migration takes?
Raw record counts matter less than people expect. What stretches a migration is structure: how many places the data lives, how it is linked, and how much of it is in free text.
| Factor | Quicker when | Slower when |
|---|---|---|
| Source systems | One CRM holds everything | CRM plus spreadsheets, a separate BD tool and shared inboxes |
| Export format | A full database export with record IDs | Per-screen CSV downloads with links between records lost |
| CVs and files | Exported with a reference to their owner | A folder of files with names as the only clue |
| Custom fields | Few, used consistently | Dozens, half abandoned, meanings known only to one person |
| Activity history | Notes carry a date, author and linked record | Notes pasted into one long text field |
| Duplicates | Handled during the load | Treated as a clean-up project before anything moves |
| Decisions | One person signs off the mapping | Every consultant must agree every field |
What can you actually get out of your current CRM?
Find out before you give notice. Ask your current vendor, in writing, what a full export includes, what format it comes in, whether attachments and email history are included, whether there is a charge, and how long it takes to produce. The answers vary more than you would think, and some exports leave out exactly the history you care about.
As the data controller, your agency is responsible for the personal data in the system, and your contract with the vendor should cover how it is returned or deleted at the end. Read your notice period too: running out of contract before the export arrives is an avoidable way to lose access to your own database.
What usually gets lost in a migration?
Record counts can match perfectly while the useful part of the data quietly disappears. These are the things most worth checking by hand:
- Links between records: which candidate was submitted to which role at which client, and what happened.
- Who did what and when: notes and calls that arrive with today's date and the importer's name as author.
- Stage history on past roles, not just the stage each application ended at.
- CVs and documents attached to the right person, rather than dumped in a shared folder.
- Consent, source and privacy notice dates, which you need to show UK GDPR compliance.
- Placement details: start dates, fees, rates and rebate terms.
Should you clean the data before migrating or after?
Neither, if you can avoid it. Cleaning first delays the move by weeks and cleans data you might have dropped anyway. Cleaning after means living with the mess in a new system, where it is less familiar.
The quicker route is to decide what not to bring, then deduplicate and map as the data loads. Leave behind records with no contact details and no activity in years, and anything you no longer have a reason to hold under your retention policy. Migrating stale personal data only moves the compliance problem to a new address.
How do you migrate without stopping the desk?
Do a trial load of a real export into the new system first and have two or three consultants check records they know well. Fix the mapping, then pick a cut-over date. Take the final export at the end of a working day, load it, and have the team start in the new system the next morning. Anything added in the old system after the export needs a short catch-up load or a rule that nothing new goes into it.
Avoid long parallel running. Two live systems means two partial records for everything that happens in the overlap, which is how duplicates are born.
Where Vayora fits
Vayora imports CSV and Excel exports, proposes the field mapping itself for you to confirm, deduplicates candidates on email and LinkedIn profile as the rows load, brings CVs across as a zipped bundle, and lets you undo a whole import run. A free migration service connects to a supported old system through an authorised connection rather than a shared password. Past placements arrive as pipeline history, not as full placement records with fees.
Common questions
- Can we keep using our old CRM while we migrate?
- For the trial load, yes: nothing changes for the desk while the mapping is checked. For the real move, keep the overlap to a day or two. Anything entered in the old system after the final export must be brought across or re-entered, and the longer both systems are live, the more records end up split between them.
- Who owns our candidate data when we leave a CRM vendor?
- Your agency does, as the data controller; the vendor processes it on your behalf. How and in what format you get it back depends on your contract, so check the exit and data return terms before giving notice. Once you have a complete export and have checked it, ask the old vendor to confirm the data has been deleted.
- Do we need to tell candidates we have changed CRM?
- Usually not individually, if you are using their data for the same purposes as before. Do check your privacy notice: if it names your software providers or describes where data is stored, update it. You will also need a data processing agreement with the new vendor, as with any processor handling personal data for you under UK GDPR.
- What is the most common cause of a delayed migration?
- Decisions rather than data. Loading records is quick; agreeing what each old field means, which custom fields to keep and how to map stages takes far longer when it is done by committee. Give one person the authority to sign off the mapping, and let consultants check the result on records they know rather than debate it in the abstract.