You do not replace a legacy system in one weekend. The straight answer to "how do we replace this without downtime" is that you stop thinking of it as a replacement and start thinking of it as a migration in slices: the new system is built piece by piece alongside the old one, each piece proven on real traffic before the next begins, and the business keeps running the whole way through. The dramatic cutover, the weekend where everyone holds their breath and hopes the new system boots, is exactly the thing this approach removes.
This is not a new idea and it is not a trick. It is the standard way serious migrations are run when the system in question cannot afford to stop. What follows is how it actually works, what gets moved first, what it costs against the all-at-once rewrite, and how to tell whether your system is ready to move.
Why the big-bang rewrite keeps getting rejected
The pattern is familiar. A critical system ages. It gets slower, more expensive to host, and harder to change, until everyone is afraid to touch it. A full rewrite gets quoted, and rejected, and quoted again, and rejected again, for the same reason every time: nobody can afford the system being down while its replacement is built, and nobody believes the new one will do everything the old one did on the first day it goes live.
That fear is correct. A big-bang rewrite is all-or-nothing. You run the old system until a flag day, then switch the whole thing over at once. If anything is missing or broken at the switch, the business is down with no way back to the system that worked yesterday. Most big-bang rewrites that fail do not fail in the code. They fail at the cutover, when the new system meets real data and real load for the first time and the team discovers what the plan missed.
The alternative: migration in slices
Instead of replacing the whole system at once, you cut it into slices along its natural seams, a reporting module here, a billing path there, an admin tool, and rebuild one slice at a time on a modern stack. Each new slice goes live quietly, takes real traffic, and proves itself before the next one is started. The old system shrinks as the new one grows around it. Engineers have a name for this; the name is uglier than the idea. What matters is the property it gives you: at no point is the entire business riding on a switch that has never been tested.
Because the work is incremental, the plan can change as it goes. A slice that turns out harder than expected gets more time without holding up the rest. A priority that shifts mid-project reorders the queue. The all-at-once rewrite gives you one decision, made up front, that you live with for a year. The sliced migration gives you a decision at every phase boundary.
The two approaches diverge most where it matters: at the cutover and at the point of no return.
| Consideration | Big-bang rewrite | Sliced migration |
|---|---|---|
| How it goes live | One flag day, the whole system switched at once | One slice at a time, each proven on real traffic before the next |
| Downtime | A tense cutover where the business can go dark | None: old and new run side by side throughout |
| If something breaks | No way back to the system that worked yesterday | Routing flips back to the old path in minutes, nothing lost |
| When you decide | One decision up front you live with for a year | A decision at every phase boundary |
| When value arrives | All at the distant finish line | In instalments, each phase live and earning before the next |
| Cost shape | Committed up front against a promise | Spread across phases, tracking proven progress |
| Main failure mode | Fails at the cutover when new code meets real data and load | A slice runs harder than expected and gets more time |
Running old and new side by side
The mechanism that makes this safe is that both systems are live for a while. Data flows between them continuously, so either side holds the current truth at any moment. Traffic is routed one slice at a time: this function now answered by the new system, everything else still by the old. Every slice ships with a rollback. If the new path misbehaves, routing flips back to the old one in minutes, and nothing is lost because both sides were kept in sync the entire time.
This is the part that actually buys the no-downtime promise. The old system is not switched off when the new one arrives; it stays as the safety net until the new piece has earned its place under real load. Only then does it retire, one slice at a time, until there is nothing left of it.
The switchover should be the least eventful day of the project.
What gets migrated first?
Not the riskiest, scariest core. You start with a slice that is low-risk and high-learning: something real enough to prove the approach, contained enough that a problem is survivable. The first slice is as much about proving the migration machinery, the data sync, the routing, the rollback, the monitoring, as it is about the feature itself. Once that machinery is trusted, the harder slices follow using the same tooling, and the team is no longer guessing whether the method works.
The order is also chosen so that each phase pays for itself before the next begins: a lower hosting bill, a page that finally loads quickly, a manual workaround retired. Value arrives in instalments instead of waiting for one distant finish line, which is also what keeps the project funded and supported while it runs.
The switchover is meant to be boring
Because the system was migrated slice by slice, there is no single dramatic flag day at the end. The final switchover is a routing change on a quiet morning, flipping the last small piece, and most of the team only notices the system getting faster. If your migration plan still has a tense all-hands weekend scheduled at the finish, it has not actually removed the risk. It has renamed it.
What does a no-downtime migration cost?
A sliced migration is neither free nor instant, and it is worth being honest about the trade. For a mid-size system it typically runs over a quarter or two, sometimes longer for a large one, because it is deliberately incremental. It can also cost more in raw engineering hours than an idealised big-bang rewrite, because for a stretch you are running and syncing two systems at once rather than one.
What that premium buys is the removal of the cutover risk and the option to stop, reassess, or change direction at any phase boundary. Measured against a big-bang rewrite that fails, and a meaningful share of them do, the sliced migration is far cheaper, because the failure mode of big-bang is the business going dark with no way back. The spend is also spread across phases instead of committed up front, so the budget tracks proven progress rather than a promise. Expect a program measured in months, not weeks, paid in instalments, with each instalment tied to a piece that is already live.
How do you tell your stack is ready to move?
A few signs that the time has come: changes that used to take a day now take a week and everyone dreads them; hosting costs climb every year for a system that does less than it used to; the people who understood it are leaving or already gone; a framework or a vendor underneath it is going end of life. We expand on these warning signs in five signs your platform is quietly costing you money. None of these demand a rewrite tomorrow. They do mean the migration should be planned now, while it can still be done in slices on your own schedule, rather than later under the pressure of an outage or an end-of-support deadline.
Before starting, ask a firm five things: how the system will be sliced, what moves first and why, how data stays in sync across the two systems during the transition, what the rollback is for each phase, and what proof each phase has to pass before the next begins. A firm that answers those in plain language has done this before. One that promises a single clean cutover is selling you the exact risk you were trying to avoid.
Done this way, the replacement is an anticlimax on purpose. The system gets faster, the running costs drop, and the changes everyone used to schedule around fear become ordinary work. The engagement below is this pattern run end to end, on a system that could not be allowed to stop.
