Published November 11, 2026
What the job is
Application rationalization is a review of every application the organization runs. It ends in a decision for each one: keep it, invest in it, replace it, consolidate it with another, or retire it. Then the decisions have to be carried out.
Tie the program to a date: a data center exit, a cloud migration, a merger, a budget target or a large renewal. AWS and Microsoft both list retire as one of the strategies to assign each workload before a cloud migration.
The savings arrive when an application is switched off and its licenses, support, hosting and staff time end.
This page is for the people who will run the program: the decision, the options, the order of the work, what takes longer than planned, and what to settle before starting.
The decision for each application
Each application needs a disposition, an owner who agrees to it and a date. The inputs are business value, technical condition and cost. The Federal CIO Council's 2019 Application Rationalization Playbook scores applications on business value, technical fit and total cost of ownership, then decides placement using the scores and stakeholder input.
Some applications should stay even when the scores say retire. An application may hold records the organization must keep and that exist nowhere else. It may run a job once a quarter or once a year that nobody remembers. A regulator, a customer contract or another application may depend on it. Its retirement may cost more than running it for its remaining life.
Record the reason for every keep decision. The next review then starts from the reason, not from the beginning.
The options
| Disposition | When it fits | What it involves |
|---|---|---|
| Retain | The application is stable, meets the need and has no driver to change. | No change now. Review it again in the next cycle. |
| Invest | The application is high value and technically strong. | Funding for upgrades or expansion. SAP's description of Gartner's TIME framework calls this invest. |
| Replace | A SaaS product meets the need with little customization. | Selection, data migration, integration with identity, user training. Microsoft calls this replace; AWS calls it repurchase. |
| Consolidate | Two or more applications do the same job. | Move users and data onto one, then retire the others. |
| Rehost or replatform | The application stays but its hosting changes. | Move it as is, or with some optimization, to new infrastructure or a managed service. |
| Retire | The application has limited current or future business value. | Archive the data, end the contracts, shut down the servers, remove access. |
The frameworks name the options differently. AWS uses seven: retire, retain, rehost, relocate, repurchase, replatform and refactor. Microsoft's Cloud Adoption Framework uses eight: retire, retain, rehost, replatform, refactor, rearchitect, rebuild and replace. Pick one vocabulary and use it in every decision record.
The order of the work
- Set scope and governance. Decide which business units and application types are in scope, who makes decisions, who can appeal, and the date the program works back from.
- Build the inventory. Start from the CMDB, then add contracts and invoices, single sign-on logs, expense reports and network data to find what the CMDB misses. Record the owner, users, business capability, contracts and renewal dates, hosting, integrations and the data each application holds.
- Name an owner for each application. An application with no business owner after a set period becomes a retirement candidate.
- Assess value, condition and cost. Ask owners about business value. Ask technical teams about supportability, security and integration. Take cost from invoices and hosting bills, not estimates.
- Decide in batches. Bring groups of applications to a standing forum. Record each disposition with its owner, date and reason.
- Retire early and in waves. AWS recommends identifying and retiring applications early in a migration, so an application found to be needed can still move in a later wave.
- Close out and report. End the contracts, shut down the servers, remove the accounts and update the inventory. Report savings when the invoices stop.
What takes longer than expected
- Ownership. AWS notes that the risk in a retirement decision can lead to it being postponed, especially when subject matter experts have left and documentation is sparse.
- Dependencies. AWS's guidance warns that architecture diagrams and institutional knowledge can be outdated or incomplete. It recommends monitoring each server's inbound and outbound network connections, then following the chain: if the application writes a file to a share, find which system reads that file.
- The controlled stop. AWS describes simulating retirement by blocking traffic with a firewall, pausing the virtual machine or stopping a service, then watching for impact. It notes that a one-week stop may not be enough for a batch workload that runs once a month or once a quarter.
- Archive decisions. AWS notes that regulatory or compliance requirements may require keeping an application's data after it is retired. Get legal, finance and records teams to agree what to keep, for how long and in what form before the application goes.
The detail plans leave out
- Interfaces on the other side: the systems that send data to the application or receive data from it, and the jobs that move it.
- Reports, spreadsheets and extracts that users built on the application's data.
- Service accounts, API keys, certificates, DNS entries and firewall rules that still point to it.
- Licenses and support contracts that keep billing after shutdown.
- Backups that contain the application's data and fall under the same retention rules as the archive.
- Storage media from the retired servers. NIST SP 800-88 Revision 2, published September 26, 2025, is NIST's guidance for media sanitization. It supersedes Revision 1 (2014).
Contracts, records and cost
Contract dates decide when a retirement saves money. Collect these for every application before deciding:
- The renewal date and the notice period.
- Any minimum term, termination fee or right to reduce users at an anniversary.
- For SaaS, how the vendor returns your data at exit, in what format, and whether it certifies deletion.
- Who signed the contract and who holds the budget for it.
Retired systems often hold financial records. IRS Revenue Procedure 98-25 requires machine-sensible records to be kept as long as their contents may become material to tax administration, at minimum until the period of limitation for assessment expires. For each retained file it requires record layouts, field definitions and file descriptions. An archive that keeps the data but loses that documentation does not meet it.
Set a cost baseline per application before the first decision: licenses, support, hosting and staff time. Without it, nobody can show what the program saved.
Skills and operations
The program needs a portfolio lead or enterprise architect, someone from procurement who can read the contracts, a records or legal contact, and time from each application's business owner.
A rationalization is not a one-off. The CIO Council playbook describes its six steps as a loop. Put new applications through an intake gate that records owner, contract and data from day one, and repeat the review on a fixed cycle.
Users of a retired application need a date, a replacement and training.
Settle these first
- What date does the program work back from, and what savings does it have to show by then?
- Who decides, and who can overrule an application owner?
- Where will the inventory live after the program ends?
- Who decides what data is archived, for how long and in what form?
- Which contracts renew in the next 12 months, and what are their notice periods?
- How long will a controlled stop last for applications with monthly, quarterly or annual jobs?
Questions
- How is application rationalization different from application portfolio management?
- Portfolio management is the ongoing practice of keeping the inventory and reviewing it. Rationalization is a program within it that ends in a decision for each application and carries those decisions out.
- How do we find applications that are not in the CMDB?
- Compare the CMDB with contracts and invoices, single sign-on logs, expense reports and network traffic. Each source can show applications the others miss.
- How do we know an application is safe to retire?
- Check its inbound and outbound network connections for dependencies, then run a controlled stop: block traffic or stop the service and watch for impact. Make the stop long enough to cover jobs that run monthly or quarterly.
- What happens to the data when we retire an application?
- Archive what you must keep, in a readable format, with its documentation. For US tax records, IRS Revenue Procedure 98-25 requires machine-sensible records to be kept at least until the period of limitation for assessment expires, with record layouts and field definitions.
- Which framework should we use to label applications?
- Any one, used consistently. AWS uses seven strategies, from retire to refactor. Microsoft's Cloud Adoption Framework uses eight, from retire to replace.