Glossary
Big bang migration
Also: Cutover migration
Switching a system on a fixed date, usually over a weekend, with no intermediate state and only one attempt.
The appeal is simplicity: no parallel operation, no duplicated data, one clear date. That is exactly why it gets chosen when gradual replacement looks too expensive.
The price is the risk profile. Everything has to work at once, and the way back consists of restoring a backup while the business is down.
The reasoning error behind it is usually the same one. Parallel operation is weighed against the cutover, but only the build cost is compared. What a failed cutover costs, multiplied by the probability that it fails, is left out. That probability is not small for grown systems, because the special cases that will get in the way are exactly the ones nobody knows about.
Two things separate a defensible cutover from a negligent one. The first is the rehearsed rollback: not described, but carried out in full at least once, with a measured duration and on a data set of production size. The second is an abort criterion agreed before the date, including the time of day by which the decision has to be made at the latest.
Without that time the same thing happens again and again: at two in the morning, after ten hours of work, an exhausted team decides against the way back because it feels like giving up. So the moment of decision belongs in the plan, not in the night.
There are cases where the cutover is right: a database version that cannot be run in parallel, a data centre with a hard end of contract, a small system with a clean data boundary where the switching layer would cost more effort than the move. It becomes wrong when it is chosen only because nobody wants to design the intermediate state.
How you notice it
- The switch is planned for one weekend.
- There is no intermediate state where old and new run in parallel.
- The way back consists of restoring a backup.
- The duration of the rollback was estimated, not measured.
Not to be confused with
- Strangler fig
- Many small switchovers instead of one big one. Every step can be reversed on its own, at the price of an intermediate state that has to be operable.
- Blue-green deployment
- Looks similar but is something else: two complete environments of the same application, switching in seconds, and the way back just as fast. Not a change of system, a delivery technique.
- Maintenance window
- A planned downtime for a limited change. The cutover is a maintenance window in which everything essential is swapped at the same time.
When it fits
- A small system with a clean data boundary, where parallel operation would cost more than the risk.
- Parallel operation is technically impossible, for example with a database change that has no compatibility in both directions.
- A hard external date that is not negotiable.
- The rollback is rehearsed and safely fits into the time window.
When it does not
- Business-critical systems with unknown special cases.
- When the way back has only been described, never carried out.
- When the rollback takes longer than the maintenance window allows.
- When the cutover is chosen only because the intermediate state was never designed.
How to approach it
- Build the way back firstBefore the switch itself. Whatever cannot be rolled back does not get switched, it gets made reversible first.
- Rehearse in full, at production sizeWith a copy of the real data set and a stopwatch running. A rehearsal on a tenth of the data does not measure the duration that counts.
- Fix the abort criterion and the timeHow an abort is recognized, and by when the decision has to be made. Both in writing, before the date, approved by somebody who is not working through the night.
- Write down the sequence and the ownersWho does what, who confirms, who decides. At night people read, they do not reason.
- Prepare the business checksConcrete cases with an expected result, worked through after the switch. "Looks good" is not a criterion for sign-off.
- Plan for the days afterThe first working days are part of the switch: heightened observation, short paths, no other changes. Most special cases do not report themselves during the night, they report themselves on Monday.
Frequently asked
When is a cutover defensible?
For small systems with a clean data boundary, when parallel operation would cost more than the risk. The precondition is a fully rehearsed rollback with a measured duration. Without that rehearsal it is not a migration, it is a bet.
How long may the rollback take?
Short enough to fit completely into the maintenance window after the abort has been decided. In practice that means: window minus planned switch duration minus buffer. If you have an eight hour window, spend six hours switching and need three hours to restore, you do not have a way back.
What about the data created during the window?
It is the most common reason a rollback is no longer possible when it matters. If orders land in the new system after the switch, restoring the backup throws them away. So the question of when the way back ends, and what applies instead from then on, belongs before the date: usually a forward fix under time pressure, and that should be chosen deliberately rather than discovered.
Why is the cutover still chosen so often?
Because it looks cheaper. What gets compared is the build cost of a switching layer and parallel operation against one weekend. What does not get compared is the expected damage, and for grown systems that is considerable, because the special cases that cause trouble are precisely the unknown ones.