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.
Anyone who calls parallel running the safe choice without pricing the bridge is being sloppy. A custom sync between two databases that disagree is its own failure point, and somebody has to reconcile the drift every single morning while the business waits for one set of numbers it can trust.
So we rehearsed the weekend 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.
Anyone who calls parallel running the safe choice without pricing the bridge is being sloppy.
That’s the real shape of the big-bang trade: it moves the risk out of the weekend you can script and into the weeks you can’t. Anyone who sells you a big bang without saying that out loud is selling you half a plan.
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.
The people who’d have paid most for that rollback were outside the war room: the employees across the company who’d have watched the new platform arrive, fail and disappear, and who’d have met the next attempt with their arms crossed. I wasn’t willing to spend their trust that way while any fix was still within reach.
A big-bang migration is won in the weeks you survive after cutover weekend.Share on X
Barely tolerable
What kept us off that edge was a fix that my consultant and I 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.
Too many migration plans have no line at all for this phase. They go from cutover straight to success, as if limping were something to hide.
Limping kept the company running. I’ll take a system that barely works and keeps working over a clean rollback every time, as long as someone’s already building the real fix.
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 came out.
| Phase | What happened | Lesson |
|---|---|---|
| Cutover weekend | Database converted, systems came up | The weekend is rehearsable; the risk sits after it |
| Monday | Performance collapsed and a rollback came close | Big bang leaves no partial retreat |
| First days | An improvised fix got the system to barely tolerable | Survive first; buy time for the real fix |
| The months after | Specialists optimized hundreds of queries | The real problem was in the query layer |
| Next time | Write the barely-tolerable plan, the 2 AM improvisers, and the rollback trigger | Decide them while everyone is calm |
My take
Plan for the weeks after the big-bang weekend, because the cutover gets all the planning and the trouble comes later. The fight starts when the platform buckles under real load and a rollback starts looking tempting. Find a fix that buys time and keep the system limping while someone builds a permanent cure. A limping system that keeps the company running beats a clean rollback that burns everyone’s trust. Any plan that jumps from cutover straight to success is half a plan.
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 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 allowed 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.
