How a parallel run works when you leave a platform

Every horror story about replacing a business system has the same shape: everything moved at once, over a weekend, and on Monday the business could not invoice. The lesson usually drawn is that migrations are dangerous. The better lesson is that big-bang cutovers are dangerous, and that they are avoidable.

What a parallel run actually is

For a defined scope — one department, one process — the new system runs against the old one on the same real inputs, at the same time, for a defined period. Both produce output. The output is compared. When it matches for long enough, the old one is switched off for that scope, and only that scope.

The old platform stays live throughout. Nobody is asked to trust the new system before it has demonstrated agreement with the system it replaces, on real data, under real load.

Choosing what goes first

The instinct is to start with the most painful area, because that is where the frustration is. The instinct is wrong. Start where the process is well understood, the data is clean, and the blast radius of being wrong is small — because the first phase is not really about that department. It is about establishing that the migration works, in front of an audience that has been told it will not.

• A clear scope boundary: this process, these users, this data.
• Well-understood rules, so a mismatch means a bug rather than a disagreement about policy.
• Enough volume to be a real test, and low enough stakes that a bad day is recoverable.
• Users who will report problems rather than work around them quietly.

The switch-off criteria, agreed in writing, in advance

This is the part most often skipped and the part that decides whether the parallel run ever ends. Before it starts, write down what agreement means: which figures must match, to what tolerance, over how many cycles. Without that, the parallel run becomes permanent — two systems maintained forever because nobody is willing to be the person who declares the new one ready.

What it costs

For the duration, you are paying for both. That is the honest cost of the approach, and it is why the phases are ordered so that the earliest ones deliver savings that fund the later ones. It is also why phases are kept short: a parallel run measured in weeks is a safety mechanism, and one measured in quarters is a failure to decide.

Why this changes the risk conversation

A phased exit converts an irreversible decision into a series of reversible ones. At every point before switch-off, the answer to "what if this does not work" is: you stop, and you are exactly where you were. That is a very different proposition to put in front of a board than a weekend cutover, and it is the reason the phasing matters more than any technical choice in the project.