Application modernization is usually framed as a technology problem — old code, new cloud. In practice it is a portfolio problem. Almost no organization has one legacy application; it has a landscape of them, accumulated through years of projects, acquisitions, and departed vendors. Treating that landscape one heroic rewrite at a time is how modernization programs run for years and end nowhere. The teams that succeed treat it the way an investor treats a portfolio: triage everything, act on each asset according to what it is worth.
This piece lays out that portfolio approach. If you are staring at one specific system everyone is afraid to touch, our practical guide to legacy modernization goes deep on the single-system decision; this is the view from one level up — the one an enterprise application modernization program actually needs.
Start with the inventory, not the architecture
The first deliverable of any modernization effort is embarrassingly unglamorous: a list. Every application, with four facts per row — who uses it (measured, not assumed), what it costs to run (licenses, hosting, the fraction of people's time it consumes), what risk it carries (unsupported stack, key-person dependency, compliance exposure), and what changes have been requested and refused in the past year. That last column is the hidden one, and it matters most: it is the business change the current landscape has already blocked.
Organizations that build this inventory get two surprises, reliably. A meaningful share of applications have almost no users — they run because nobody was ever sure it was safe to turn them off. And the riskiest system is rarely the oldest one; it is the one where risk and business-criticality intersect.
Four verdicts per application
Retire is the verdict programs are most reluctant to issue and the one with the best return. If usage is near zero, the project is archiving the data properly and switching the thing off. Every retired app funds the rest of the program.
Keep applies to systems that are healthy and changeable — supported stack, people who can modify it, changes flowing normally. Modernizing these is activity, not progress. Leave them alone and revisit next year.
Rehost fits applications that work fine but sit on the wrong infrastructure — the data center being decommissioned, the OS aging out. Move them; do not be tempted to "improve while we're at it." Scope creep inside a rehost is how a six-week migration becomes a two-year program.
Rebuild is reserved for the intersection that matters: business-critical and frozen. These are the systems where the inability to change is actively costing the business — and they are where the modernization budget should concentrate. For how a rebuild actually runs — mapping business rules from behavior, migrating data with reconciliation, parallel running before cutover — see the four-path comparison in the diagram below and our deep dive on legacy application modernization services.
What the program costs — and what changed
Traditional enterprise application modernization pricing is dominated by the rebuild column: agency rewrites of a single mid-sized business application historically ran $100,000 to $500,000, and multi-system programs comfortably reached seven figures. That arithmetic is why so many inventories got built and then shelved — the portfolio view revealed more rebuild candidates than any budget could fund.
AI agents changed the marginal cost of the rebuild verdict specifically. The expensive mass of a rebuild — screens, workflows, validations, reports, permissions — is what agents produce quickly when grounded in real rules and data; human attention concentrates on business-rule mapping, data migration, and verification. On Evonx's modernization flow, a rebuild starts with a running preview within minutes and proceeds slice by slice at platform-subscription economics rather than per-project bids. The practical consequence for the portfolio: rebuild verdicts that were unaffordable at agency prices become sequenceable — two or three systems a year instead of one every three years.
Sequencing: the program that survives
Three rules keep a modernization program alive past its first year. Retire before you rebuild — the quick wins fund credibility and budget. One rebuild at a time per team — parallel rebuilds compete for the same subject-matter experts, and both starve. Every quarter ships something a user can click — programs die when their only outputs are documents. A modernization program with a working slice in production every quarter is unkillable; one with a two-year roadmap and no running software is already dead, whatever the steering committee says.
The starting move is the same regardless of scale: build the inventory, issue the four verdicts, retire the easy ones, and take the single worst intersection of critical-and-frozen into a first rebuild slice. If you want to see what that first slice looks like when agents do the heavy lifting, describe the system — the preview arrives before the steering committee's next meeting.