The second great transformation at the major national retailer was the platform migration: everything we ran, moved from one architecture to another, with the database converted underneath. And the cutover strategy was the boldest one available. Big bang, over a weekend. Move the database, convert it, cut over. You’re live. No parallel running, no phased departments. Friday you’re on the old world; Monday you’re on the new one.
Oh my lord, what a switch.
Why choose a big-bang cutover?
Big bang was a choice, and the reasoning deserves a fair hearing because the alternative wasn’t free. Running old and new platforms in parallel means building bridges: synchronization between two databases with different shapes, dual data entry or replication, reconciliation processes to detect the drift between two systems both claiming to be the truth.
Every month of parallel running is a month of paying for both worlds plus the bridge between them, and the bridge itself is new, custom, and fragile, a strange thing to build in the name of safety. For our migration, with the database converting underneath everything, the bridge would have been a project rivaling the migration itself.
So the weekend was rehearsed instead. Conversion runs against copies, timing measured, procedures scripted, checkpoints defined: by this hour the data is converted, by that hour the applications connect, and past a defined point the weekend is committed. The rehearsals worked, so cutover weekend itself, the part everyone fears, went to plan. What the rehearsals couldn’t contain was the following week, because you can’t rehearse the entire company using the system at production intensity.
That’s the honest shape of the big-bang trade: it moves the risk out of the weekend you can script and into the weeks you cannot.
Monday
It didn’t go clean. The conversion worked, the systems came up, and then the performance collapsed. The new environment couldn’t carry the load at anything like the speed the business required. And with a big-bang cutover, there’s no partial retreat: the entire company was standing on the new platform, and the new platform was buckling.
We stood at the edge of a rollback. Almost took it. A rollback would have meant unwinding the weekend, returning to the old platform, and absorbing the organizational damage of a very public failure, with every future attempt starting from a crater of lost credibility. Almost.
A big-bang migration isn’t won on cutover weekend. It’s won in the weeks you survive afterward.Share on X
Barely tolerable
What kept us off that edge was a fix that me and my consultant improvised under pressure: a change that clawed back enough performance to move the system from failing to barely tolerable. What we achieved in those first days needs stating plainly, because migration stories usually lie here. We didn’t save the system. We kept it limping, struggling but functional, inside a range the business could barely endure, long enough to reach the real solution.
That distinction, between the fix that buys time and the fix that solves the problem, is the most useful thing this story contains. In a post-cutover crisis you rarely get to jump straight to the cure. You survive first. Survival was worth everything, because the alternative was the rollback.
What fixed the big-bang cutover?
The actual problem was in the query layer: the SQL that had run acceptably against the old database behaved badly against the new one. Same logic, different platform, different performance physics. The cure was optimizing those queries, hundreds of them, and the scale of that effort, a team of specialists working for months on an open checkbook, gets its own article, because it’s where the true cost of the migration surfaced.
When is a big-bang cutover the right call?
I won’t tell you big bang is wrong; we chose it, and the migration succeeded. What I’ll tell you is what the choice actually purchases. A big bang trades months of dual-running complexity for a concentrated bet, and the bet isn’t “will cutover weekend work.” Cutover weekend is rehearsable. The bet is on the weeks after go-live, where the new platform meets real load, real users, and real data patterns that no test cycle fully reproduced, with everyone watching and no easy way back.
So if your team proposes a big-bang migration, the plan to interrogate isn’t the cutover runbook. Ask three questions. What’s our barely-tolerable plan when performance disappoints? Who are the two people empowered to improvise at 2 AM, and do they have the authority to act? And what’s the rollback trigger, decided now, in writing, while everyone is calm? We survived without having all three answers in advance. I don’t recommend the experience.
For more from this series, see The Digital Transformation Hub: real transformations, lived from the inside, decades before the term existed.
