Once the application inventory exists, the next question is whether the organization knows enough to act on it. An inventory tells leaders what applications appear to exist. Fact collection tells them which systems matter, what they cost, how risky they are, and how difficult they will be to change. Many rationalization efforts fail because they collect too little evidence and make poor decisions, or collect too much and never reach decisions at all. The discipline is to gather the facts that materially improve judgment. This chapter focuses on five categories of evidence: business usage, technology condition, financial profile, risk exposure, and rapid fact gathering when records are incomplete. The goal is not a perfect repository. The goal is a credible fact base for action. In practice, good fact collection is the difference between a portfolio debate and a portfolio decision.
6.1 Business Usage Data: Users, Processes Supported, Frequency, and Criticality
Business usage data is the most important input because applications exist to support work. Yet many organizations rely on weak proxies such as license counts or general statements that a system is “important.” Those signals are not enough. Rationalization decisions require a clearer view of who depends on the application, what work it enables, how often it is used, and what would happen if it were unavailable.
The first task is to understand the user base in practical terms. How many people use the application, which roles use it, and how central is it to their work? A system used by a small group every day may be more critical than one with thousands of occasional users. User counts should therefore be paired with role dependence. The real question is not how many accounts exist. It is who would be unable to perform essential work if the application failed or disappeared.
The second task is to link the application to business processes. Teams should record the specific processes supported and the point in the workflow where the application is used. Some applications are systems of record. Others provide approval steps, local exception handling, reconciliations, or reporting around a larger platform. Those distinctions matter because they shape the removal path. A duplicate reporting tool can often be retired quickly. A small local solution that carries an undocumented compliance step needs much closer scrutiny.
Usage frequency also needs more nuance than “active” or “inactive.” A practical scale such as daily, weekly, monthly, quarterly, seasonal, or event-driven is usually enough. Seasonal applications are especially easy to misjudge. Tools used for year-end close, open enrollment, tax filing, or plant shutdowns may look dormant for long periods but still be highly important during specific windows.
Criticality should be assessed explicitly. If the system were unavailable for a day, would work stop, slow down, or continue through a manual workaround? Would customers notice? Would a legal or regulatory obligation be missed? This moves the conversation away from emotion and toward operational consequence. It also helps separate truly important systems from applications that are mainly familiar or preferred.
A simple business usage record should capture five things:
- User groups: which roles or teams rely on the application.
- Process support: the activities or decisions the application enables.
- Usage pattern: daily, periodic, seasonal, or event-driven use.
- Criticality: the effect of outage or removal on the business.
- Fallback option: what the business would do if the application no longer existed.
Collected well, these facts prevent both overprotection and underestimation. They show where dependence is real and where it is mostly habit.
6.2 Technology Data: Age, Architecture, Integrations, Hosting, Performance, and Support Model
Technology data explains how difficult an application is to keep, how risky it is to leave alone, and how hard it will be to change. A business may feel a system is acceptable because users can still complete their work. The technology view may reveal unsupported components, fragile interfaces, weak recovery capability, or dependence on a few specialists. Rationalization needs this technical reality, not just user sentiment.
Age is the most visible technical field, but it should not be treated as a verdict. Older systems are not automatically poor candidates for retention, and newer tools are not automatically healthy. What matters is age in context: vendor support status, maintainability, platform alignment, and the effort required to keep the application running. A stable old package with full support may be less concerning than a newer custom tool built on a fading framework.
Architecture data should capture the shape of the application. Is it custom-built, packaged, SaaS, or a module within a larger platform? Is it tightly coupled to other systems or relatively self-contained? Does it rely on custom code, scheduled file transfers, manual data movement, or a large number of interfaces? These facts matter because the visible application is often only one part of the technical footprint.
Integration data deserves special attention. Many applications survive because removing them would disturb a network of dependencies no one wants to untangle. The team should identify major upstream and downstream systems and the primary integration mechanisms involved. It is rarely necessary to document every field mapping at this stage, but it is important to know whether the application is loosely connected or sitting at the center of a dense interface web.
Hosting, performance, and support model are equally important. Leaders should know whether the application runs on-premises, in a cloud environment, or on a vendor-managed platform; whether it suffers recurring performance or incident issues; and who actually keeps it running. A system supported by one long-tenured specialist is a very different risk from one supported by a stable vendor and a documented internal team.
A practical technical fact pack includes:
- Technology type: custom, packaged, SaaS, platform module, or end-user solution.
- Lifecycle status: supported, limited support, or nearing end of life.
- Integration profile: major dependencies and interface style.
- Hosting model: where and how the application runs.
- Operational stability: major incidents, performance issues, and recovery difficulty.
- Support model: who maintains it and how concentrated the knowledge is.
This set of facts is usually enough to distinguish technically healthy assets from systems that remain in service mainly because no one has confronted the effort of changing them.
6.3 Financial Data: Licenses, Infrastructure, Vendors, Internal Labor, and Project Spend
Financial data is where rationalization becomes tangible for most executives, but it is also where teams often slow themselves down by chasing perfect precision. The purpose is not to create flawless cost accounting for every application. It is to produce a credible economic view: what the application costs now, what future spend is likely if nothing changes, and where savings or avoided cost may come from if action is taken.
License and subscription costs are usually the easiest place to start. For SaaS and packaged software, the team should identify annual subscription or maintenance charges, the pricing model, the broad gap between entitled and active use if known, and the next renewal date. Those facts often reveal obvious inefficiencies such as shelfware, duplicate tools, or locally negotiated contracts that no longer make sense.
Infrastructure cost should be included even when it can only be estimated. Servers, storage, database licenses, middleware, backup, and cloud consumption all contribute to the real cost of keeping an application alive. This is especially important for older custom applications, where direct software cost may be low but the hosting and operations burden is high. Teams should not wait for perfect allocation logic before using this information. Directional costing is good enough for prioritization.
Vendor spend must be viewed broadly. One application may involve software fees, external support, enhancement contracts, managed services, and specialist contractors. Internal labor should also be considered, even if it is only estimated. Analysts, developers, support teams, testers, release managers, and local business users may all spend time because the application exists. Some of that effort is direct. Much of it sits in shared teams or workarounds and is therefore easy to miss.
Project spend is often the most important forward-looking field. A system that appears tolerable today may soon require a major upgrade, remediation program, contract renegotiation, or infrastructure refresh. That future spend can make retirement or replacement far more attractive than current run cost alone would suggest.
A useful financial view should separate three things. Run cost: the annual cost to keep the application operating. One-time cost: the investment needed to replace, migrate, retire, or archive it. Avoided cost: future spend that disappears if the application exits before renewal, upgrade, or remediation. Leaders need all three views to make sensible decisions. Without that separation, teams tend to confuse a high one-time exit cost with a weak long-term business case.
Where data is incomplete, teams should record estimates and confidence levels rather than false precision. A reasonable range with a clear confidence flag is far more useful than a blank field or a number that looks exact but is not.
6.4 Risk Data: Security, Compliance, Resilience, Audit Findings, and Data Retention Needs
Risk data ensures the portfolio is judged on more than usefulness and cost. Many systems remain in place because they are familiar and the disruption of change feels immediate, while the risks of leaving them alone feel abstract. A disciplined risk view corrects that imbalance. It shows where the organization is carrying exposure that is not obvious in budgets or user feedback.
Security data should begin with the basics. Does the application handle sensitive data? Is it integrated with current identity and access standards? Is it patchable and supported? Are there known vulnerabilities, weak privilege structures, or unmanaged service accounts? The goal is not to launch a new assessment for every application during rationalization. It is to use the best existing evidence from security operations, vulnerability management, architecture, and application teams.
Compliance data is equally important. Applications may support regulated reporting, privacy obligations, payroll controls, trade controls, financial controls, or industry-specific compliance requirements. A small local tool can still carry major exposure if it handles regulated data or produces evidence used in audits. Teams therefore need to know not only whether the application is in scope for regulation, but also what obligations would continue after it is retired.
Resilience data addresses recoverability. What backup and restoration arrangements exist? Is disaster recovery defined and tested? Does the application depend on fragile infrastructure or manual restart procedures? Many applications are assumed to be resilient simply because they have not failed recently. That is not the same as demonstrated recovery capability.
Audit findings provide an efficient shortcut because they often summarize risk already examined elsewhere. Repeated control deficiencies, access issues, unsupported technology observations, logging gaps, or weak change controls are strong signals that an application deserves attention. Data retention needs must also be captured early. An application may be operationally replaceable but still required as a source of historical records, legal evidence, or tax documents. That affects retirement planning even when the business process has moved elsewhere.
A concise risk record should answer five questions:
- Sensitive data: what important data types the application stores or processes.
- Control exposure: known security, access, or compliance weaknesses.
- Recovery posture: how the application would be restored after failure.
- Audit history: whether meaningful findings already exist.
- Retention obligation: what data must remain accessible after retirement.
Risk data turns rationalization into a control discipline, not just a savings exercise. It makes the cost of delay more visible.
6.5 How to Gather Data Quickly When Records Are Incomplete
Incomplete records are normal. Many organizations begin rationalization with patchy CMDB entries, scattered contracts, inconsistent ownership fields, missing cost allocation, and business teams that know the application by a different name from the architecture repository. The wrong response is to stop until the data is perfect. The right response is to collect enough evidence quickly while making uncertainty visible.
The first principle is triangulation. When one source is weak, combine several weaker signals. An application that appears in the CMDB, in a vendor invoice, in an interview, and on a server list is probably real even if none of those sources is complete on its own. The second principle is thresholding. Do not invest the same effort in every system. Gather deeper facts for applications that are costly, risky, duplicated, strategically important, or heavily used. Treat the long tail proportionately.
Structured interviews are often the fastest way to improve data quality. A short conversation with the business owner, application manager, or support lead can clarify purpose, criticality, user patterns, major dependencies, and renewal timing faster than hours of repository browsing. To keep interviews efficient, use a standard question set and validate answers against existing records rather than starting from scratch.
Another useful technique is the evidence ladder. Start with what is known, mark uncertain fields clearly, and then resolve the unknowns most likely to change the recommendation. If ownership, criticality, and renewal timing are unclear, those usually matter more than exact version numbers. If an application is already a strong retirement candidate, perfecting every technical attribute may add little value.
Rapid workshops can also accelerate fact collection in a controlled way. Bring business, architecture, support, security, and finance representatives together around a domain view and review overlapping systems one by one. This format exposes contradictions quickly and often resolves them on the spot.
Three rules keep rapid collection credible:
- Record confidence: mark key fields as confirmed, estimated, or unknown.
- Resolve material gaps: close the unknowns that would change the recommendation.
- Time-box discovery: do not let data gathering continue indefinitely without decisions.
Fast fact collection is not careless fact collection. It is disciplined prioritization. The aim is to reduce uncertainty where it matters most and move the portfolio toward action rather than waiting for a level of completeness that rarely arrives.
