Most of the worry in a system replacement goes to the build. Will it do what we need, will it be finished on time, will it cost what we were told. Those are fair questions, but in my experience they are not where these projects go wrong. A build is a known problem with known methods. The cutover is where a project that looked healthy for six months turns into a bad month for the whole company.
A cutover is the period when you stop running the business on the old system and start running it on the new one. That sounds like a technical event. In practice it is an operational decision with a technical component, and it belongs to the leadership of the business rather than to the engineering team.
If you are replacing a donation platform, a reconciliation process, a case management system, or an internal CRM that a dozen people touch every day, here is how I think about planning the switch.
Start with what breaks if this is wrong for a day
Before anyone picks a date, answer one question honestly. If the new system is wrong for a day, what happens?
For some systems the answer is that a few people are annoyed and you fix it Tuesday. For others, donations fail quietly, a payout file goes out with bad totals, or a regulator asks a question you cannot answer. Those are different projects, and they deserve different cutover plans, even when the software underneath looks similar.
I ask clients to sort their workflows into three buckets:
- Reversible
- A mistake can be corrected later with no outside consequence.
- Visible
- A mistake is noticed by a customer, donor, or partner, and it costs trust.
- Binding
- A mistake creates a financial or legal fact that is hard to undo. Money moved. A filing was made. A number was reported to someone who relies on it.
The binding workflows set the pace of the whole cutover. Everything else can follow them.
Three shapes a cutover can take
| Approach | What it looks like | When it fits | What it costs |
|---|---|---|---|
| All at once | Old system off Friday, new system on Monday, one source of truth from the first hour | Small operations, low binding risk, or a clean single domain | No fallback if something is wrong, and all the pressure lands on one weekend |
| Phased by function | One workflow moves at a time: intake first, then billing, then reporting | Most mid-sized operations with several distinct workflows | A stretch where data lives in two places and has to be kept in step |
| Parallel run | Both systems process the same real work and you compare the outputs before switching | Payments, reconciliation, payroll, grants, anything binding | The team does the work twice for the duration, so it has to be time-boxed |
Most organizations I work with land somewhere in the middle: phased by function, with a parallel run on the one piece that cannot be wrong.
Parallel running is expensive, so be specific about it
Parallel running means your team does the same work twice for a while. That is real cost and real fatigue, and it is why people skip it and then regret it.
The way to make it affordable is to be narrow. You do not parallel run the whole system. You parallel run the calculation you cannot afford to get wrong.
For a reconciliation process, that might be one month of settlement files pushed through both the old process and the new one, with every difference explained line by line. Not "the totals matched." Explained.
A difference nobody can account for is a finding, even when the totals happen to agree.
Set the exit condition before you start. How many cycles, what counts as a clean cycle, who signs off. Without that, parallel running never quite ends, because no one wants to be the person who called it.
Decide what moves, and be willing to leave things behind
The instinct is to bring everything. Every record, every note, every attachment, back to the beginning of the company.
That instinct costs more than people expect, because old data was created under old rules. Fields meant something different in 2015. Statuses existed that no longer exist. Records were entered by people who have long since left. Migrating all of it means either writing transformation logic for every historical exception or pouring a decade of mess into a clean system on day one.
A pattern that holds up:
- Move live records in full. Anything a human will act on next month: open cases, active donors, unreconciled transactions, current accounts. These have to be complete and correct.
- Move history in a reduced form. Usually what people need from history is the ability to answer a question, not to work the record. A read-only archive or a flattened, searchable export covers that at a fraction of the cost.
- Keep the old system readable for a defined period, and say out loud how long and who pays for it. That is a budget line, and it is the one that quietly gets forgotten.
Name the person who declares the new system authoritative
This step is the one most often missing, and it is free.
There has to be a moment, on a date, when a named person says: as of now, the new system is the record. Before that moment the old system is the record. After it, when the two disagree, the new one wins and the old one is a reference.
Without that declaration you get a slow, miserable middle period where half the team enters data in one place and half in the other, and nobody can answer a simple question because the answer depends on who you ask. I have seen that state last for months. It does more damage than a failed launch, because a failed launch is obvious and this is not.
Write it down. Date, name, what is in scope, what is still on the old system. One page is enough.
Rehearse it, more than once
Run the cutover before you run the cutover. Full sequence, on a copy, with the real steps in order and the real people doing them.
The first rehearsal always surfaces things a plan cannot: an export that takes nine hours instead of one, a permission nobody has, an integration whose credentials belong to a former employee, a report someone in finance built years ago that never came up in any meeting. Far better to find those on an ordinary Tuesday with nothing at stake.
Rehearse the rollback too. If you decide at hour four that this is not working, what exactly do you do, and who does it? If the answer is vague, you do not have a rollback. You have a hope.
The first two weeks after go-live are part of the plan
Go-live is not the end of the project. The two weeks after are when the exceptions arrive: the odd record, the workflow nobody described during discovery, the partner who sends a file in a format the old system quietly tolerated for years.
Plan for that window. Keep capacity on the team for fixes instead of starting the next thing. Give people one obvious place to report what looks wrong, and answer quickly. How you respond in those two weeks decides whether the team trusts the system for the next two years, and trust is much harder to win back than it is to keep.
A boring cutover is a successful one
A good cutover is boring. That is the whole goal. Boring comes from sequencing the risky parts first, proving out the numbers you cannot be wrong about, deciding in advance who calls it, and rehearsing until the day itself is just a checklist.
If you are looking at replacing a system your operation runs on and you are not sure how to sequence the switch, that is the kind of thing we work through in discovery. We map how the work actually moves today, exceptions included, before anyone commits to a date. You can start that conversation at songswift.com/start-with-discovery