What Legacy System Modernization Really Costs 

An IT director once opened a call with us by asking for one number: what does it cost to modernize a fifteen-year-old system? We asked a question back that he found annoying and later called the most useful part of the engagement: how much of what the system does can anyone at your company currently explain? The gap between 'it runs the business' and 'we can describe what it does' is where most of a modernization budget actually goes, and it's why honest answers come as ranges with conditions attached. This post is the breakdown we give clients scoping legacy modernization: where the money really goes, why the strangler-fig approach changes the risk math more than the total, what realistic durations look like, and the handful of decisions that genuinely make the whole thing cheaper.

Cost Driver One: Archaeology, Not Code

The first budget line that surprises people is discovery, and it shouldn't, because nobody knows what the old system does. The documentation describes the system as designed, years of patches describe the system as it is, and the difference lives in places like the database. The canonical example is the undocumented stored procedure: business logic that migrated into the database over a decade, written by people who've left, enforcing rules nobody remembers agreeing to. On our logistics migration, we spent the first two weeks doing nothing but archaeology, reading code and tracing batch jobs before anyone touched anything, and the client's IT director later said the thing that won his trust was a vendor treating those undocumented stored procedures as our problem instead of his fault. Budget real weeks for this. Every proposal that skips discovery hasn't removed the cost; it has moved it into the build phase, where each surprise arrives with a deadline attached.

Cost Driver Two: Running Two Systems at Once

However you modernize, there's a stretch where the old system and the new one both run, and both cost money. That means double infrastructure for the overlapping scope, a routing layer or API gateway deciding which system owns which request, and engineering effort spent keeping behavior consistent across the seam. Data migration sits inside this driver and deserves its own respect: a decade of records in inconsistent formats, with duplicates, orphans, and encodings that predate the current team, has to be cleaned, mapped, moved, and reconciled, and reconciliation is the expensive part because finance won't sign off on 'mostly matches.' There's also an organizational cost nobody invoices: every new feature the business launches into the old system during the migration widens the gap the new system has to close. Freezing legacy change isn't always possible, but every month of unfrozen legacy development is a month of paying for the same ground twice.

Strangler Fig vs Big Bang: the Economics, Honestly

The strangler-fig pattern, replacing the monolith one capability at a time behind a gateway while the rest keeps running, is not automatically cheaper in engineering hours than a rewrite. The gateway, the incremental boundaries, and the long coexistence all cost effort a clean-room rewrite wouldn't. What it changes is the shape of the risk. A big-bang rewrite concentrates everything into one cutover: if the new system has a gap, you find out on go-live day, with no graceful way back, and the industry's record on those cutovers is grim. The strangler approach spends its budget in small, reversible steps, each one shippable and each one falsifiable, so being wrong costs a slice instead of the project. On the logistics engagement, that meant a team of seven migrating capability by capability for eleven months until the monolith was down to a scheduling stub, with a cutover the eighteen working warehouses never noticed and API response times cut by more than half along the way. The business never stopped running, which is the line item no rewrite quote can offer.

Realistic Duration Bands

Durations vary with scope, team size, and how much archaeology the system needs, but the bands we see hold fairly steady. A contained system, one application with a known data model and few integrations, runs four to nine months to modernize properly. A monolith running a whole operation, with batch jobs, integrations, and a decade of accumulated logic, is realistically twelve to twenty-four months with a dedicated team, and our eleven-month logistics timeline sat at the fortunate end of that band because discovery started before commitments did. Anything quoted in weeks for a system of real age is describing a lift-and-shift, which moves the problem to new hosting without modernizing anything, and anything quoted at three years without intermediate shipped milestones is a rewrite wearing incremental clothing. The schedule tell is simple: ask what will be live, in production, serving real traffic, at month four. A good plan has an answer. A risky one has a phase name.

What Actually Makes It Cheaper

• Retire features instead of migrating them: usage data always shows screens and reports nobody has touched in years, and every one you sunset with business sign-off is scope deleted, not deferred
• Do the archaeology before the commercial commitment, so the price is built on evidence instead of optimism
• Freeze or strictly gate new development on the legacy system, because a moving target is the most expensive kind
• Sequence by business value and risk together: migrate a capability that's painful and well-understood first, and save the gnarliest module for when the team knows the terrain
• Build the reconciliation tooling early, since proving the new system matches the old is cheaper as a habit than as a crisis
• Keep finance and operations in the loop weekly; they accept or veto cutovers, and surprises at that table cost months

The Honest Summary

Modernization costs what it costs mostly because of what nobody knows about the old system, and the cheapest money you'll spend is whatever makes the unknowns known earlier: discovery weeks, usage analysis, reconciliation tooling. The strangler-fig route rarely undercuts a rewrite on paper, and it wins anyway, because its worst case is a delayed slice while a rewrite's worst case is a failed cutover with the business on top of it. If you're budgeting one of these, ask every vendor where the archaeology time is in their quote, what ships by month four, and how the plan behaves when it meets a stored procedure nobody can explain. The quotes that survive those three questions are the ones worth comparing.