Table of Contents
TL;DR
Our platform migration was a big-bang weekend: convert the database, cut over, you are live. It did not go clean, and we almost rolled back. On the other side of the cutover, performance collapsed. Me and one consultant found enough headroom to keep the system in barely tolerable range, which bought the time for the real fix. The lesson: a big-bang migration is not won on cutover weekend. It is won in the weeks you survive afterward.
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 are live. No parallel running, no phased departments. Friday you are on the old world; Monday you are on the new one.
Oh my lord, what a switch.
Why we bet the weekend
Big bang was a choice, and the reasoning deserves a fair hearing because the alternative was not 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, which is 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, which is why cutover weekend itself, the part everyone fears, was the part that went to plan. What the rehearsals could not contain was the following week, because you cannot rehearse the entire company using the system at production intensity. That is 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 did not go clean. The conversion worked, the systems came up, and then the performance collapsed. The new environment could not carry the load at anything like the speed the business required. And with a big-bang cutover, there is 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 is not won on cutover weekend. It is 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. I want to be honest about what we achieved in those first days, because migration stories usually lie here. We did not 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.
The real solution
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 is where the true cost of the migration surfaced.
What I now believe about big-bang cutovers
I will not tell you big bang is wrong; we chose it, and the migration ultimately succeeded. What I will tell you is what the choice actually purchases. A big bang trades months of dual-running complexity for a concentrated bet, and the bet is not “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 is not the cutover runbook. Ask three questions. What is 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 is the rollback trigger, decided now, in writing, while everyone is calm? We survived without having all three answers in advance. I do not recommend the experience.
For more from this series, see the The Digital Transformation Hub: real transformations, lived from the inside, decades before the term existed.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.