Modernization Isn't a Rewrite

Every failed rewrite we've been called in to autopsy started with the same sentence: "The system is ancient, let's just rebuild it." Reasonable-sounding words. They have probably destroyed more IT budgets than any other sentence in this industry.

A regional utility we worked with had a billing platform older than half its staff. Green screens, batch jobs, the works. The new CIO wanted a clean-sheet replacement, and honestly, we understood the itch.

Here's what we asked instead: what, specifically, can't the business do today? That one question changed the whole engagement.

The replica problem

When you commission a rewrite, the default requirement set becomes "everything the old system does." Nobody wants to be the person who dropped a feature, so the spec turns into an inventory of the past. Every workaround. Every report nobody has opened since 2011.

You end up paying millions for a faithful replica of decisions made under constraints that vanished decades ago. That batch job runs at 2 a.m. because tape drives were slow in 1994. Your shiny new cloud platform will run at 2 a.m. too, because the requirement said so and nobody asked why.

Meanwhile the business waits. Rewrites are all-or-nothing bets, and the payoff sits at the far end of a multi-year schedule that history says will slip. If priorities change in year two, and they will, you're holding half a system and a full invoice.

Boring and correct is an asset

A rewrite is the most expensive way to avoid asking what the business actually needs.

Start from the business problem and something useful happens: a lot of the legacy estate turns out to be fine. Ugly, undocumented, and fine. That rate calculation engine has produced correct numbers for twenty years. It is not the thing standing between you and growth.

The things actually standing between you and growth are usually at the edges. Customers who can't self-serve. Field crews re-keying paper forms. A month-end close that takes eleven days. Those problems have dollar figures attached, and most of them can be fixed without touching the core at all.

Strangle it, don't shoot it

The approach that works is incremental, and it's old enough to have a name: the strangler pattern. Build the new capability at the edge, route one flow through it, and let the legacy system keep doing everything else. Then pick the next flow. Over time the old system does less and less, until switching it off is an afternoon, not an event.

This looks slower on paper and runs faster in reality. You ship value in months. You learn from live users before you've committed the whole budget. And you can stop at any point and still be ahead, which is not something a half-finished rewrite can claim.

Our utility client never did replace that billing core. They wrapped it, moved self-service and payments off it, and let the mainframe keep calculating. Call volumes dropped, the board got its modernization story, and the riskiest part of the estate stayed untouched and correct.

So before you sign off on a rebuild, make the team name five business outcomes that are genuinely blocked by the current system. Blocked, with numbers attached, not merely annoying. If they can't get to five, you don't have a modernization problem. You have a maintenance budget conversation, and those are a lot cheaper.