Migration without downtime: how parallel running actually works
Parallel running means your old system stays live and primary while the new one runs alongside it, fed the same reality, with the two reconciled against each other daily: record counts, totals, spot checks. Cutover happens only when the comparison has been boring for long enough, the business decides when that is, and the old system stays available as a fallback afterwards. Done properly, downtime is not minimised; it is removed from the plan entirely.
Every owner of an old system carries the same picture of migration day: a weekend of pizza boxes, a 2am decision nobody is sure about, and Monday morning as a coin toss. That picture is why dying systems stay in production for a decade after everyone agrees they should go.
The picture describes a big-bang cutover, and big-bang cutovers deserve their reputation. Parallel running exists so you never hold that coin.
The method, plainly
- The old system stays primary. Nothing about the daily routine changes. Orders go in, invoices come out, the business trades. Whatever happens on the new side, today is safe.
- The new system runs alongside it, on the same reality. Data flows from the live system into the new one automatically. The new system processes it exactly as it will after cutover.
- The two are reconciled, daily, in writing. Record counts. Financial totals. Spot checks on individual records chosen to be awkward: the oldest account, the weirdest discount, the customer with three addresses. The output is a comparison report a non-technical owner can read.
- Disagreements are treated as treasure. Every mismatch is a piece of undocumented behaviour surfacing while it costs nothing, because the old system is still the system of record. It gets explained, fixed and re-checked, and the report goes green again.
- Cutover happens when the business says so. Not when the project plan says so. When the comparison has been boring for weeks and the people who own the risk are satisfied, the new system becomes primary, and the old one stays available, read-only, as a fallback.
Done this way, cutover is an anticlimax. That is the whole point. Anticlimaxes do not make the newsletter, which is why you mostly hear about the other kind of migration.
Why this beats the alternatives
| Approach | The bet you are making | When it goes wrong |
|---|---|---|
| Big-bang weekend cutover | Everything was tested, nothing was missed | Monday morning, in front of customers, with the old system already switched off |
| Long freeze and careful handover | The business can stop changing while you migrate | It cannot; the freeze breaks, scope drifts, the project eats a year |
| Parallel run | The new system must prove itself against live reality before it carries anything | Disagreements appear on a report, on a Tuesday, while the old system carries the load |
The honest cost of parallel running is that it is more engineering: the data bridge, the reconciliation tooling and the discipline of reading the report all take real work. You are paying to move risk from cutover day, where it is concentrated and expensive, into the build, where it is spread out and cheap. For a system a business cannot trade without, that trade buys itself.
What it asks of you
Not much, but not nothing. Someone on your side owns the comparison report and actually reads it. Staff give honest feedback on the new screens while the stakes are low, which is when honest feedback is easiest. And the business resists the temptation to cut over early just because the first fortnight looked clean; boring has to be earned for longer than that.
One more thing it asks: the old system must keep running, untouched, throughout. That is a feature. Nothing in this method requires you to bet the company on the new thing being right, because nothing gets switched off until the numbers have agreed, line by line, for as long as you want to watch them.
This is the method on every migration scoped here, regardless of platform: it is step three of how a rescue works, and the Rescue Roadmap prices it for your specific system. If a supplier proposes a migration without a parallel run, ask them which weekend they have picked for the coin toss.