Cost is one of the most common reasons organizations launch an application rationalization effort, but it is also one of the most poorly understood. Leaders usually know they are spending too much on software and support, yet they often cannot explain which applications absorb the most money, which costs are structural, and which costs would actually disappear if a system were retired. That gap matters because weak economics leads to weak decisions. A team may target the most visible license spend while ignoring older applications that consume more through infrastructure, support effort, interfaces, and workarounds. This chapter builds the economic lens for rationalization: what an application truly costs, where hidden burden sits, what value can realistically be captured, and how to compare options in a consistent way. Used well, this lens helps teams distinguish between applications that are expensive to run and applications that are expensive to avoid.
10.1 Total Cost of Ownership by Application
Total cost of ownership, or TCO, is the most useful cost concept in application rationalization because it captures the full cost of keeping an application alive, not just the invoice a vendor sends. Many organizations know only fragments of this picture. They know the software maintenance line or the SaaS subscription fee, but not the hosting charges, the internal support effort, the enhancement backlog, the contractor spend, or the reporting activity that exists because the application is part of the landscape. A rationalization program needs a broader view.
A practical TCO model should start with direct spend. Software cost: subscription fees, maintenance fees, license renewals, usage-based charges, and support entitlements paid to the vendor. Infrastructure cost: servers, storage, database licensing, middleware, cloud consumption, backup, monitoring, and disaster recovery environments. External services cost: managed services, specialist contractors, vendor support retainers, enhancement partners, and testing or release support purchased externally. These items are usually the easiest to identify because they leave financial and contractual records.
The harder part is internal effort. Application support labor: incident management, problem resolution, release management, user administration, patching, minor enhancements, and business support. Shared technology labor: database administration, middleware support, platform engineering, cloud operations, security operations, and service desk time attributable to the application. Business support labor: super users, local coordinators, reconciliation teams, and business analysts who spend time because the application requires attention, workarounds, or special knowledge. These costs are rarely booked neatly at the application level, yet they are real and often substantial.
For rationalization, perfection is less important than consistency. A usable TCO estimate does not require activity-based costing for every minute of support time. It requires a structured estimate that is applied the same way across the portfolio. If one application includes license and infrastructure costs but another includes only license cost, the comparison is distorted. The team should therefore define a standard cost perimeter and apply it systematically. Where precise allocation is not possible, use directional estimates with explicit confidence levels.
It is also important to separate run cost: the ongoing annual cost of operating the application, from change cost: discretionary investment in projects, enhancements, upgrades, and compliance work. Both matter. Run cost shows the burden of the current estate. Change cost shows where the organization is already spending to compensate for age, fragmentation, or new requirements. An application with moderate run cost but high recurring change cost may be a stronger rationalization candidate than a stable system with higher but predictable operating cost.
TCO should be assessed at the right level of granularity. Some packaged platforms host multiple business solutions or modules. Some custom applications share infrastructure and support teams. In those cases, forcing every cost to a single named application can create false precision. The better answer is often to estimate cost at the application cluster or platform level, then note how the cost behaves if one component is retired.
Contract timing should be integrated directly into TCO. A system with modest annual spend may still be economically unattractive if it is approaching a major renewal, upgrade, or hardware refresh. Likewise, a legacy application with low visible cost may in fact be protected by underinvestment; its economics can change sharply once mandatory remediation is recognized. TCO therefore needs both a current-year view and a forward-looking view.
A practical three-part TCO view is often enough for leadership discussion. Current annual run cost: what the application costs to operate today. Known future obligations: renewals, upgrades, compliance remediation, or infrastructure changes likely within the next two to three years. Support intensity: the level of internal and external effort required to keep the application serviceable.
10.2 Hidden Costs: Interfaces, Manual Workarounds, Reporting Layers, and Local Support
The most misleading application economics are usually not wrong because the direct costs are inaccurate. They are wrong because the surrounding costs are invisible. Many applications look cheap when viewed in isolation. They become expensive when the organization recognizes everything that exists because the application exists. These hidden costs are one of the main reasons leaders underestimate the value of simplification.
Interfaces: every integration has a cost, even when no explicit invoice is attached to it. Interfaces need design, monitoring, failure handling, version management, incident resolution, data reconciliation, testing, and often manual intervention when something breaks. In mature portfolios, many interfaces are also business logic carriers. They transform codes, apply rules, split or combine records, and route exceptions in ways that are poorly documented. When an application requires many interfaces to remain useful, those interfaces are part of its economic footprint.
Manual workarounds: these are among the most expensive hidden burdens because they are dispersed across teams and therefore rarely visible in IT budgets. Users may rekey data between systems, correct outputs in spreadsheets, run local reconciliations, route approvals by email, maintain reference tables manually, or build end-of-period workarounds around weak system behavior. None of these activities appears as a software line item, yet all of them consume labor and introduce risk. In some portfolios, the manual effort created by fragmented applications exceeds the direct technology savings that local teams believe they gained by keeping specialized tools.
Reporting layers: one application often creates several reporting artifacts around it. There may be a local data mart, a BI model, extracts to enterprise reporting, operational spreadsheets, ad hoc databases, or shadow dashboards built because standard reports are missing or too slow. These layers are often defended as reporting needs rather than application costs, but in rationalization terms they belong together. If an application requires a separate reporting ecosystem to make it usable, that ecosystem should be counted in its economic burden.
Local support: decentralized environments often accumulate small teams, part-time coordinators, super users, local administrators, and external boutique vendors who exist because a given application or local variant remains in place. Their costs are easy to dismiss individually and hard to aggregate centrally. Yet when the estate is viewed by domain, it becomes clear that many of these roles are symptoms of fragmentation. Standardization often creates value not because the central platform is dramatically cheaper by itself, but because the organization no longer needs dozens of local support arrangements.
There are other hidden costs worth surfacing. Training burden: multiple tools require multiple training paths and onboarding materials. Testing burden: every change to an integrated landscape creates more regression testing and coordination. Vendor management burden: more applications mean more renewals, escalations, and compliance reviews. Delay cost: fragmented estates make transformation programs slower because every new initiative must accommodate more exceptions and interface points. Delay cost is not always easy to quantify, but it is often strategically significant.
A simple method helps uncover these hidden costs. First, trace the process end to end and note every manual handoff, spreadsheet, extract, interface, and report that exists around the application. Second, ask who owns each item and how much time it consumes monthly or at peak periods. Third, determine whether the item would still exist if the application were replaced or consolidated into a strategic platform. This exercise often reveals that the application is not a standalone system at all, but the center of a small ecosystem of compensating controls and support structures.
The goal is not to inflate every business inconvenience into a monetized cost estimate. The goal is to make structural burden visible. When that burden is visible, rationalization decisions become more accurate. Applications that look cheap often turn out to be expensive to preserve. Applications that looked costly sometimes turn out to be efficient once the surrounding complexity of alternatives is considered.
10.3 Estimating Savings From Retirement, Consolidation, Renegotiation, and Modernization
Once the organization understands what an application costs, the next question is what value can be realized by changing it. This is where many rationalization business cases become unreliable. Teams often assume that if an application is retired, its entire cost disappears immediately. In practice, some costs vanish quickly, some phase out over time, some are absorbed elsewhere, and some are replaced by transition spending or by increased use of another platform. Sound economics requires more discrimination.
Retirement savings: these are usually the cleanest when an application can be fully decommissioned without a like-for-like replacement. Direct license or maintenance savings, infrastructure removal, external support elimination, and some internal support effort may disappear. But retirement rarely eliminates all costs instantly. Data archival, residual read-only access, contract notice periods, and shared platform costs can delay or reduce realized savings. The right estimate is therefore phased rather than binary.
Consolidation savings: these occur when multiple applications supporting similar capabilities are reduced to a smaller number of standard platforms. Savings often come from license overlap, fewer interfaces, reduced local support, lower training burden, and lower enhancement spend. Consolidation may also create procurement leverage because the enterprise can negotiate around a larger standard deployment rather than many fragmented purchases. The main discipline here is not double counting. If one local tool is retired and its users are absorbed into a strategic platform, the case should include the incremental cost of adding those users, storage, configuration work, or support demand to the target platform.
Renegotiation savings: not every rationalization move involves decommissioning. Sometimes the application remains, but the organization improves economics by reducing unused licenses, eliminating duplicate modules, consolidating contracts, changing support tiers, or renegotiating vendor terms using better enterprise visibility. These savings are real and often faster than deep platform changes. However, they should be distinguished from structural rationalization. A better contract on a redundant application does not remove duplication; it only makes it temporarily cheaper.
Modernization savings: these are the most nuanced because modernization often requires new investment before run costs decline. Savings may come from retiring old infrastructure, reducing manual support effort, lowering failure rates, simplifying interfaces, or moving to a support model that needs fewer specialized skills. In some cases, modernization does not reduce cost materially in the short term but still creates economic value by avoiding looming remediation expenses or by increasing delivery capacity for higher-value work.
One-time costs must always be estimated alongside savings. Migration, data conversion, testing, training, change management, archive creation, parallel run, cutover support, and vendor exit fees can be substantial. The mistake is not that teams include these costs. The mistake is that they compare them only against first-year savings. A retirement or consolidation move with modest first-year payback may still be economically compelling over three years, especially if it avoids a large renewal or remediation event.
Avoiding cost deserves explicit treatment. If a system is due for a major upgrade, database relicensing, hardware refresh, compliance remediation, or contract auto-renewal, exiting it beforehand creates value even if current run cost has been manageable. Avoided cost is often one of the strongest elements in a rationalization business case because it converts a future obligation into a present decision point.
Benefits should also be separated into tiers. Hard savings: budget lines or contracts that can be removed. Soft savings: labor effort that can be redeployed but may not immediately reduce budget. Avoided cost: future spend prevented by acting now. Strategic value: speed, simplification, and reduced risk that may not be booked as savings but materially improve enterprise capacity.
In rationalization, the most credible savings estimates are those tied to specific mechanisms: which contract will end, which server will be removed, which support role will be reduced, which interface will disappear, which upgrade will be avoided, and when each of those events will occur. General claims about efficiency are rarely enough. Leaders want a line of sight from action to realization.
10.4 Building a Simple Economics Model to Support Decisions
The purpose of an economics model in application rationalization is not to produce a perfect finance case for every application. It is to create a consistent, decision-ready view that allows leaders to compare options. The best models are simple enough to use at scale, transparent enough that assumptions can be challenged, and structured enough to avoid the common errors of double counting, overclaiming, and ignoring timing.
A practical model usually works best over a three-year horizon. One year is too short for many consolidation and replacement moves. Five years often introduces too much speculative assumption. Three years is usually long enough to show the value of action while staying close enough to current contracts, roadmaps, and execution realities.
The model should include six fields for each decision case. Baseline annual run cost: the current cost of the application or cluster. Incremental target-state cost: the added cost, if any, of absorbing the capability into another platform or operating model. One-time transition cost: migration, implementation, data, testing, and change cost. Year-by-year savings: hard savings, soft savings, and avoided cost by year. Timing assumptions: contract dates, migration waves, and when savings actually start. Confidence and risk: a simple rating that signals how firm the numbers are and what could delay realization.
A concise template can be used in steering materials:
- Current state: annual run cost and upcoming obligations
- Decision: retire, consolidate, renegotiate, modernize, or retain
- Target state: landing platform or exit method
- Transition cost: one-time investment and major assumptions
- Annualized value: hard savings, soft savings, avoided cost
- Payback view: first-year net impact and three-year cumulative value
- Confidence: high, medium, or low, with the main uncertainty named
Two rules make the model far more credible. First, separate hard savings from everything else. If a contract will not be terminated, or a budget line will not actually disappear, do not present the value as hard savings. Second, show ramp timing honestly. A retirement decision approved in June may not create infrastructure or labor savings until the following budget cycle. Economics that ignore timing often look impressive and then disappoint.
The model should also be used to compare options, not just justify a preferred answer. For example, a legacy application might have three plausible paths: retain and contain, modernize selectively, or replace with an enterprise platform. Each option should be shown with its own transition cost, run-rate effect, avoided cost, and risk profile.
Not every benefit must be monetized. Reduced interface complexity, lower key-person dependency, better control, or faster delivery capacity may be too uncertain to express as precise dollars. They should still be stated explicitly in the case. A finance-grade model should remain honest about what is quantified and what is directional.
The simplest decision output is often the most powerful: a short economics summary beside each application cluster that states current cost, one-time move cost, three-year net value, timing of realization, and confidence level. Combined with business value and technical risk scoring, this gives leaders an integrated basis for action. It keeps economics practical, comparable, and closely tied to real portfolio choices rather than abstract optimization claims.
