A legacy cutover fails when the plan is "turn the old system off on Saturday and hope Monday is quiet." The system still takes orders, pays people, or answers customers. A rewrite that only exists in a branch does not replace it. You replace one path, prove it, then the next.
This is how we scope digital transformation when the current platform cannot simply be switched off. It sits next to what belongs in a SOW (the slices have to be testable) and weekly demos (you click the new path, not a migration slide). The work page describes the same shape as a representative pattern — phased, observable, your cloud account — not a named case study.
What a Big-Bang Weekend Actually Costs
The weekend cutover looks cheap on a Gantt chart: one date, one DNS flip, one celebration email. The invoice shows up later.
- A freeze that starts Thursday and ends "when we are sure"
- A rollback that was never rehearsed because the old database was already mutated
- A Monday where support cannot tell which system owns a record
- Engineers who spent the quarter building a parallel world instead of fixing the path that pages them
If nobody can name the first user journey that will move, you do not have a cutover plan. You have a rewrite project with a date on it.
Strangler: One Path at a Time
A strangler does not mean "new UI, old everything." It means a router in front of the behavior you are replacing:
- Pick a path with a clear start and end (view an order, submit a claim, run the nightly export).
- Send a slice of traffic — one tenant, one office, one percent — to the new implementation.
- Keep the old path as the fallback until the new one has survived a real week, including the failure you already know (timeout, empty state, permission denied).
- Only then delete the old code for that path.
Reads usually move before writes. Writes move before batch jobs that fan out to finance or a warehouse. Auth and the system of record move last, not first, unless identity is the actual constraint.
Do not "strangle" by copying the database every night and calling it progress. Two writers to two stores is how you invent a reconciliation team.
Dual-Run Rules
Dual-run is useful for a short window on one path. It is not a lifestyle.
| Rule | Why |
|---|---|
| One writer | The new path or the old path owns the mutation, not both |
| Compare outputs | Log mismatches with an id you can look up; do not only chart "percent match" |
| Cap the window | Dual-run without an end date becomes the architecture |
| Same identity | The user, tenant, and permission check are identical on both sides |
| Rehearse rollback | Flip the router back in staging before you need it in production |
If the new path cannot run beside the old one, say so in discovery. Some batch systems and some licensed monoliths do not dual-run cleanly. Then the slice is smaller: a read replica, a new edge API, or a single report — still not the whole estate in one night. Paid discovery is where that constraint should surface, not on Friday evening.
The Data Freeze Is a Decision, Not a Mood
A freeze means: these fields stop changing for a named interval, for a named population.
Write it down:
- Which tables or documents
- Which hours, in the company's time zone
- Who is allowed to break the freeze (and how that is audited)
- What happens to a transaction that arrives during the freeze — queue, reject, or old system only
"We'll be careful" is not a freeze. Support will still edit a record because a customer is on the phone. Give them a path that does not corrupt the move.
After the slice cuts over, the old store for that path becomes read-only or unused. Leaving it writable "just in case" is how the next incident writes to the wrong place.
What Belongs in the SOW
A cutover SOW is a list of paths, not a slogan about modernization.
- The journeys in order, with acceptance you can demo
- The router or feature flag, and who can flip it
- Observability on the new path before traffic moves (alarms you will actually read are a cousin of this: cost and errors both need an owner)
- The freeze window and the rollback drill
- What is explicitly not in this phase (the rest of the monolith)
Each slice should be small enough to show in a weekly demo. If the demo is "the migration framework," you have not cut anything over.
Cloud choice is a separate decision. Azure vs AWS for an SME still applies: one cloud, your account, no second provider as a side bet during the move.
FAQ
Can we rewrite it in a new stack and switch DNS once? Only if the system can be down, the data set is small, and you have restored a backup onto the new stack in a drill. Most systems that "cannot wait" also cannot be down. Slice them.
Is a strangler slower? The calendar to first production traffic is usually shorter. The calendar to "old system deleted" is longer, and that is the point. You are buying Mondays that look normal.
Who owns the data during the move? Name a system of record per entity in the SOW. If two teams both think they own the customer row, stop and fix that before you write a sync job.
The Bottom Line
Legacy cutover without a big-bang weekend means one path, one writer, a freeze you can explain, and a rollback you have already flipped. The old system stays up until the new path is boring.
A date on a slide is not a cutover. A journey you can demo is.
Planning a cutover that still has to take traffic? See digital transformation or get a free estimate.