The most expensive technical decision is the rushed migration

The most expensive technical decision I see PE portfolio companies make is rushing a cloud migration to hit a deadline. End of quarter, end of fiscal year, last year of a hold. The deadline changes; the mistake doesn’t.

I watched it almost happen recently. A team I work with had been running infrastructure on a single VM. Cheap, simple, working. The ask came in to migrate to a managed cloud service before quarter close. The cost case was real, meaningful monthly savings, the kind of line item I usually argue should get more scrutiny, not less. The destination was right.

The timing was wrong, and I pushed back hard.

The asymmetry

Two days before a project endpoint is the worst possible time to introduce a major architectural change. Even if the migration goes perfectly, you have no time to validate that the new system behaves the way the old one did. And migrations don’t go perfectly. They go mostly fine, with a handful of surprises that take days or weeks to surface: the cron job that assumed local disk, the latency profile that changed shape, the backup that was never actually tested in the new environment.

Run the math on what each side of the bet pays. Best case, you capture the savings a few weeks earlier than you would have anyway. Worst case, you spend the next month firefighting, and the savings get consumed by the cleanup. Capped upside, uncapped downside. That’s not a close call.

The cost nobody puts in the model

The team in this story had spent two quarters building credibility by delivering against a stable foundation. A bad cutover would have erased it, and not because the technology was wrong. Because the timing turned every operational hiccup for the next quarter into a referendum on the migration decision. Once that referendum starts, the team stops proposing improvements at all, and the infrastructure quietly freezes. The most expensive outcome of a rushed migration isn’t the outage. It’s the two years of justified conservatism that follow it.

The hold-period version of this is worse. A migration rushed in the final year before a sale doesn’t just risk operations, it lands squarely in the buyer’s diligence window, where every unvalidated change reads as risk and gets priced accordingly. An aging-but-stable system with a documented migration plan is a better diligence story than a fresh cutover nobody has lived with yet. I think most sellers have that exactly backwards.

What we did instead

We documented the path, scoped the migration properly, and parked it for the next quarter, when there was room to cut over and then actually watch it. The savings arrived one quarter later. Nothing else changed. That’s the whole cost of doing it right, and it’s almost always smaller than it feels in the “just do it” moment.

The tell of a senior technology leader isn’t that they make the right architecture call. Most experienced people get the destination right. It’s that they’re willing to push back when the cost of being wrong is asymmetric, even when the pressure to just do it is coming from above. That’s a big part of what a modernization done right looks like in practice: phases, validation windows, and a business that keeps running while the ground moves.

Worth being honest about: most of the architectural pain I get called into mid-stage companies to fix traces back to a migration somebody rushed. The deadline that forced it never turns out to have mattered as much as everyone thought.