Most IT budgets are spent before the year starts. The systems already in production take the bulk of it, and modernization competes for what is left, one business case at a time.
An IT modernization strategy changes that by deciding, for the whole portfolio, which systems to invest in, which to fix, which to retire and how the savings pay for the next step. This guide walks through the assessment, the funding, the roadmap, the governance and the metrics.
Why modernization needs a strategy, not a list of projects
Upkeep crowds out change. The UK government's State of digital government review found that organizations such as DWP and NHS England spend 70 to 85% of their technology budgets on upkeep, against 67 to 70% in heavily regulated private industries and about 60% among digital leaders. US federal agencies report about 80% of more than $100 billion a year going to operations and maintenance of existing IT (GAO, 2025).
The legacy share keeps growing while projects are argued one by one. In UK central government, legacy systems made up an estimated 28% of systems in 2024, up from 26% in 2023, and 28% of red-rated legacy systems lack remediation funding. GAO's list of the 11 US federal systems most in need of modernization ranges from about 23 to 60 years old and costs about $754 million a year to run; agencies had modernization plans for nine of them.
Large programs do not fix this reliably either. BCG found that 70% of digital transformations fall short of their objectives (BCG, 2020). A strategy that works sits between the two: decisions made once for the whole portfolio, delivered in small, funded steps that each show a result.
An IT modernization strategy has to answer four questions:
- Which systems change, which stay as they are and which are retired?
- In what order, given the engineers and the budget available?
- How is the work funded beyond the first year?
- Who decides, and how is progress measured?
Step 1: application portfolio assessment
An application portfolio assessment scores every application on two independent axes, business value and technical health, from evidence that can be collected in a few weeks.
| Business value: what to collect | Technical health: what to collect |
|---|---|
| The business capability it supports and its owner | Language, framework and runtime versions, with their support end dates |
| Users, transactions or revenue that depend on it | Open vulnerabilities by severity, and how many need a major upgrade to fix |
| How often the business asks for changes to it | Change lead time and change fail rate |
| Regulatory or contractual obligations it carries | Incidents in the last year and their cost |
| Whether another application already does the same job | Run cost: hosting, licences, support contracts, people |
| What stops if it is down for a day | Test coverage of critical rules, and how many people can change it |
Score each axis from 1 to 5 with written criteria, so two people scoring the same application land on the same number. Record the evidence next to the score; a score without evidence turns the next steps into negotiation. For the technical side of a single Java system, our application modernization guide includes a worksheet.
Step 2: portfolio triage with the TIME model
Gartner's TIME model (Tolerate, Invest, Migrate, Eliminate) turns the two scores into four actions.
- Invest: high value, good health. Keep funding new features; keep versions current so the application stays here.
- Migrate: high value, poor health. These are the modernization candidates, and the order among them is the main decision of the strategy.
- Tolerate: low value, good health. Leave alone, patch on schedule, spend nothing extra.
- Eliminate: low value, poor health. Retire, consolidate into another application or replace with a packaged product.
Two caveats make the triage useful. First, check dependencies across quadrants: a Tolerate application that feeds a Migrate one may need to move with it. Second, "Migrate" is a category, not a method. For each application in it, choose between keeping and containing it, upgrading in place, rearchitecting in slices and replacing it; our legacy system modernization guide sets out how to choose.
Step 3: funding modernization in waves
Modernization funded as one large program competes with every other program each budget round and often stops halfway. Deloitte puts the average IT department's spending at 55% on maintaining business operations and 19% on new capabilities (Deloitte Insights). The way out is to fund modernization from the upkeep line itself, in waves:
- Retire first. Eliminate applications release licences, hosting and support effort within months, and the first wave's savings are the easiest to prove.
- Then the nearest deadline. Among Migrate applications, start with the one whose platform leaves support first, because its cost rises on a known date: extended support fees, then unpatched vulnerabilities. Our Java end-of-life calendar gives the dates for Java systems.
- Recycle the savings. Book what each wave saves in run cost and move it into the next wave's budget. A finance partner who agrees the accounting up front makes this credible.
- Fund teams, not projects. A persistent team per product area, with a fixed share of capacity for modernization, does not lose its funding when a project closes.
Each wave needs a business case of its own, with the run cost before and after, the risk removed (vulnerabilities, unsupported versions, single points of knowledge) and the change in delivery speed.
Step 4: the modernization roadmap
A modernization roadmap puts the waves on a calendar with entry and exit criteria, so the portfolio moves in steps that can each be checked.
| Wave | Scope | Exit criteria | Funding |
|---|---|---|---|
| 0: Baseline | Inventory, scores, TIME triage, metrics in place | Every application scored with evidence; dashboard live | Small, fixed budget |
| 1: Retire and patch | Eliminate applications; supported patch levels for the rest | Applications switched off; no critical vulnerabilities with an available patch | Existing run budget |
| 2: First Migrate application | The highest-value application with the nearest deadline | On supported versions, with lead time and incident targets met | Wave 1 savings plus a ring-fenced share |
| 3 onward: Next Migrate applications | One or two at a time, by value and deadline | The same per application | Recycled savings |
Limit how many applications are in progress at once. Engineering capacity sets the pace of any modernization, and five half-finished migrations cost more than two finished ones.
Governance that does not slow the work
Governance in a modernization program has two jobs: keep the portfolio decisions current and keep individual teams moving. It needs less ceremony than most programs give it.
- A quarterly portfolio review re-scores applications that changed, checks each wave's exit criteria and funds the next wave. Business owners attend; the technical scores come from the dashboard, not from slides.
- Architecture decision records for choices that cross teams, such as a target runtime, an integration pattern or a data platform, written once and linked from every project that follows them.
- Guardrails instead of approvals. A supported template for new services (build pipeline, observability, security scanning) lets teams comply by default and saves a review board for the exceptions.
- Cost visibility. In Flexera's 2026 survey, cost was the top cloud challenge for 85% of organizations, and wasted cloud spend rose to 29% (Flexera). Modernized applications that move to the cloud need an owner for their bill from the first day.
Metrics for an IT modernization strategy
Measure outcomes, not activity. Migrations started and story points delivered say little; the metrics below show whether the portfolio is getting healthier and cheaper to change.
| Area | Metric | Why it matters |
|---|---|---|
| Portfolio health | Share of applications on supported versions; applications retired | The direct measure of platform debt |
| Cost | Upkeep share of the technology budget; run cost per application | Shows whether savings are real and available for the next wave |
| Risk | Open critical vulnerabilities; days a critical one stays open | What a regulator or auditor will ask first |
| Delivery | DORA's change lead time, deployment frequency, change fail rate, failed deployment recovery time and deployment rework rate | Whether modernized systems actually change faster and break less |
| Business | Time from a business request to production for the applications in scope | The number business owners recognize |
DORA's five delivery metrics are worth adopting as they are, because they come with published definitions and benchmarks. They also show whether AI coding tools help: DORA's 2025 research describes AI's primary role as "an amplifier, magnifying an organization's existing strengths and weaknesses" (DORA, 2025). In a portfolio full of untested, unsupported code, AI tools speed up the wrong things.
Why IT modernization strategies stall
The failure patterns repeat across organizations:
- Nothing is retired, so the run budget never shrinks and every wave needs new money.
- The program is funded as one project and stops when the budget year ends.
- Too many applications are in flight at once, so none reaches its exit criteria.
- Scores are opinions, so every portfolio review reopens the triage.
- Progress is reported in activity, and the business sees no change in how fast it gets what it asks for.
For the Java part of a portfolio, our Application Modernization Sprint starts with a thirty-minute scoping call and a written ballpark within a week. The first iteration maps versions, support dates and vulnerabilities across the applications in scope, and sets the order of work.