// Recruitment Technology, Migrations
How to Survive a CRM Cutover Without Losing Two Weeks of Billing
Published: 02 November 2026,
9 min to read
The bottom line
Most migration plans cover the records and ignore the fortnight around them, where consultants work live roles in a system being taken apart. Cutover sequencing matters more than migration speed. Freeze new jobs in the current CRM and set dual entry rules the desk can follow, then publish a switch-off date before the first file is exported.
Where a data migration plan stops and a cutover plan begins
The data gets a project plan, a named owner, and a spreadsheet with tabs. The fortnight where consultants work live roles across two systems gets a message in a group chat. That gap is where billings disappear. It has little to do with the quality of your export.
A crm migration plan describes what happens to your records. A cutover plan describes what happens to your desk while those records are in transit. More than a hundred agencies have raised the same two weeks with us. The pattern barely changes between a 30-seat firm and a 300-seat one. The export lands clean, the mapping is signed off, and the month still comes in light.
Sequencing is the fix, and it costs nothing except decisions made early.
Why does a careful crm migration plan still cost you two weeks of billing?
Because the plan measures the data and not the desk. A migration project plan tracks record counts, field mapping, transformation, and QA passes. None of that tells a consultant where to log a call on the Wednesday of cutover week. That decision gets made forty times a day across your floor.
The failure is rarely dramatic. A CV goes out from the legacy CRM. The interview gets booked in the new one, and the placement lands in neither. Rebate dates slip because the deal history sits in a system nobody is updating. Consultants hedge by keeping their own notes somewhere safe. That is how an agency ends up with a spreadsheet one person understands and nobody is allowed to delete.
Reporting goes dark at the same moment, which is the part that costs management its grip. Pipeline numbers split across two sources. Nobody can say with confidence how many CVs went out last week. Atlas research found that 56.16% of agency recruiters describe their tech stack as functional but fragmented. During a cutover, every agency is briefly the most fragmented version of itself.
Duration is the compounding factor. McKinsey and Oxford found that longer projects overrun more often, with every additional year on an IT project increasing cost overruns by 15 percent. Agency cutovers run in weeks rather than years, but the direction holds. An overlap with no end date drifts, and every extra week adds records living in two places.
What should happen to live roles in your old CRM before cutover?
Freeze new job creation in the old CRM on a fixed date. Let the roles already running there finish where they started. The freeze line belongs on the job record, not the candidate record. Everything new opens in the new platform from that date, so the two systems divide by time rather than guesswork.
The timing needs honesty about your average time-to-fill. A role opened the day before the freeze will still be live three weeks later. The freeze has to land earlier than feels comfortable. Most agencies set it too late, then extend the overlap to protect the roles still open on switch-off day.
Your integration inventory needs the same fixed date. Job boards, LinkedIn seats, email sync, and the CV parser all point at the old system. Each one needs re-pointing on cutover day rather than whenever someone notices. An hour spent listing every integration your stack depends on saves a week of confusion.
Applicant flow deserves its own decision, because it does not pause for your project plan. Name the system that receives new applications from the freeze date. Keep applicant screening running there rather than in two queues at once.
How do dual entry rules protect data quality during the overlap?
They name the source of truth for each record type before anyone has to improvise. Dual entry is duplicated work, so keep it narrow and time-boxed rather than thorough. Two rules that hold beat ten that get abandoned in week one.
The split that works for most agencies is simple. Candidate activity goes into the new platform from day one. Job and placement records stay in the old CRM until the role closes or the migrated data lands. Notes, calls, emails, and new contacts go forward. Anything tied to a live deal stays put. Write it on one page, and say what happens when a consultant gets it wrong.
Discipline is the weak point rather than the logic. Atlas research found that 22.22% of agencies have defined processes that are followed inconsistently. A cutover week is where that gap shows up fastest. There is always one desk still logging calls in the old system after switch-off. Those records do not catch themselves up.
Dual entry survives a busy desk only when one side of it stops being manual. That is where an AI-powered recruitment platform changes the overlap. Atlas uses agentic AI to strip admin out of recruitment workflows. Calls and meetings reach the record through the AI note taker instead of being typed twice. The same discipline protects adoption later, which is why CRM adoption fails at so many agencies.
When should the switch-off date be published to the whole desk?
Before the export, not after staging sign-off. A date that lives only in the project team’s plan has no effect on the floor. Publishing it early turns an open-ended overlap into a finite one. It also gives consultants a reason to move their habits rather than wait.
A short cutover checklist, agreed in this order, covers most of what goes wrong:
Atlas handles the data side in a way that suits this sequence. Field mapping is reviewed and signed off in a migration dashboard before anything is transformed. Every table then runs through roughly 30 to 40 automated tests. Nothing reaches production until you approve it in a staging environment that behaves like the live system. Most enterprise CRM database migrations complete within two to three weeks.
The detail that matters most for sequencing is what happens at the end. If your team has already started working in Atlas, the migrated records merge cleanly into the live data they created. The desk never waits for history to land before it bills in the new system. Our ATS migration checklist covers the stages either side of this one.
- Freeze new job creation in the old CRM, dated and announced
- Confirm dual entry rules and the owner of each record type
- Re-point integrations, adverts, and inboxes on switch-off day
- Lock the old system to read-only, with a named exception process
Frequently asked questions (FAQs) on CRM cutover planning
Two to three weeks is a realistic overlap for most agencies, and shorter is better. The window needs to be long enough for live roles opened before the freeze to close. It also needs to be short enough that consultants do not settle into two systems. Set the end date first and build the schedule backward from it.
A migration plan covers the records: the export, the mapping, the transformation, and the QA that proves nothing was lost. A cutover plan covers the live work during that period. It names where a consultant logs a call and which system owns a live role. Both are needed, and the second is the one usually missing.
Either sequence works if the platform merges migrated records into live data rather than overwriting it. Many agencies start working in the new system first and let the historical data land behind them. That shortens the period where the desk is waiting. Confirm with your provider that a later merge will not create duplicates.
Some overlap is unavoidable while live roles finish in the old system. It should be narrowly defined rather than universal. Send new candidate activity to the new platform, and leave deal history where it sits until the role closes. Dual entry becomes a problem when nobody has written down which records belong where.
Make the old system read-only on the published switch-off date, with a named exception process for genuine cases. Access is the strongest lever, because habit beats training every time. Pair it with user training delivered close to go-live rather than weeks in advance.
Contract desks need their own line in the plan. Timesheets and invoicing run on a weekly cycle that will not pause. Most agencies run the contractor book to the end of a pay period in the old system. The cutover then lands on the period boundary. Agree that date with finance before the wider switch-off date is published.
The fortnight that decides how your migration gets remembered
A crm migration plan that stops at the data hands your desk the hardest two weeks of the year. The records will land either way. What decides the billing number is whether consultants knew where to work while those records moved.
A staged go-live is what makes the overlap survivable. Mapping is signed off before anything is transformed, and you approve the data in staging. The migrated records then merge into the work your team has already started in the new system. That is the shape Atlas builds its migration around, so nobody chooses between working the role and protecting the record.
If your switch is penciled in for this quarter, the cutover sequence is the part worth drafting first.
