Application rationalization efforts often struggle for a simple reason: organizations start gathering data before they agree on what they are trying to achieve. One leader wants savings, another wants standardization, another wants better controls, and another wants to clear the way for cloud or platform change. Those are all legitimate goals, but they imply different choices about scope, timing, and decision criteria. This chapter focuses on the framing decisions that should be made before the inventory and scoring work begins. It explains how to set the ambition level, how to define the boundaries of the effort across business and technology dimensions, how to decide which types of applications belong in the review, and how to establish a realistic time horizon with success criteria that can guide execution.
3.1 Setting the Ambition Level: Cost Takeout, Simplification, Modernization, or Control
Every rationalization effort needs a declared ambition. Without one, stakeholders assume the program serves their own priorities. Finance expects savings. Enterprise architecture expects standardization. Security expects risk reduction. Business leaders expect minimal disruption. The result is predictable: the team spends months collecting facts while senior leaders debate what counts as a good outcome. A clear ambition does not solve every disagreement, but it does give the program a hierarchy of priorities.
A cost takeout ambition is the most common starting point. The organization reviews the estate to remove duplicate tools, reduce licenses, cut support effort, avoid infrastructure expense, and stop renewing low-value contracts. This ambition has one major advantage: it is easy to explain and usually wins executive attention quickly. But cost cannot be the only lens. A system that looks expensive may still be business-critical, deeply integrated, or the wrong candidate for near-term change. Cost-led rationalization works best when it is framed as targeted simplification rather than indiscriminate reduction.
A simplification ambition goes deeper. Here the goal is to reduce the number of systems, variants, interfaces, and local exceptions that make the portfolio hard to manage. Savings still matter, but they are treated as one result of simplification rather than the sole objective. This ambition is especially valuable when the organization feels slow and fragmented: too many tools doing similar jobs, too many workarounds, and too much time spent reconciling data across systems. Simplification creates lasting value because it removes structural complexity.
A modernization ambition is different again. The organization uses rationalization to free resources, reduce technical clutter, and prepare the estate for cloud, data platform, automation, or digital product investments. The question is not only what should be removed, but also which platforms should anchor the future landscape. In this model, rationalization is tied directly to transformation. It is less about cleaning up history and more about making the next strategic move possible.
A control ambition is appropriate when the organization lacks visibility and governance. Ownership is unclear, shadow IT is widespread, contracts are scattered, and leadership cannot answer basic questions about cost, risk, or lifecycle status. In this case, the first goal may not be dramatic consolidation. It may be establishing a disciplined view of what exists, who owns it, how it is classified, and which standards apply. Control sounds less exciting than modernization, but without it, most rationalization programs become one-time exercises rather than a sustainable management discipline.
These ambitions can coexist, but one must lead. The lead ambition determines how trade-offs are resolved. If cost is primary, a redundant tool may be exited quickly. If modernization is primary, the same tool might be tolerated for a period because it fits the future platform plan. If control is primary, the first step may be classification and ownership rather than retirement.
A useful practice is to define ambition in a short written mandate that answers four questions. Problem: what is the program solving? Priority outcome: what matters most? Decision scope: what kinds of actions are expected? Constraints: what must be protected, such as customer resilience, regulatory commitments, or a major transformation already in flight? That one paragraph is often enough to keep the rest of the work coherent.
3.2 Defining Business, Geography, Function, and Technology Scope
Once the ambition is clear, the next task is to define the boundary of the effort. Scope is where many rationalization programs either become too small to matter or too large to execute. Good scope is not about being exhaustive for its own sake. It is about creating a decision perimeter that is broad enough to capture real value and narrow enough to produce action.
Business scope comes first. Some organizations need an enterprise-wide review because leadership has little confidence in the inventory or suspects duplication across many domains. Others should begin with a sharper focus, such as a newly acquired business, a major function like finance or supply chain, or the set of applications surrounding a core transformation. The right choice depends on where spend, overlap, and urgency are concentrated. A company-wide launch sounds bold, but if the pressing issues sit in three domains, a narrower first wave is often more effective.
Geography scope requires similar discipline. Large organizations often carry different platforms by region because of acquisitions, local leadership choices, or regulatory requirements. Some variation is justified. Much of it is historical. A “global” review may be the correct aspiration, but it should not imply that local requirements will be ignored. It is usually better to define a global standard while explicitly acknowledging where local exceptions may be required for legal, tax, language, or market reasons.
Functional scope is where rationalization becomes more practical. Applications should be examined in the context of business capabilities, not as a flat list. Finance tools should be reviewed together. So should HR, sales, procurement, operations, analytics, customer service, or plant systems. Capability-based scoping reveals overlap that is invisible in a generic inventory and creates a natural structure for business discussion. It is easier to make decisions when the comparison set is coherent and the accountable business leaders are obvious.
Technology scope must also be stated clearly. Many programs say they are reviewing applications but quietly exclude the surrounding components that create real cost and dependency. Reporting layers, workflow tools, integration platforms, databases, and local utilities often exist only because the core application estate is fragmented. Leaving them out creates a misleading picture. At the same time, not every technical component needs the same level of assessment. A practical solution is to define two layers of scope. Primary scope: the applications and domains being directly evaluated for retain, replace, consolidate, or retire decisions. Dependency scope: the interfaces, data stores, and supporting tools that must be understood because they affect feasibility, cost, or risk.
Exclusions should be defined deliberately. Some platforms may already be on a separate roadmap. Some specialized systems may be out of scope for an initial wave because the business cannot absorb change there yet. The discipline is to name those exclusions openly. Otherwise, they reappear later as arguments about whether the program was incomplete or unfair.
A simple scope test is worth applying before the work starts. Coverage: does the boundary include the assets that actually drive cost, risk, and complexity? Decision value: will the fact base produced support real choices? Stakeholder fit: are the business owners in scope able to engage? Executability: can the resulting decisions be implemented in waves the organization can absorb? If the answer to any of these is no, the scope needs refinement.
3.3 Deciding Which Application Types to Include: SaaS, Custom, Legacy, Shadow IT, and End-User Computing
Even after the broad boundary is set, one question remains: what counts as part of the application portfolio? Many organizations include the well-known enterprise systems and leave the rest for later. That is understandable, but it often misses the very assets that create hidden cost, weak control, and operational fragility. Inclusion rules should be explicit.
SaaS applications must be part of the review. In many companies, SaaS has been the main source of portfolio growth because it is easy to buy and easy to deploy. Departments adopt tools for collaboration, workflow, analytics, customer engagement, and specialized operational needs, often without seeing the full enterprise picture. Some of these tools are highly valuable. Others duplicate existing capability or create new data and integration problems. The important point is that SaaS is not automatically strategic just because it is modern. It should be judged by the same questions as any other system: does it provide distinctive value, what does it cost in full, how hard is it to support, how well does it fit the target landscape, and what risk does it introduce?
Custom applications also belong in scope, especially when they are poorly documented. They often contain critical business logic, local market rules, or integration behavior that no packaged product fully replicates. They are also frequently the source of key-person dependency and hidden maintenance effort. Because custom systems are harder to evaluate, organizations sometimes postpone decisions about them. That usually means they remain in place by default. A better approach is to classify them clearly: strategic and worth further investment, stable but to be contained, candidates for modernization, or candidates for replacement over time.
Legacy applications deserve inclusion, but “legacy” should not mean merely old. Some older systems are cheap, stable, and adequate. Others are recent but still poor fits because they duplicate capabilities or rely on brittle interfaces. The real test is not age. It is whether the application constrains change, carries disproportionate risk, consumes excessive support effort, or conflicts with the intended target state.
Shadow IT should also be included where it matters. This means software bought or managed outside central technology governance, as well as locally built solutions that support recurring business activity. The aim is not to hunt down every team experiment. It is to surface the tools that have become operationally important without being treated as governed enterprise assets. Those tools often represent hidden spend and hidden risk.
End-user computing deserves special attention. Spreadsheets, desktop databases, scripts, and low-code utilities are often treated as informal, yet they may carry approval logic, reconciliations, pricing rules, compliance evidence, or management reporting. Rationalization teams should not try to catalog every file on every laptop. They should focus on end-user tools that meet at least one of three tests: the business depends on them repeatedly, they substitute for a missing system capability, or they create material control or operational risk.
A practical inclusion rule is to use thresholds. Include any asset that meets one or more of the following conditions:
- Business dependence: a meaningful process would be disrupted if it failed.
- Economic significance: it drives notable license, hosting, support, or vendor spend.
- Risk relevance: it handles sensitive data, important controls, or fragile manual logic.
- Architectural impact: it creates important interfaces, data dependencies, or platform lock-in.
Thresholds keep the effort from turning into an endless search for minor utilities while ensuring the real shape of the estate is visible.
3.4 Establishing the Time Horizon and Success Criteria
The final framing decision is time. Rationalization programs frequently fail because the expected results and the delivery horizon do not match. Leadership wants meaningful savings, lower risk, and a cleaner architecture, but expects those outcomes on a timetable that supports little more than inventory building. Others set such a broad horizon that the program becomes an academic exercise. A credible effort needs both a near-term execution horizon and a longer-term directional horizon.
The execution horizon defines when visible actions will happen. In most organizations, this should be organized in waves. An initial wave usually focuses on low-complexity actions: duplicate SaaS tools, underused licenses, applications with limited migration effort, or systems already approaching contract renewal. Later waves can handle deeper consolidation, data migration, platform replacement, or process redesign. Wave-based planning matters because it aligns rationalization with business capacity. It recognizes that the company cannot absorb change everywhere at once.
The directional horizon is about intent. Even if a difficult legacy platform cannot be removed for three years, leadership should know whether the long-term plan is to retain, contain, replace, or retire it. Without that clarity, temporary decisions become permanent. Contracts get renewed by default, integration work continues around systems with no future, and scarce investment leaks into assets that should be winding down.
Success criteria should be set before detailed analysis begins. They should reflect the lead ambition. A cost-led program might define success as a specific run-rate savings target, contract reduction, or support-cost reduction. A simplification-led program might track lower application counts, fewer interfaces, or reduced duplication within key business capabilities. A modernization-led program might focus on increased use of strategic platforms, reduced unsupported technologies, or greater capacity released for product and platform work. A control-led program might measure ownership coverage, lifecycle classification, policy compliance, and contract transparency.
It is important to separate activity from outcomes. Activity measures show that the team is working: inventories completed, workshops held, applications scored. Outcome measures show that the estate is changing: systems retired, contracts not renewed, interfaces removed, risks reduced, or budgets reset. Rationalization should always be judged primarily by outcomes.
A short planning template is usually enough:
- Decision date: when will the first wave of choices be approved?
- Realization date: when will the first wave of savings or risk reductions show up?
- Leadership metrics: which few measures will be reviewed monthly?
- Proof of value: what must be visible in budgets, contracts, or risk records to count as realized?
- Expiry date for deferrals: how long can a deferred decision remain open before it must be revisited?
This discipline keeps the program from drifting into endless assessment. It also protects the organization from unrealistic expectations. In application rationalization, the portfolio can always be analyzed in more detail. Only a clear horizon and explicit success criteria keep the work anchored in action.
