Most modernization efforts stall because the starting point is too big.
Once the conversation becomes "should we rewrite the whole system," it collects a set of questions that are hard to answer: How long would that take? What breaks along the way? How do we justify it against the roadmap? What happens if we start and cannot finish? Faced with that, many teams postpone legacy system modernization even when everyone agrees the current system is slowing them down.
There is a more useful way to frame it. You do not have to modernize everything to make real progress. You have to choose the right first modernization milestone. This is how to find it.
Why "modernize everything" creates too much scope
A full rewrite is appealing because it promises a clean slate. In practice, it front-loads the most risk at the exact moment your team understands the new system the least. The data on large efforts is sobering: the Standish Group's CHAOS research has long found that large software projects succeed far less often than small ones, and that the biggest projects are the most likely to be cancelled outright or to deliver far less value than planned.
The reasons are familiar. Scope is hard to estimate, because a legacy system encodes years of undocumented decisions you will only rediscover by rebuilding them. The timeline competes directly with roadmap work, which makes it hard to defend to leadership. And the payoff arrives at the very end, if it arrives at all, so there is little to show for months of effort until the whole thing lands. Meanwhile the old system still has to run the business, which means you are effectively maintaining two systems at once.
This is why the most reliable alternatives to a full rewrite are incremental. Google's 2024 DORA research consistently ties strong delivery performance to small batch sizes and solid testing, not to sweeping changes. The same logic underpins established patterns like the strangler fig approach, where a new system grows alongside the old one and takes over a piece at a time while the original keeps running. Incremental modernization is not a compromise. It is usually the lower-risk path to the same destination.
"Modernize everything" also hides the more important question. Not all technical debt is equally expensive. Some of it is genuinely slowing the business down. Some of it is just old and perfectly fine to leave alone. A whole-system rewrite treats both the same and spends your team's scarcest resource, focused engineering time, on areas that may not be creating any drag at all.
The better question is narrower and more honest: where is change most expensive right now, and what is the smallest milestone that would reduce that cost? That reframing turns an intimidating multi-year debate into a scoped, defensible decision.
How to evaluate technical debt by what it actually costs you
To choose a first milestone, you need a way to compare candidates that is grounded in business reality rather than engineering preference. A sound application modernization strategy usually weighs five lenses.
- Business impact. How directly does this area affect customers, operations, revenue, or a strategic priority? Debt attached to a core revenue workflow matters more than debt in a rarely used internal tool, regardless of how ugly the code is.
- Delivery friction. How much does this area slow the team down day to day? Look for the workflows where small changes take far longer than they should, where estimates are unreliable, and where planned work keeps getting interrupted.
- Production risk. How dangerous is it to change this area? Concentrated system knowledge, hidden dependencies, and fragile release paths all raise the odds that a reasonable change causes an incident. High-risk areas are often where confidence, not effort, is the real constraint.
- AI suitability. How much could AI-assisted discovery reduce the cost of understanding this area before you touch it? Systems with thin documentation, unclear boundaries, or lost tribal knowledge are strong candidates for AI-supported analysis that maps dependencies and documents behavior.
- Test readiness. How well is this area covered by tests today? Test coverage determines how safely you can change something. An area with reasonable coverage can be modernized with more confidence; an area with none may need a testing milestone before anything else.
Score your candidates across these five lenses and the priorities usually separate quickly. The area with high business impact, high delivery friction, and high risk is almost always where a first modernization milestone earns its keep.
What makes a strong first modernization milestone
Once you have a priority area, the milestone itself needs the right shape. A strong first milestone shares five traits.
It is tied to a real delivery bottleneck, so the benefit is felt, not theoretical. It affects a business-critical workflow, so the effort is easy to justify. It can be scoped clearly, so the team knows when it is done. It reduces future change risk, so the next change is safer than the last. And it creates proof, evidence for the team and for leadership, that modernization can happen safely without disrupting the business.
That last trait matters more than it looks. A well-chosen first modernization project does three things at once: it improves visibility into the system, it reduces uncertainty around the next change, and it builds the credibility to fund the work that follows. That is how modernization stops being a "someday" line item and becomes an executable plan. McKinsey makes a similar case for breaking technical debt's cycle through steady, prioritized work rather than one disruptive overhaul.
One test cuts through most debates. Would improving this area make the next three roadmap changes easier, safer, or faster? If the answer is yes, it is worth evaluating first. If it is no, it may be debt you can live with for now.
What a first milestone looks like in practice
Concrete examples make the shape clearer. Here are four common starting points that fit the criteria above.
A framework or platform upgrade. A long-running application falls several versions behind its framework. The versions it depends on stop receiving security and maintenance updates, and the gap widens every quarter. A scoped upgrade, with tests added around the pages and workflows most likely to be affected, brings the platform current and makes every future upgrade cheaper. In one engagement, upgrading a multi-year application to a current framework version was the milestone that let the team modernize aging components as they went, rather than all at once.
Migrating a legacy component to a modern structure. An application carries two front ends: an older structure that was never migrated, and a newer one the team actually wants to build on. Every change to the old side is slow and risky. Migrating one high-traffic component to the modern structure is a contained milestone that proves the pattern and creates a template for the rest. This is also an area where AI-assisted work helps: it can translate legacy components into the new structure quickly, while engineers handle the parts that require judgment, like wiring up the right endpoints and parameters, and verify the result with tests and QA.
Filling a critical test gap. A business-critical workflow has little or no automated coverage, so every change depends on manual investigation and careful QA. A milestone that builds a test suite around that workflow does not change the architecture at all, but it changes everything about how safely the team can work in it afterward. It is often the highest-leverage first step for an area flagged as high risk.
Stabilizing a fragile release workflow. A brittle deployment path requires manual intervention with every release, which quietly taxes velocity and morale. A milestone focused on understanding and hardening that workflow, documenting what it does, removing the manual steps, and adding rollback safety, reclaims capacity on every future release rather than once.
None of these is a rewrite. Each is a contained piece of legacy system modernization work with a clear boundary, a real payoff, and a result you can point to.
How to use the first 90 days to create visible progress
A first milestone is most valuable when it produces something real inside a quarter. Ninety days is enough time to show progress and short enough to keep the scope honest, which is why a 90-day modernization plan is often the most practical way to start.
A practical shape for that window has three phases. First, a scoped assessment of the priority system: its architecture, dependencies, release bottlenecks, and where the risk actually concentrates. This is where AI-assisted discovery earns its place, by compressing the manual work of understanding the system. Second, the modernization of one high-impact workflow or component, using AI-assisted development where it speeds the work without lowering quality, and delivering production-ready improvements the team can actually use. Third, safe deployment, with a clear testing and rollback strategy, plus a documented path for what to modernize next. A disciplined delivery process is what keeps each phase predictable and low-risk.
The output is not just cleaner code. It is a production-ready first milestone and a roadmap for everything that follows, backed by proof that the approach works on your system specifically. That proof is what makes the second milestone easier to fund than the first.
The goal was never to modernize everything at once. It is to pick the first area where better structure, documentation, testability, or architecture creates the most downstream benefit, and to deliver it in a way that builds momentum.
The bottom line
You probably do not need a full rewrite. You need a clear first step: the one workflow, service, code path, or platform area where modernization would reduce the most risk or create the most delivery leverage. Choose it by what it costs the business today, scope it so the team can finish it, and use the first 90 days to turn it into visible, defensible progress.
If your team is weighing where to start, we can help you map a practical first modernization milestone.