Getting the Green Light on Your Rewrite: How AI Changes the Math on Legacy Software Modernization

The high-stakes rewrite that was too expensive and too risky to greenlight is now a real option.

For years, replacing a costly, aging application was a project most organizations simply couldn't greenlight. Not only because it was expensive, but because the cost was impossible to bound with any confidence. You were asking a board to approve a number that everyone in the room knew could be off by 2x or more.

Agentic engineering changes both halves of that problem. It lowers the cost of a legacy software modernization by roughly the same 30–50% we're now seeing on new-product work, and — just as important — it materially tightens the confidence around the budget, because AI agents can read the legacy system as a specification and surface hidden complexity before you commit. The result is straightforward: rewrites that were too big and too uncertain to approve now pencil out. That opens the door to modernization work that simply wasn't viable a couple of years ago.

How far the gains go depends on the project, and I'll be specific below about where this holds and where it doesn't. But the direction is clear, and for a lot of leaders sitting on a system they've been afraid to touch, it's worth re-pricing that decision now.

The rewrite you couldn't green-light

Picture the aging internal application everyone depends on and no one wants to touch. It's costly to change, risky to update, hard to integrate with, and the data you need is effectively trapped inside it. It works — right up until it doesn't — so modernization keeps getting deferred another year.

When I wrote about getting started on application rewrites years ago, the core obstacle was already clear, and it was never just the price tag. It was two problems stacked on top of each other.

The first is cost. Replacing ten or fifteen years of accumulated custom software in a year or two was often preventatively expensive. The second, and the one that actually kills these projects, is uncertainty. Rewrites are extremely difficult to budget with high confidence. The complexity hides in undocumented business rules, tangled integrations, and edge cases nobody remembers — and it tends to surface in the middle of the project, after the budget is set, not before. My colleague Drew Colthorp has written about estimating rewrites from the legacy codebase precisely because a normal, time-boxed analysis phase is too short to de-risk one adequately.

So the executive calculus was rational: a high expected cost, wrapped in enormous uncertainty, adds up to a risk-adjusted answer of "let's live with it another year." Multiply that across a decade and you get the legacy systems still running critical operations today.

What actually changed

The instinct is to say "AI writes code faster," and that's true. But it isn't the interesting part.

When writing code was the expensive part of building software, it was also the constraint — teams organized everything around making that step go faster. Once agents handle much of the coding, the constraint moves upstream: to deciding precisely what to build, and to verifying what the agents produced. Our team has written at length about how we work in this new reality in Agentic Engineering for Teams, and the central shift is exactly that — the bottleneck is no longer typing the code.

Here's why that matters so much for software modernization specifically. The thing that always made rewrites expensive and un-budgetable was discovery — understanding what the old system does and what it will take to replace it. Discovery is the phase agents are now unusually good at accelerating, because in a rewrite the answer key already exists: it's the legacy system itself. That gives modernization two distinct wins, not one — an economic win and a confidence win. They're worth taking in turn.

Foundation one: the economics

Start with cost. We're seeing agentic engineering reduce the cost of building new software by roughly 30–50%, and modernization lands in a similar band. (We frame this as a reduction rather than a speed multiple because it's easier to reason about — but the two are the same fact: for a fixed team, cost tracks weeks of work, so compressing the schedule compresses the budget.)

Two levers drive that reduction. The first is throughput — agents do more of the building, so implementation goes faster. The second is the legacy system itself: because it's a readable specification, agents can extract business rules, map dependencies, and translate old code far faster than a team starting from a blank page. That second lever is what makes modernization compress differently from new work, and to see how, it helps to split a project into three parts.

Discovery is understanding what the current system does. The old way was never reading the whole codebase — nobody did that. It was analysts and designers interviewing and job-shadowing users to reconstruct business logic and workflows. Agents reading the code directly collapse much of that cost. Not all of it: the code tells you what the system does, not what users need or what's happening in the spreadsheets and workarounds outside it, so some human research remains.

Replicate build is rebuilding behavior the system already has, on a modern footing. This compresses the hardest of the build work — faster even than greenfield — because the spec is handed to you. Agents don't have to invent what to build, and they can check the result against the still-running old system.

Net-new build is the new features and architecture you add along the way. This behaves like any new development, because you're inventing it, so it lands at the same sort of reduction a greenfield project would.

Because those three parts compress at different rates, the mix determines the total.

An illustrative example

Take the same 100-week rewrite under two different mixes, holding the per-part reduction rates fixed — discovery down 50%, replicate build down 60%, net-new build down 30%. Only the mix changes.

Replicate-heavy mix — a platform modernization (mostly same behavior, modern stack)

• Discovery: 10 weeks → 5 (−50%)
• Replicate build: 80 weeks → 32 (−60%)
• Net-new build: 10 weeks → 7 (−30%)
• Total: 44 weeks — a 56% reduction

Net-new-heavy mix — a modernize-and-expand (mostly new capability)

• Discovery: 10 weeks → 5 (−50%)
• Replicate build: 10 weeks → 4 (−60%)
• Net-new build: 80 weeks → 56 (−30%)
• Total: 65 weeks — a 35% reduction

Same baseline, same per-part rates; only the mix changes — and the result swings from 35% to 56%. That's why we anchor on 30–50% and treat the high end as conditional: a replicate-heavy job can exceed it, a net-new-heavy one sits near the bottom. ("Replicate" here means reproducing the business behavior on a modern platform — not cloning the old interface feature-for-feature, which is its own well-documented way to make a rewrite fail.) Because cost tracks weeks of team time, the budget moves with the weeks. Drew's lines-of-code estimation method is a possible, first-blush way to put real figures against your own system.

Foundation two: confidence in the budget

Lowering the cost is only half the story — and it's the half everyone expects. The other half is the one that quietly did the killing. Executives don't decline rewrites simply because they're expensive; plenty of expensive projects get funded when the return is clear and the number is trustworthy. They decline rewrites because the number can't be trusted — an estimate everyone in the room knows could be off by 2x. That's what's distinctively broken about a rewrite: a new product of similar cost is often easier to fund, because its estimate is more believable. A cheaper rewrite you still can't bound with confidence is likely still un-fundable — both halves have to move.

This is where the legacy system's role as an answer key pays off a second time. Instead of a time-boxed analysis phase in which a few people review a slice of a large system, agents can read the entire codebase during scoping — extracting rules, mapping real dependencies, and surfacing the hidden complexity that used to ambush projects at month six.

That's the mechanism worth internalizing: agentic scoping moves the discovery of hidden scope to the front of the project instead of the middle. The surprises don't disappear — they become known scope before anyone commits a budget. The estimate tightens not because the system got simpler, but because you saw more of it before you priced it. It's the direct answer to the old truth that a rewrite is always bigger than it looks.

A necessary caveat: this buys you higher confidence, not certainty. The reason a system is being rewritten is usually that its code is a mess — which means agent-extracted rules still need human validation. You narrow the range of the estimate; you don't collapse it to a point. But narrowing the range is often exactly what turns a "no" into a "yes."

What this unlocks

Put the two foundations together and the executive calculus flips. Lower the expected cost and tighten the variance around it, and a decision that was rationally "no" becomes rationally "yes."

The reframe I'd encourage leaders to sit with is this: the point isn't that your project gets cheaper. It's that the $5–10M rewrites that were simply too big to greenlight now drop into a fundable range. In our own writing on agentic engineering, the business benefit we keep returning to isn't just lower cost per line — it's the reach to take on work that wasn't viable before. That's the real opportunity here. The modernization that's been sitting on your someday list, the one you shelved because the business case never closed, is worth putting back on the table and re-pricing.

Where this does and doesn't hold

I've used a clean, logical model to show how agentic engineering changes the math on modernizing legacy software — but that model is an illustration, not a promise for your specific project. The size of the gain is earned, and it turns mostly on two things: whether the agents can get at the real system, and what your project's mix actually is.

Source access and completeness. The discovery win assumes the agents can actually see the code that runs — and that's a more important assumption than code quality. Where the source is present and runnable, agents are remarkably good at tracing even ugly, undocumented, spaghetti code; messiness slows a human reviewer far more than it slows an agent. The real limiters are access and completeness. On access: you may only have binaries, source that's been lost or has drifted from what's in production, or logic locked inside a third-party product you can't see into. On completeness: some behavior isn't in the application code at all — it lives in data, configuration, scheduled jobs, or the manual steps people perform around the system. So the question that governs the discovery win isn't "how readable is the code?" — it's "can the agents get at the code that actually runs, and how much of the real behavior lives outside it?"

Project mix. The ratio of behavior-replication to net-new work is the other lever: it sets where in — or beyond — the 30–50% band you land, because the two kinds of work compress so differently. It also drives how much of the verification is automatable. Confirming the new system matches the old is a step unique to modernization, and for replicate work it's largely automatable — the legacy system is a runnable oracle, so agents can push the same inputs through old and new, confirm the outputs match, and compare at the interface level. (That's where source access bites a second time: you need to run the old system to diff against it.) For the net-new portion there's no prior behavior to match, so parity gives way to human product judgment — which is exactly where you'd want a person deciding anyway. So the legacy-as-spec advantage shows up at both ends, scoping at the front and verifying at the back, and both track the same replicate-versus-net-new split.

If you read our team's agentic engineering guide, you'll notice we're deliberately measured about all of this. This piece should read as consistent with that, not louder than it. The gains are real; they're also specific to the project in front of you.

Getting started

A few practical moves make the first step smaller than it sounds.

Think in partial replacements, not a single monolithic rewrite. Sequencing the work so it delivers value in stages is still the surest way to build momentum and keep funding decisions grounded in real progress. Put the right team on it — one experienced in product development, not only in operational IT maintenance. And invest in an agent-accelerated scoping phase up front, so you walk into the funding conversation with a bounded plan rather than a hopeful one.

That last point is where the two foundations become tangible. A modern scoping engagement can give you a credible cost, a defensible range around it, and a phased plan — the exact things that used to be impossible to produce for a rewrite, and the exact things an executive or a board needs to say yes.

The rewrite you couldn't justify a few years ago may be a different decision today. If you'd like to find out, that's a conversation we're glad to have — our free pre-project consulting is built to give you an honest read on your situation and a real budget model to take back to your team.

‍