Legacy Modernization Cost: Replatform vs Rewrite Economics

⚡The short answer, with numbers

Every legacy modernization estimate reduces to one of three strategies, and each has a characteristic cost shape. Replatforming moves the system to modern infrastructure with minimal code change. Refactoring restructures the code in place while keeping it running. A rewrite replaces it. The price difference between them is not linear — it is closer to an order of magnitude from cheapest to most expensive.

The ranges below are what we observe across the US market for a mid-size business system: think 100,000 to 500,000 lines of code, a handful of integrations, and one database that everyone is afraid of. Smaller tools come in under these numbers; estate-scale systems with decades of accumulated logic come in above them.

One warning before the table: any vendor who quotes you a single number for modernization before reading the code is guessing. The discovery phase exists because the spread between "this system is well-documented with tests" and "three people retired and took the knowledge with them" can triple the same nominal scope.

Our legacy modernization service, scoped this way→

🔧Replatform vs refactor vs rewrite: what you are actually buying

Replatforming buys you infrastructure relief without touching logic. A typical engagement: containerize the application, move the database to a managed service, rebuild the deployment pipeline, and decommission the aging servers. The code keeps its flaws, but the operational risk — the hardware, the end-of-life operating system, the hosting contract nobody remembers signing — goes away. This is why replatforming is the cheapest path: you are paying for infrastructure engineering, not for understanding thirty years of business logic.

Refactoring buys you changeability. The system stays up and keeps its behavior, but the internal structure gets rebuilt: the monolith gets module boundaries, the stored procedures move into testable services, the god-object gets decomposed. This is the most underrated option and the one buyers most often skip, usually because a rewrite sounds cleaner in a board deck. Refactoring is roughly half the price of a rewrite for the same system because you never pay to rediscover what the system does — only to reorganize it.

A rewrite buys you a clean slate, and it is priced accordingly. The hidden cost is not writing the new code; it is the parallel archaeology of figuring out what the old code actually does, because the old system is the specification. Every rewrite estimate we have ever seen that skipped that archaeology has been wrong by a factor of two or more.

The right mental model is a cost curve over time, not a single price. Replatforming has the lowest upfront cost and the flattest curve — but it leaves the structural problems in place, so feature work stays slow. A rewrite has the steepest upfront cost and then, if it succeeds, the cheapest ongoing curve. Refactoring sits between the two on both axes. Choosing is a finance question about how long you intend to run the system, not a technical beauty contest.

📊What actually drives the number

Code volume matters less than buyers expect. Two systems with the same line count can differ 3× in modernization cost. The drivers that actually move the estimate are below, in rough order of impact.

First: knowledge availability. If the people who built or maintained the system are reachable, if there is documentation, if there are tests that encode intended behavior — the discovery phase is measured in weeks. If the system is a black box that works for reasons nobody fully remembers, discovery is measured in months and the risk premium on everything downstream goes up with it.

Second: the data. Migrating a clean, well-modelled database is plumbing. Migrating a schema that has absorbed fifteen years of special cases — columns reused for three different purposes, nulls that mean something, triggers that encode business rules — is often the single largest work package in the whole program. Data migration routinely consumes 20 to 35 percent of total budget on systems older than a decade.

Third: integrations. Every system your legacy application talks to is a dependency that must be replicated, adapted, or retired. Buyers consistently undercount these; a system described as "mostly standalone" in the first meeting often turns out to have a dozen file-drop integrations, three direct database links, and a fax gateway in discovery.

Fourth: compliance and operational constraints. A system that must stay available during migration, or one subject to audit requirements, pays for parallel running, reconciliation tooling, and sign-off processes that an offline internal tool does not.

🏦The COBOL and mainframe premium

Mainframe modernization is priced differently from everything else on this page, and it is worth being direct about why: the constraint is not technology, it is people. The pool of engineers who can read production COBOL, understand JCL job streams, and also build the target cloud system is small and shrinking. In the US market, senior COBOL-literate modernization engineers typically bill at $150 to $250 per hour, versus $100 to $180 for equivalently senior generalists — and that premium compounds across a long program.

The second driver is the economics you are escaping. Mainframe workload is often billed by consumption (the classic MIPS model), and licensing for the surrounding tooling — schedulers, transaction monitors, database — frequently costs more annually than the modernization program itself. This is actually good news for the business case: mainframe exits are among the few modernization projects where the run-cost savings alone can pay back the investment in two to four years.

There are three practical exit patterns. Rehosting moves the workload to a mainframe emulator on cloud or x86 hardware — cheapest, fastest, and the code stays COBOL, which means the talent problem follows you. Automated translation converts COBOL to Java or C# with tooling — the middle path, workable when the code is structurally sound, and the output requires real engineering to make maintainable. A functional rewrite rebuilds the business capability in a modern stack — most expensive, and the only option that fully retires the talent dependency.

Budget-wise, in US market ranges we observe: rehosting a mid-size COBOL workload typically runs $150,000 to $500,000, automated translation $300,000 to $1 million depending on code volume and cleanup depth, and functional rewrites start around $500,000 and scale with the business surface area. Any of these should be priced against what the mainframe costs you per year to keep.

🌿Strangler-fig phasing: how to fund a rewrite without betting the company

The strangler-fig pattern replaces a legacy system incrementally: you build the new system around the edges of the old one, route one capability at a time to it, and let the old system shrink until it can be retired. For cost purposes, this turns one terrifying seven-figure commitment into a sequence of funded phases, each with its own go/no-go decision.

The financial shape matters as much as the technical one. A phased program lets the business case prove itself — if the first two slices cut incident volume or run cost as predicted, phases three through six are a much easier approval. If they do not, you have spent 20 percent of the budget learning that, not 100 percent.

The honest trade-off: phasing costs more in total than a hypothetical perfectly-executed big-bang rewrite, because you pay for the routing layer, the temporary coexistence plumbing, and the longer program duration. Call it 15 to 30 percent more in total spend, in exchange for dramatically lower probability of a catastrophic failure. On a core revenue system, that is the cheapest insurance in the entire budget.

How we phase a modernization program→

🎲Risk pricing: why honest quotes include contingency

Modernization quotes carry larger contingencies than greenfield quotes, and buyers sometimes read that as padding. It is not. It is the price of known unknowns: the vendor has not yet read all the code, and neither have you. A contingency of 15 to 30 percent on a legacy program is the market being honest with you; a fixed-price quote with no contingency on an unexplored codebase is either naïve or planning to renegotiate later.

The risks being priced are specific and enumerable. Undocumented business logic discovered mid-migration. Data that does not mean what the schema says it means. Integrations found in week six that nobody listed in week one. Performance characteristics of the old system — often accidentally load-bearing — that the new one must match. Organizational drag: approvals, environment access, and the calendar time of the two internal people who understand the system and also have day jobs.

You can compress contingency by paying for it as discovery instead. A $30,000 to $80,000 assessment phase that produces a real code and data inventory, a risk register, and a phased plan will typically shrink the contingency on the remaining program by more than the assessment cost. Buying certainty early is almost always cheaper than carrying uncertainty to the end.

What you should push back on is contingency with no mechanism. Ask how it is held, what triggers its release, and what reporting shows it being consumed. A vendor who can answer that precisely has done this before. A vendor who treats the question as an insult has not, or plans to spend it silently.

One more thing worth pricing explicitly: your own calendar. Legacy programs fail silently when the internal experts who must validate migrated logic are assumed to be available full-time and are actually available two hours a week. Put a named internal allocation — real hours per week, protected by management — into the plan and the contract, and treat a missed allocation as a schedule risk on the same footing as a missed vendor deliverable.

💼Building the business case that survives the CFO

Modernization business cases fail when they argue engineering virtue — cleaner code, a modern stack, happier developers. Those things are true and worthless in a budget meeting. The case that survives is built on four quantifiable lines: run cost, incident cost, change cost, and risk exposure.

Run cost is the easiest: hosting or mainframe consumption, licences, the maintenance contract, and the fully-loaded cost of the people keeping the lights on. Incident cost is outages and urgent fixes — count them from the ticket system for the last two years, with an honest loaded hourly cost and any revenue impact. Change cost is the one that usually wins the argument: what did the last three significant business changes cost in engineering time and calendar delay, and what would they cost on a modern stack? When a pricing change takes four months because of the legacy system, that delay has a number.

Risk exposure is the actuarial line: key-person dependency, end-of-life components with no security patches, and compliance posture. You do not need to pretend you can quantify the probability of a key-person departure precisely — a range with reasoning is more credible than a fake-precise figure.

Then put the do-nothing option in the table with honest numbers. Over a three-year horizon, the status quo frequently costs more than the modernization program once run cost and change drag are included — and that is before the risk line. The comparison below is an illustrative composite for a mid-size system, not a benchmark; build your own version of it with your own ticket and invoice data.

🧭How to buy modernization without getting burned

The procurement shape that works: a paid, fixed-scope assessment phase with a named deliverable (code and data inventory, risk register, phased plan with per-phase estimates), followed by phase-gated build contracts. Never sign the whole program on day one; never let the assessment be free, because a free assessment is a sales document, not an engineering one.

Five questions that separate vendors who have done this from vendors who have read about it. Ask to see a risk register from a past engagement (anonymized is fine). Ask what their characterization-testing approach is for a system with no tests. Ask how they handle the discovery of undocumented logic mid-phase — the words "change request" should not be the first ones out of their mouth. Ask who specifically, by name and seniority, will do the archaeology. Ask what their last modernization failure looked like and what it cost.

Insist that your own people are in the room. A modernization done to an organization rather than with it produces a new system that nobody internally understands — the exact disease you were treating, with a twenty-year reset on the clock.

Expect the honest vendor to occasionally talk you down. Some systems should be replatformed and left alone; some should be retired and replaced with a SaaS subscription; a few genuinely should be rewritten. If every conversation ends in the most expensive option on the menu, you are talking to a quota, not a consultant.

We have run this playbook since 2018 across 500+ projects, with 200+ engineers between Edmonton and Chandigarh, and the pattern holds every time: the assessment pays for itself, phasing is cheaper than faith, and the do-nothing option is the most expensive line on the page. If you want a second set of eyes on your numbers — or an honest opinion that you do not need modernization yet — that conversation is free.

Start with a scoped modernization assessment→Enterprise software development guide→