Barely Tolerable: Surviving the Weeks After Go-Live

TL;DR

Go-live is not the finish line of a migration. It is the midpoint, and the weeks after it decide whether the project succeeded. After our big-bang cutover, the platform ran in what I can only call barely tolerable range: struggling, slow, alive. Holding it there while the real fix was built is a discipline nobody plans for, and it is the phase where migrations are actually won or lost.

Every migration plan I have ever seen treats go-live as the summit. The Gantt chart crescendos to cutover weekend, and the boxes after it say things like “stabilization” and “hypercare,” thin little boxes, drawn by optimists. Then you go live, and you discover what those boxes actually contain.

After our big-bang platform migration at the major national retailer, described in the previous article, the system came up and could not carry the load. An emergency fix bought us headroom, and what the headroom purchased was not health. It was a state I call barely tolerable: the platform struggling, the business enduring, everything functional and nothing good. We lived there for weeks while the real repair, a months-long query optimization effort, ground forward.

What barely tolerable actually demands

Operating a barely-tolerable system is its own discipline, and no methodology I have read describes it honestly. Three things defined it for us.

Triage becomes the operating system. When the platform cannot do everything acceptably, someone must decide what it will do badly. Which workloads get priority, which reports can run overnight instead of on demand, which departments absorb the worst of the slowness. Those are business decisions wearing technical clothes, and they need to be made deliberately, by people with the authority to disappoint someone, rather than emerging from whoever complains loudest.

Expectations need active management, daily. A workforce that just lost its familiar system and received a slow one in exchange will conclude the migration failed unless someone credible keeps telling them the truth: here is why it is slow, here is what is being done, here is the honest timeline. Silence gets filled with the worst interpretation, and morale-driven failure is real failure.

And you protect the fix from the firefight. The same people best qualified to build the permanent repair are the ones everyone wants on today’s emergency. We had to deliberately wall off the optimization work from the daily triage, because a team that spends every day surviving never ships the thing that ends the survival phase.

There is also a ledger being kept in those weeks that appears on no dashboard: credibility. Every honest daily update deposited a little; every workaround that held deposited more. The reserves mattered because barely-tolerable operation runs on discretionary human effort, the accounting clerk accepting the slow report, the manager not escalating, and that effort is extended to teams people believe. We could spend trust because we had been earning it daily, and I have watched other organizations run the same weeks with an empty account, where every slowdown became an escalation and the recovery drowned in its own meetings.

The trap in the phase

The subtle danger of barely tolerable is that organizations acclimate to it. Week three, the workarounds have hardened into routine, the complaints have gone quiet, and the pressure that funds the real fix begins to leak away. Barely tolerable starts to look like the new normal, and I have watched companies, not mine, thankfully, stall there permanently, running degraded systems for years because the crisis lost its urgency before it lost its cause.

The countermeasure is measurement. We knew what healthy looked like in numbers, we knew where we were against those numbers, and the gap stayed visible to the people writing the checks until it closed. Barely tolerable must be a bridge with a far end, and someone has to keep pointing at the far end.

Go-live is not the finish line of a migration. It is the midpoint, and nobody plans for the second half.
Share on X

Why this chapter belongs in your book

Executives who write about their transformations reliably skip this phase, straight from the dramatic cutover to the happy retrospective. Readers who have lived a migration know exactly what got skipped, and they trust the author less for it. The barely-tolerable weeks are where the leadership actually happened: the triage calls, the credibility spent, the fix protected from the fire. Tell that part, and practitioners will believe every other page.

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.

Frequently Asked Questions

What happens after go-live in a system migration?
The new platform meets real production load, and performance and stability problems that testing missed surface. The weeks after go-live are typically where migrations succeed or fail, not cutover weekend itself.
What is hypercare and why is it underestimated?
The intensive support period after go-live. Plans draw it as a short stabilization phase; in a difficult migration it becomes an extended operating discipline of triage, expectation management, and protecting the permanent fix from daily firefighting.
How do you keep a degraded system running after migration?
Deliberate triage of what runs well versus badly, daily honest communication to maintain workforce trust, measurable definitions of healthy versus current state, and a firewall around the team building the permanent repair.

📁︎ Digital Transformation

🏷︎ IT Leadership🏷︎ IT Operations🏷︎ Migration🏷︎ Risk Management

📝 Disclaimer

The views and opinions expressed in this blog post are solely those of Richard Lowe and are based on personal experience and research. This content is for informational purposes only and should not be construed as professional legal, financial, accounting, or business advice. Always consult with qualified professionals before making important business or legal decisions. Richard Lowe is not a lawyer, accountant, or licensed professional advisor, and this content does not establish any professional relationship.