Both the old and the new system are running side by side. How do you decide the day you switch customers over, and what does rollback mean once you have?
6 min readUpdated 2026-08-15Target archetype: Big Tech, Enterprise Captive, Product Startup
0
Answer
Short answer
Write the entry criteria before the parallel run begins so the decision is a checklist rather than a mood, ramp through a stepped population with an abort condition at each step, and recognise that rollback stops meaning redeploy once the new system takes its first authoritative write.
Was this answer helpful?
Likely follow-ups
→The comparison shows a 0.2 per cent mismatch that you cannot explain. Does that block the flip, and what would change your answer?
→How long do you keep the ability to reverse, and what makes you finally give it up?
→Batch and end-of-period processing never ran during the parallel period. How do you prove those before cutover?
→How do you cut over a customer population that cannot be segmented, because every record touches every other?
The decision has to be a checklist written in advance
The failure mode is deciding by sentiment at the end of a long programme, when everybody is tired, the budget is spent and the parallel run has become an expense rather than a test. By that point any evidence can be read as sufficient, because the alternative is telling a sponsor the date is moving again. So the entry criteria are written before the parallel run begins, agreed by the people who will be under pressure later, and expressed as numbers rather than as adjectives.
The criteria that hold up are specific. The comparison mismatch rate is below a stated figure, with every remaining mismatch classified into a bucket that has an owner and a written disposition, so "we still see differences" cannot be used either to block indefinitely or to wave through. The new system has served the peak load pattern, not the average one, for a period long enough to include whatever the business cycle contains. Its error rate and latency at the tail are inside the old system's, measured on the same requests. Every batch, reconciliation and reporting job has run to completion against real volumes at least once. And the reversal procedure has been rehearsed in an environment with production-shaped data, by someone who will be awake on the night.
Adding one more criterion changes the character of the whole list: a stated maximum duration for the parallel run. Without it, the run becomes permanent, because there is always one more anomaly to chase and running both systems is the option that requires nobody to take responsibility. If the criteria cannot be met within the window, that is a finding to escalate rather than a reason to extend quietly.
Rollback stops meaning redeploy
This is the distinction that separates a strong answer, and it is about time rather than about mechanism. While the old system is still the writer of record and the new one is being shadowed, reversal is trivial: change a routing decision and the new system's state becomes irrelevant. Once you flip reads, customers see the new system's answers but the old system is still receiving the writes, so reversal is still a routing change — this is why the read flip and the write flip should be separate events, and why compressing them into one is the single most expensive shortcut available.
After the write flip, the new system holds writes that the old one does not. From that moment reversal means transporting those writes back into the old model, and that is a data-migration problem executed under incident pressure with a partially trained team. Three consequences follow and you should state all three. There has to be a reverse-transformation path, written and tested before the flip rather than improvised after it, or you do not have a rollback plan and should stop calling it one.
The window in which reversal is feasible shrinks as writes accumulate, so name the window explicitly — hours, or a day — and after it, the honest position is that you are going forward and the plan is remediation rather than reversal. And some writes are irreversible in the outside world regardless of what your database can do: money moved, a message sent to a customer, a filing submitted to a regulator. Those operations decide the shape of the whole cutover, because they cannot be replayed or unwound.
Ramp through a population you chose
Flipping everyone at once removes your ability to learn anything cheaply. Step through a population you selected for a reason, with an abort condition at every step, and make each step's routing change reversible with a single action that does not need a deployment.
Loading diagram…
The edge that matters is the one going back from the decision gate, and what makes it real is that it must be the same size of action as the step forward. If going forward is a configuration change and going back needs a release, you do not have a ramp, you have a series of one-way doors.
Choosing the population is a judgement with organisational weight rather than a technical one. The tempting first cohort is the smallest customers, on the grounds that they matter least, but they are frequently the ones whose usage is least representative, so you learn nothing about the cases that will hurt. The defensible approach is to pick early cohorts for coverage of the awkward paths, and to have told those customers they are early, which is a commercial conversation somebody has to have.
The cutover that could not be reversed
In April 2018, TSB cut over to a new core banking platform before it was ready, and customers were left with failing and incorrect access to their accounts for months rather than hours. The lesson is about the shape of the cutover rather than the code: there was no realistic way back once both sides had diverged, and the worst problems were only visible under full production load. A migration answer should say how the two systems run alongside each other, what proportion of traffic proves the new one, and what the reversal actually consists of.
Two specific habits follow from it. Prove under the load that actually breaks things, which for most businesses is not a busy Tuesday but the end of the month, the end of the quarter, or the day after a bank holiday when the queues have backed up. And treat "we can roll back" as a claim requiring evidence, in the form of a rehearsal with a date and a named person who performed it, rather than as an architectural property you have asserted in a document.
Who is allowed to stop it
Cutovers go wrong slowly at first, and the expensive minutes are the ones spent deciding whether this is bad enough. Fix that in advance by naming one person with the authority to revert without seeking approval, giving them the abort criteria in writing before the night, and ensuring the criteria are things they can observe from a dashboard rather than things they have to infer from Slack. Rehearse the revert so that using it is not a career risk, because a rollback path that has never been exercised will not be used by anyone who reasonably suspects it might make things worse.
Then make stopping cheap in the other direction too. If reverting means the programme slips a quarter and somebody's objectives fail, the person on the night will hesitate, and that hesitation is the mechanism by which a recoverable problem becomes an incident. Sponsors who genuinely want a safe cutover say out loud, before it starts, that reverting is a success outcome.
Separate the read flip from the write flip, because reversal is a routing change before the new system takes authoritative writes and a data-migration project afterwards. State the reversal window in hours, rehearse it with a named person, and prove the new system at peak rather than on an average day.