Staged cutover: migrating a live CRM without stopping frontline services

Most migration plans assume a quiet weekend. Freeze the old system on Friday night, load everything, test on Sunday, everybody logs into the new one on Monday. That works fine for a sales team. It does not work for an organisation whose staff are in someone’s lounge room on Saturday morning doing a risk assessment, because there is no weekend when nothing happens. For those organisations, CRM migration without downtime is not a nice-to-have. It is the constraint the whole project has to be designed around, and a staged cutover is how you meet it.

I have done this once, properly: an Australian community-care provider moving from Salesforce NPSP to Nonprofit Cloud, delivered alongside the implementation partner. What follows is what that actually involved, including the parts nobody puts on a methodology slide.

Big-bang versus staged: the honest trade-off

A big-bang cutover is cheaper and shorter. One load sequence, one reconciliation, one training event, one support surge. You pay for it with an outage and with risk concentration — every unknown in the project resolves itself on the same night, in front of the same audience.

A staged cutover costs more and runs longer. You build the load pack once and then run it repeatedly. You reconcile after every step instead of once. You train in waves. You carry two systems in parallel for weeks. Anyone telling you a staged cutover is the cheap option has not run one.

What you buy is that nobody stops working. On the engagement above, staff moved in cohorts rather than all at once, and there was never a day where a support worker could not record a client session. Where an organisation serves vulnerable people, losing a day of access, or a day of history, has consequences that sit outside the project’s risk register entirely.

What a CRM migration without downtime actually requires

Three capabilities, and if you cannot build all three, do not promise a staged cutover.

Re-runnable loads. Every load has to be safe to run twice. That means external IDs on every migrated object, so loads are upserts rather than inserts. If your load creates duplicates when re-run, you do not have a staged cutover — you have one attempt and a prayer.

A defensible reconciliation. You need to prove, after each step, that what landed matches what left. Not a spot check: a count compared against the source extract, done before anyone signs anything.

A rehearsal environment. We rehearsed in a partial-copy sandbox before touching production. The first rehearsal is where you find out your sequence is wrong, your timings are optimistic, and one of your lookups resolves to nothing.

How to pick your cohorts

Cohorts should follow the way work actually flows, not the org chart. The test: within a cohort, people hand records to each other constantly; across cohorts, they barely do. Split along the wrong seam and you will spend the migration chasing half-finished work between two systems.

In practice that means one of three cuts:

• By team. Cleanest where teams own distinct caseloads end to end.
• By service line. Good where a program has its own intake, delivery and reporting, and touches other programs only at referral points.
• By geography. Useful for regionally structured providers, and you can put a person on the ground with each region as it goes live.

Sequence matters as much as the split. Go first with a cohort small enough to support properly and robust enough to tolerate a rough week — not your most fragile team, and not the one holding the messiest data. Save the highest-risk cohort for when the load pack has been run four times and the support pattern is known. On the community-care engagement, the aged-care navigation team went last, with a final delta load in September 2026.

Delta loads: the mechanic that makes it work

Between the moment you extract a cohort’s data and the moment they start working in the new system, the old system keeps accruing records. A delta load is the catch-up: everything created or changed in the source since the last extract, loaded on the same mappings.

These are not small. One delta on that engagement was around 3,500 records, covering client sessions, tasks, documents, check-ins and newly completed risk assessments. That is a normal fortnight of frontline activity, which is why the loads have to be routine rather than heroic.

Two rules make deltas survivable. First, external IDs everywhere, so a record already brought across is updated rather than duplicated when it reappears in a later delta. Second, the delta must use the same mapping and the same sequence as the original load — not a hand-built script written at 11pm by whoever is still awake. The moment your delta logic diverges from your main load, your reconciliation stops meaning anything. The field-level groundwork is covered in our NPSP data migration checklist.

Keeping two systems partially live without corrupting either

The rule to enforce, hard, is one writer per record. A migrated cohort writes in the new system only. An unmigrated cohort writes in the old system only. Reads can go both ways; writes cannot. The failure mode that will hurt you is a well-meaning staff member updating a client record in the old system after their cohort has moved. Take the write access away on go-live day; leave them read-only if history matters.

Shared reference data is the other exposure. Picklists, program definitions, service catalogues — pick one master, usually the new system, and stop maintaining the other. Diverging reference data will quietly poison every subsequent delta.

Freeze windows: what actually has to freeze

Staged does not mean nothing ever freezes. It means the freeze is narrow and applies only to the cohort moving. For the hours between final extract and cohort go-live, that cohort stops writing. Everyone else keeps working.

What must freeze: record creation and edits in the source for the objects in scope, and any automation or integration that writes to those objects. What does not: everything owned by other cohorts, reporting, and read access. Be specific about integrations — an overnight job that quietly writes to the source during a freeze window will hand you a variance you cannot explain at 2am.

Reconcile, then sign off, then move

Every load on that engagement was reconciled against the source extract before sign-off, and sign-off was a gate, not a formality. Counts by object, matched against the extract, with variances explained individually. A genuine exclusion is fine; an unexplained one is a stop.

The discipline that makes this work is refusing to start the next cohort while a variance from the last one is open. It is tempting, because the next cohort is booked and people have arranged their diaries. Resist it. Unresolved variances compound, and by cohort four nobody can tell which load introduced the problem.

Archive before you delete

Converted records were archived before anything was deleted. On that migration, 17,248 legacy tasks became Benefit Disbursement records — a genuine transformation, not a copy, and transformations are where subtle mapping errors hide. The archive is what lets you answer a question six months later about what a record looked like before conversion. Storage is cheap; an unanswerable question from a funder is not. Retire the old system when the last cohort has stopped consulting it, and not before. The cost shape of all this is set out in what Salesforce data migration really costs in Australia.

Training and the support load after each go-live

Cohort-by-cohort training is a real advantage, provided you use it. You train people days before they move, on their own data — and each round improves, because you have watched the previous cohort struggle and fixed the material.

Expect a support spike immediately after each go-live, and staff it. The issues that came back on that engagement were the ordinary ones: task visibility, record page layouts, and emergency contact details still living in a legacy field. All raised through the same channel, most fixed the same day. Same-day turnaround converts a nervous cohort into people who tell the next cohort it went fine. A backlog does the opposite, and it travels faster. The full sequence is written up in our NPSP to Nonprofit Cloud migration case study.

When big-bang is genuinely the better choice

Staged is not automatically right. Choose a big-bang cutover when the data volume is small enough to load and reconcile in one sitting, the user base is small enough to train and support in one event, and the organisation has real tolerance for downtime — a genuine quiet period, not a hopeful one. If you can be offline from Friday evening to Monday morning and nothing breaks for anyone who depends on you, take the simpler, cheaper path. Paying for a staged cutover you did not need is its own kind of failure.

The question to answer first is not which approach is best practice. It is what happens to the people you serve if this system is unavailable for 48 hours. Answer that honestly and the approach picks itself. How we work through that decision is set out in our method.

If you are weighing a live CRM migration and cannot take the outage, get in touch. A short conversation about your cohorts, your data volumes and your real downtime tolerance will tell you whether a staged cutover is worth what it costs.