Every enterprise application modernization program runs into the same question sooner or later: which system goes first? Knowing what is outdated is not enough. In its 2025 review of federal legacy IT, the US Government Accountability Office (GAO) reported that agencies had completed only three of the ten critical modernizations it flagged in 2019. A workable answer comes from scoring every application on six criteria in a fixed order, so the ranking holds up in budget reviews and under stakeholder pressure.
Why enterprise application modernization needs a prioritization framework
No enterprise can modernize every application at once. Budget, engineering capacity and the organization’s tolerance for change are all limited, so the order of the work matters as much as the method. A prioritization framework turns competing opinions into comparable scores and produces a ranked backlog you can defend.
The problem starts with the portfolio itself. An enterprise may run dozens or hundreds of applications, and every business owner believes theirs is the most urgent. AWS describes the result as analysis paralysis: teams struggle to decide where to begin, so they don’t begin at all.
A bad order is costly. Money goes into a system that is old but rarely used while an exposed one keeps running untouched, or the first project targets the most complex system in the company, overruns, and leadership loses confidence before anything is delivered.
A scoring framework makes every application answer the same questions, on the same scale, with the same evidence. The decision becomes transparent and repeatable, which is what a CFO or board expects before approving a multi-year budget.
Note that prioritization comes before strategy. Deciding which application to modernize first is a different question from deciding how to modernize it. Once the ranking is clear, you can move on to choosing a modernization strategy for each application.
What to prepare before you score
Scoring is only as good as the inventory behind it. For each application, collect a minimum set of facts:
- Ownership and purpose: the business owner, the process it supports and who uses it.
- Technology: language, framework, database, hosting and the support status of each.
- Connections: inbound and outbound integrations, shared databases and batch jobs.
- Cost and stability: annual run cost, recent incidents and open defects.
Most of this lives in a configuration management database (CMDB), discovery tools, finance records and the ticketing system. Gaps are normal, and finding them is part of the value of the exercise.
Score in one workshop with the right owners: business owners for criticality and cost, architects for condition, dependencies and effort, security for risk, and finance to validate the cost figures.
With the inventory in place, score each application in the following order.
A framework to prioritize applications for modernization
Score each application in a fixed order. Business criticality filters out what isn’t worth modernizing. Technical condition, security risk and maintenance cost measure how urgent the need is. Integration dependency decides what must move together, and modernization effort decides what you can deliver first.
| Order | Criterion | Question it answers | Role in the decision |
|---|---|---|---|
| 1 | Business criticality | How much does the business depend on it? | Filter and highest weight |
| 2 | Technical condition | How fragile and hard to change is it? | Need score |
| 3 | Security risk | How exposed is it, and to what data? | Need score and override |
| 4 | Maintenance cost | What does standing still cost each year? | Need score |
| 5 | Integration dependency | What must move with it, or before it? | Sequencing constraint |
| 6 | Modernization effort | How much work and risk does the change involve? | Turns need into delivery order |
The order is deliberate. Filtering first saves you from scoring systems that should simply be retired, and dependency and effort come last because they decide timing, not need.
Business criticality, technical condition, security risk and maintenance cost use a 1–5 scale where 5 means more urgent. Modernization effort uses a 1–5 scale where 5 means more effort. Integration dependency is mapped rather than scored.
Score business criticality
Business criticality measures how much revenue, operations, customers or compliance depend on an application. Score it first, because it decides whether an application deserves modernization budget at all. Applications with low criticality move to a retire, replace or tolerate track instead of the modernization queue.
To score it, look at the process or revenue stream the application supports, the number of users, how long the business can tolerate an outage (its recovery time objective, or RTO), whether it feeds regulatory reporting, and how closely it fits the strategy for the next two to three years.
| Score | What it looks like |
|---|---|
| 1 | A convenience tool; users have a workaround if it goes down |
| 3 | Supports an important process; an outage of a few hours is manageable |
| 5 | An outage stops revenue, customer service or regulatory reporting the same day |
The best evidence comes from a business impact analysis (BIA), the business continuity plan and interviews with business owners.
Applications that score 2 or lower should leave the modernization queue here. They are candidates to switch off, replace with a SaaS product, or keep running as they are. Gartner’s TIME model (Tolerate, Invest, Migrate, Eliminate) is a familiar way to label these decisions. Filtering early can remove a meaningful share of the portfolio and focus scarce engineering time on systems that matter.
Assess technical condition
Technical condition shows how fragile an application is and how hard it is to change. Look at platform support status, code health, test coverage, release speed, incident history and how many people still understand the system. Poor condition raises urgency, because every change to a fragile system carries more risk and takes longer.
The most objective signal is support status. A framework past its end of support no longer receives fixes: AngularJS support ended on December 31, 2021, and .NET Framework 4.5.2, 4.6 and 4.6.1 reached end of support on April 26, 2022. Beyond that, measure complexity hotspots and dead code with static analysis, check test coverage, and look at how often the team releases and how long a small change takes. AWS suggests similar directional metrics, such as production defects and the time needed to make a simple change.
| Score | What it looks like |
|---|---|
| 1 | Supported stack, good test coverage, frequent and routine releases |
| 3 | Some components near end of support; changes are slow but predictable |
| 5 | Unsupported platform, no automated tests, only one or two people dare to change it |
Data sources include SonarQube or a similar tool, CI/CD logs, the ticketing system and vendor lifecycle pages.
One caution: age is not a criterion. A 15-year-old system with clean code, tests and a supported runtime can score lower than a five-year-old one built in a hurry.
Evaluate security risk
Security risk combines how exposed an application is with how sensitive its data is. An internet-facing system that handles personal or payment data on components that no longer receive patches belongs at the top of the list, even if its other scores are average.
Start with the components. Unsupported runtimes, libraries and operating systems can’t be patched, and open critical vulnerabilities matter most when they appear in the CISA Known Exploited Vulnerabilities catalog, because they are already being used in real attacks. Then look at controls: can the application support single sign-on and multi-factor authentication, encrypt data and produce audit logs? Finally, consider exposure and data: whether the system is public or internal, whether it stores personal, payment or health data, and which compliance regimes apply, such as PCI DSS, HIPAA, GDPR or SOC 2.
| Score | What it looks like |
|---|---|
| 1 | Internal only, no sensitive data, patched regularly |
| 3 | Holds sensitive data, but its components are still supported |
| 5 | Internet-facing, sensitive data, components that can’t be patched |
This is not a theoretical concern. GAO found that seven of the eleven federal legacy systems most in need of modernization were operating with known cybersecurity vulnerabilities.
Security also gets an override. An application that scores 5 here moves up the queue regardless of its total score. If it can’t be modernized right away, apply compensating controls immediately, such as network isolation, a web application firewall and tighter access rules, and set a deadline for the permanent fix.
Security risk during modernization itself: Modernization temporarily expands your attack surface. During parallel runs you operate two systems, keep copies of the data and maintain temporary integrations. Factor this into wave planning: avoid running two sensitive cutovers in the same wave if the security team can’t monitor both, and mask production data before it reaches test environments.
Calculate maintenance cost
Maintenance cost is the price of standing still: licenses, extended-support fees, infrastructure, scarce skills and the engineering hours spent keeping the system alive. Score the trend as well as the total, because a cost that grows every year makes each month of delay more expensive.
Build a simple annual total cost of ownership for each application. Include license and extended-support fees, infrastructure or data center costs, specialist staff for skills that are hard to hire (COBOL and mainframe engineers are the usual example), hours spent on incidents and manual fixes, and the opportunity cost of slow changes.
| Score | What it looks like |
|---|---|
| 1 | Low and stable cost |
| 3 | Moderate cost, rising slowly |
| 5 | High cost growing every year, or a large renewal or extended-support fee coming up |
Finance records, vendor invoices, timesheets and ticketing data provide the numbers. The pattern is not unique to the private sector: GAO notes that the US government spends more than $100 billion a year on IT, most of it on operating and maintaining existing systems.
The figure you produce here is your cost of doing nothing. It is the number that turns a technical argument into a business case for enterprise application modernization.
Map integration dependencies
Integration dependency doesn’t tell you whether an application needs modernizing. It tells you when it can be modernized. Map every interface, group tightly coupled systems so they move in the same wave, and decouple shared hubs before you touch what depends on them.
List each application’s inbound and outbound integrations, shared databases, batch jobs and file transfers, point-to-point connections, and whether it is the system of record for any data. Discovery and application performance monitoring tools, network flow data, interface documents and interviews with operations staff will surface most of them.
Instead of a score, the output is a set of dependency groups. AWS Prescriptive Guidance makes the same point for migration waves: applications with unresolved dependencies, such as low-latency calls, need to move at the same time. Three sequencing rules follow:
- Tightly coupled systems move together: Synchronous, low-latency calls or a shared database put applications in the same group and the same wave.
- Hubs are decoupled first: When many systems depend on one application, put an API layer in front of it before changing what sits behind it.
- Blocked benefits wait: An application whose value depends on a system that hasn’t been modernized yet shouldn’t be scheduled ahead of that system.
Skipping dependency mapping is a common source of cutover surprises: an application is modernized successfully, and a downstream report or batch job breaks the next morning.
Estimate modernization effort
Modernization effort estimates how much work, time and risk the change requires. It depends on code size, data migration, available documentation and experts, downtime tolerance and the strategy you are likely to use. Effort doesn’t change whether an application matters, only how soon you can deliver it.
Consider the size and complexity of the codebase, the volume and complexity of data to migrate, how much documentation and expert knowledge remains, how much downtime the business can accept, and the likely approach. Rehosting takes far less effort than rebuilding, so a rough view of the seven modernization strategies helps here.
| Score | What it looks like |
|---|---|
| 1 | A few weeks; the current team can do it |
| 3 | Several months; needs additional skills |
| 5 | A multi-quarter program with complex data migration and missing expertise |
Estimates are most reliable after a short technical review by an architect, such as a legacy system assessment that covers code, data and integrations.
One design choice matters here. Use effort to schedule work, not to discount importance. Some prioritization models multiply business impact by a “readiness” score, which pushes critical but difficult systems to the bottom of the list. Those are usually the systems that need the longest lead time, so they should start early, not last.
How to turn scores into a ranked modernization backlog
Combine the first four scores into a weighted need score, plot it against effort, then apply two adjustments: security overrides and dependency groups. The result is a ranked enterprise application modernization backlog split into quick wins, strategic programs, opportunistic work and systems to tolerate or retire.
A reasonable starting point for the need score is a weighted average: business criticality 35%, technical condition 25%, security risk 25% and maintenance cost 15%. Treat these weights as a starting point and calibrate them with your stakeholders.
Then place each application on a need-versus-effort matrix:
- Quick wins (high need, low effort): First wave. They deliver visible results and prove the approach.
- Strategic programs (high need, high effort): Start the groundwork now, such as knowledge capture, test coverage and API layers, alongside the first wave, and deliver in increments.
- Opportunistic (low need, low effort): Bundle with other planned changes to the same system.
- Tolerate or retire (low need, high effort): Keep stable with minimal spend, using ongoing maintenance for stable systems, or plan the shutdown.
Two adjustments finish the ranking. Any application with a security override moves to the top of its group. Every member of a dependency group takes the rank of its highest-ranked member, because they move together.
A few rules keep the backlog honest:
- Break ties with hard deadlines: When scores are equal, the system facing an end-of-support date or an expiring hosting contract goes first.
- Test sensitivity: Shift each weight by about 10 percentage points. If the top five changes a lot, your scoring criteria are too vague and need tightening.
- Rank a wider pool than you need: AWS Prescriptive Guidance recommends prioritizing two to three times as many applications as you plan to include in a wave, which leaves room for surprises.
- Re-score on a schedule: Review quarterly and whenever something changes, such as a new end-of-support announcement, a major incident, an acquisition or a strategy shift.
Example: prioritizing a six-application portfolio
In this illustrative portfolio, the oldest system doesn’t come first. An internet-facing customer portal on an unsupported framework leads because of its security override and low effort, while the core billing system starts as a long-running strategic program.
The scores use the weights above. They are illustrative, not client data.
| Application | Criticality | Technical | Security | Cost | Need score | Effort | Dependency | Result |
|---|---|---|---|---|---|---|---|---|
| Customer portal (AngularJS, public, personal data) | 4 | 4 | 5 | 2 | 3.95 | 2 | Calls the order management API | Wave 1 (security override) |
| Order management (.NET Framework monolith) | 5 | 4 | 4 | 3 | 4.20 | 4 | Hub for portal, EDI and billing | Strategic: API layer first, then incremental |
| Partner EDI gateway | 3 | 3 | 4 | 3 | 3.25 | 2 | Tightly coupled to order management | Same dependency group as order management |
| Billing (COBOL on mainframe) | 5 | 3 | 3 | 5 | 4.00 | 5 | Shares a database with order management | Strategic: knowledge capture starts in wave 1 |
| Reporting data mart | 3 | 2 | 2 | 2 | 2.35 | 3 | Reads from billing | Tolerate, revisit next quarter |
| HR leave tool | 2 | – | – | – | Filtered out by criticality | – | – | Replace with SaaS |
The resulting plan has three waves:
- Wave 1: Modernize the customer portal, replace the HR leave tool, and start documenting the business rules inside billing.
- Wave 2: Put an API layer in front of order management and move the EDI gateway with it as one dependency group.
- Wave 3: Modernize billing in increments, using the API layer and the knowledge captured earlier.
Billing is the oldest and most expensive system, yet it isn’t first. It isn’t forgotten either: its preparation starts in wave 1.
Prioritization mistakes that derail enterprise application modernization
Most prioritization mistakes come from relying on a single factor: age, the loudest stakeholder or technical difficulty. Ranking by one factor ignores dependencies and security exposure, and it produces a backlog that falls apart at the first cutover.
- Ranking by age: An old system can be stable, cheap and low risk. Score condition, not birthdate.
- Choosing the hardest system as the pilot: The first wave should prove the approach and build confidence, not carry the biggest risk in the portfolio.
- Letting the loudest voice decide: A shared scale and visible evidence keep the ranking from following whoever argues hardest.
- Ignoring dependencies: Modernizing one system in isolation can break reports, batch jobs and partner feeds downstream.
- Treating retire or tolerate as failure: Switching off or freezing low-value systems frees budget for the ones that matter.
- Scoring once: Portfolios change. A ranking that isn’t revisited becomes another outdated document.
Successful enterprise application modernization depends on doing the right work in the right order. Filter the portfolio by business criticality, measure need through technical condition, security risk and maintenance cost, then sequence the work by integration dependency and effort. The result is a ranked backlog that puts exposed and business-critical systems first, starts long programs early and gives leadership a plan they can trust.
Relipa
Relipa is a Vietnam-based software development company established in April 2016. After two years of growth, our Japanese branch, Relipa Japan, was officially founded in July 2018.
We provide legacy system modernization services from assessment and consulting to re-engineering, data migration, integration and ongoing support. If you are planning to modernize your applications, our team is ready to help you build the right roadmap.
