CIOPages
Back to Insights
GuideTechnology

Application portfolio rationalization: how to inventory, decide, retire and count the savings

A five-step application portfolio rationalization method: the data to collect, how to score and decide, how to retire an app safely, and how to count savings finance will accept.

CIOPages Editorial Team 9 min readOctober 22, 2026

AI Advisor · Free Tool

Technology Landscape Advisor

Describe your technology challenge and get an AI-generated landscape analysis: relevant technology categories, key vendors (commercial and open source), recommended architecture patterns, and a curated shortlist — all tailored to your industry, organization size, and constraints.

Vendor-neutral analysis
Architecture patterns
Downloadable Word report

Application portfolio rationalization is a decision made for every application in the estate: keep it as it is, invest in it, migrate it to something else, or retire it. The method has five steps. Collect only the data those decisions need. Score business fit and technical condition separately. Give each application one disposition, with an owner and a date. Retire applications through a fixed sequence covering dependencies, data and contracts. Count savings when an invoice stops, not when a decision is made. Why application rationalization programs stall at the inventory covers programs that stop after the first step. This piece covers all five.

Step 1: Collect the fields a decision needs

An inventory is useful when every row can support a decision. A complete list of names with no owners or costs supports none.

Field What it decides Where it usually comes from
Business owner (a named person) Who can approve retirement Finance cost centers, the service catalog, interviews
Technical owner Who does the work CMDB, support group assignments
Business capabilities supported Where two applications overlap Enterprise architecture repository, workshops
Active users, last 90 days Whether anyone still uses it Identity provider logs, application login logs
Annual run cost, split by license, hosting, support and labor What retirement would save Invoices, cloud bills, contract register, timesheets
Contract end date and notice period When retirement is cheapest Contract register, procurement
Vendor support status Technical risk and deadline Vendor lifecycle pages
Integrations in and out What breaks when it goes Integration platform, network flows, interviews
Data held and its retention requirement What has to be kept after shutdown Records management, legal
Known security issues Risk of keeping it Vulnerability scanner, risk register

Cost and age are the fields hardest to fill. The National Archives and Records Administration's inspector general audited NARA's legacy systems in 2018 (report 18-AUD-06). It found NARA "does not know the true cost of all its systems" and "has not documented the age of their systems." License data has the same gap. GAO's 2014 review of federal software licenses (GAO-14-413) rated 24 major agencies on tracking and maintaining a license inventory. None had fully implemented it; 20 had partially implemented it and 4 had not.

Start with the 50 applications that cost the most, plus any that are out of vendor support. Fill every field for those before adding rows.

Step 2: Score business fit and technical condition separately

Score each application on two axes, with different people scoring each.

  • Business fit, scored by the business owner: how well it supports the capability it serves, whether that capability matters to strategy, and whether another application already does the same job.
  • Technical condition, scored by architects and operations: vendor support, security exposure, integration complexity, skills available to maintain it, and run cost relative to similar applications.

Keep the two scores apart. A combined score hides the case that matters most: an application the business values that is technically failing. That case calls for migration, and a single number would average it into "fine."

Use a short, published scale. GAO's 2025 review of federal legacy systems (GAO-25-107795) is a public example. GAO collected 69 systems from agencies and "scored these systems based on 16 system attributes and associated point values, such as age, vendor support," legacy programming languages, cybersecurity risk and operating costs. It selected 11 as most in need of modernization. Their ages, from the report's Table 1, ranged from 23 to 60 years.

Step 3: Give each application one disposition

The two scores sort applications into four dispositions. They are often abbreviated TIME: tolerate, invest, migrate, eliminate.

Business fit Technical condition Disposition What it commits you to
High Good Invest Funding for enhancement; it becomes a consolidation target for overlapping apps
Low Good Tolerate No new investment; review again at contract renewal
High Poor Migrate A named target platform and a migration date
Low Poor Eliminate A retirement date and a data plan

Every disposition needs three things recorded next to it: the person who approved it, the date it takes effect, and for migrate and eliminate, the date the old system stops running.

Where two applications serve the same capability, decide which one survives before scoring either in isolation. Prefer the one with more active users, current vendor support and the later contract end date.

Step 4: Retire in a fixed sequence

Retirement fails on four things: an unknown dependency, data with nowhere to go, a contract that renewed, and an access path nobody closed. Work through them in this order.

Find the dependencies. Ask the owners, then check the evidence. Look at network flow logs, database connection logs, integration platform and ETL job definitions, the job scheduler, service accounts and API keys, file shares the application writes to, and report subscriptions. Observe for a full business cycle, including a month-end and a quarter-end. Year-end jobs will not show up in a 30-day window, so ask finance which processes run once a year.

Reduce access in stages. Make the application read-only. Then disable logins for everyone but an administrator, and keep the servers running for an agreed period. A user who was missed will call during that period, while the application can still be turned back on in minutes.

Decide where the data goes. Records management and legal set how long each data set must be kept. For US federal agencies, 36 CFR 1236.14(a) requires agencies to "Determine if the NARA-approved retention period for the records will be longer than the life of the system where they are currently stored. If so, plan for the migration of the records to a new system before the current system is retired." The same section requires "Maintaining a link between records and their metadata through conversion or migration." Private companies face their own retention rules by industry and jurisdiction; the planning question is the same. For each data set, choose one: migrate it into the successor, move it to a read-only archive with its metadata, or dispose of it once its retention period has ended. Test that someone can find and read a record in the archive before the source is switched off.

Time the contracts. Find the renewal date and the notice period for every license, support agreement, hosting contract and third-party component tied to the application. The notice deadline is the real deadline. Missing it can buy another full term. Schedule the switch-off so that notice is sent before that deadline, even if that means starting the retirement earlier.

Sanitize and record. Decommission servers and storage using NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization (September 2025), or your own equivalent standard. Delete service accounts, firewall rules, DNS entries, backup jobs and disaster recovery copies. Then mark the application retired in the CMDB and the EA repository with the date.

GAO counts retirement as part of modernization. In GAO-25-107795 the three key elements of a modernization plan are "(1) milestones, (2) a description of the work, and (3) details regarding disposition of the legacy system."

What happens when the old system keeps running

NARA's Electronic Records Archives was meant to absorb several older systems. In 2012 the inspector general's Advisory Report 12-08 found NARA spending almost $7 million a year to operate and maintain eight of them. The 2018 audit put the total at approximately $33 million in operations and maintenance through fiscal 2017, plus more than $12 million to develop a new system, DAS. It estimated continuing costs of about $5 million a year until the remaining systems were integrated.

The audit gives the main cause as OMB's decision to end ERA development early, before the legacy functions were moved. It also found NARA "did not identify and implement compensating controls over all legacy systems associated with ERA." The figures came from NARA's Information Services office, and the inspector general states it "was not able [to] verify the accuracy of these numbers." The replacement went live, the retirements were not funded, and the old systems kept costing money for years.

Step 5: Count savings when an invoice stops

Rationalization business cases are full of estimates. GAO's review of OMB's PortfolioStat initiative (GAO-14-65, November 2013) shows how far estimates can drift. OMB put potential savings at $2.5 billion. GAO counted about 200 opportunities and at least $5.8 billion through fiscal 2015, because OMB's figure left out the Departments of Defense and Justice. GAO also found that "four agencies did not always provide sufficient support for all of their estimates." Both numbers were forecasts. Neither was money that had stopped going out.

Report savings in a way finance would accept.

  • Baseline from invoices. Use the last 12 months of actual spend per application: license, support, hosting and contracted labor.
  • Count on the stop date. A saving starts on the date the last invoice is paid or the cloud resource is deleted, not on the date the disposition was approved.
  • Net out the new costs. Subtract archive storage, migration work, extra licenses on the successor system, and the months both systems ran in parallel.
  • Separate cash from capacity. Removing a virtual machine from a shared cluster saves nothing until the cluster shrinks or a planned purchase is canceled. Staff time freed up is capacity, not cash, unless the budget goes down.
  • Report avoided costs on their own line. An upgrade you no longer need to buy is real, but it was never in the budget, so it does not reduce spend.

Run the review quarterly. Report the number of applications switched off and the annual spend that stopped with them.

Count the invoices that stopped

Report retirements and stopped spend, and nothing else, to the steering committee. A rationalization program that reports applications assessed can grow that number indefinitely without retiring anything. One that reports applications switched off, with their final invoice dates, cannot.

Frequently asked questions

What is the TIME model in application rationalization? TIME stands for tolerate, invest, migrate and eliminate. Each application is placed in one category by scoring its business fit and its technical condition. High fit and good condition means invest. Low fit and good condition means tolerate. High fit and poor condition means migrate. Low fit and poor condition means eliminate.

Do we need a complete inventory before retiring anything? No. Fill every decision field for the most expensive applications and those out of vendor support, and start retiring the clear eliminate cases. The first retirements show where your data, dependency and contract problems are.

Is application rationalization the same as application portfolio management? Application portfolio management is the ongoing practice of keeping the inventory, scores and dispositions current. Rationalization is the cycle of decisions and retirements that practice supports.

Sources, all retrieved October 22, 2026: GAO, "Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems" (GAO-25-107795), July 17, 2025. GAO, "Information Technology: Additional OMB and Agency Actions Are Needed to Achieve Portfolio Savings" (GAO-14-65), November 6, 2013. GAO, "Federal Software Licenses: Better Management Needed to Achieve Significant Savings Government-Wide" (GAO-14-413), May 22, 2014. NARA Office of Inspector General, "Audit of NARA's Legacy Systems" (18-AUD-06), March 29, 2018, pages 12 to 14; the Advisory Report 12-08 figures are as quoted in that audit. 36 CFR 1236.14, via Cornell's Legal Information Institute. NIST, SP 800-88 Rev. 2, September 2025. What would make this wrong, and when: NIST revises SP 800-88 and NARA amends 36 CFR Part 1236 from time to time; check both before relying on the quoted text. GAO's legacy-systems reviews recur every few years; if a later one replaces GAO-25-107795, update the attribute count and ages.

Related Reading

Application RationalizationApplication Portfolio ManagementIT Portfolio ManagementLegacy ModernizationCost Optimization
Share:
The Throughline
One decision facing technology leaders, monthly.

Independent. No sponsorships. Unsubscribe anytime.