Ask an agency owner why they are still on a system they complain about weekly and you will usually get the same answer. Not cost, not features. They will say some version of: we cannot face the migration.
It is a rational fear. Published guidance from the incumbents puts a basic setup at six to twelve weeks, and a complex multi-division configuration at three to six months. Independent migration services quote two to four weeks of preparation before anything moves at all, then another one to two weeks for the migration itself, with a bill somewhere between five and fifteen thousand dollars depending on how messy the data turns out to be.
Here is the part worth noticing. Almost none of that time is spent moving data.
Where the weeks actually go
Break a typical migration into its parts and the shape becomes obvious. There is an export, which takes minutes. There is an upload, which takes minutes. And then there is everything else:
- Field mapping. Someone sits with two spreadsheets and decides that Candidate Source in the old system corresponds to Origin in the new one, four hundred times.
- Data cleaning. Duplicates, dead records, three spellings of the same company, a decade of free-text where a picklist should have been.
- Configuration. The custom fields your desk depends on do not exist in the new system yet, so they have to be specified, created and mapped before a single row can land.
- Coordination. Test migration, review, sign-off, scheduled cut-over, usually on a weekend so the desk is not live while it happens.
Every one of those is a human deciding something. That is why migrations are quoted in weeks and billed as services: you are not buying data transfer, you are buying a person to make several thousand small decisions about your data.
Which decisions actually need a human
Not all of them, is the honest answer. Most field mapping is inferable. A column headed Mobile full of eleven-digit strings starting 07 is a mobile number, and it does not need a workshop to establish that. A column of values like Placed, Interviewing and Rejected is a pipeline stage. A model reading the header and a hundred rows underneath it can propose the mapping with high confidence and be right most of the time.
What genuinely needs you is the ambiguous remainder. A column headed Status containing values nobody outside your agency would recognise. Two candidate records with the same email and different names, where only you know which one is current. The custom field you invented in 2019 that encodes something specific about how your desk works.
So the useful design is not full automation. It is a system that proposes everything it can infer, shows you its reading, and asks about exactly the parts it cannot resolve. The work does not disappear. It collapses from a project with a statement of work into a review you click through.
The upload was never the slow part. The mapping meeting was.
The bit nobody mentions until month two
There is a second cost hiding behind the first one, and it is the reason so many migrations quietly fail: what comes across is usually not the whole desk.
Candidates and clients move, because they are the easy records to map. Notes, activity history and pipeline state are the ones that get dropped or deferred, and they are the ones that hold the actual context. A database of thirty thousand candidates with no record of which of them you spoke to, why you rejected them, or what the client said in feedback is a phone book. The relationship history is the asset, and it is the first thing a cheap migration loses.
Any honest assessment of a migration should ask what fraction of your desk arrives, not how fast the rows load. Candidates, clients, contacts, notes, jobs and pipeline should all come across, or you have moved your contact list and left your business behind.
What we did about it
Our import reads your export, proposes the mapping, and asks about the columns it cannot infer. Columns that match no standard field become real custom fields, proposed on screen and accepted with a click, so configuration stops being a separate phase. Duplicates merge on the way in. Six record types come across together, history included.
The throughput number, since people ask: thirty-five thousand candidates imported, parsed and deduped in under a minute on our infrastructure. We publish it, but it is close to the least interesting fact about a migration. Every system in this category can move rows quickly. What determines whether you are live in days or in months is how many decisions a person has to make on the way, and whether the product makes them or you do.
The remaining time is yours, and it is the part that should be yours: checking that the system read your desk correctly before you trust it with the desk.