An application may be valuable to the business and still be a poor candidate for long-term retention because its technical condition is deteriorating, its security posture is weak, or its dependencies make it too fragile to support. That is why business value alone is not enough. Rationalization requires a clear view of technical health and risk. This chapter focuses on the factors that determine whether an application is stable, supportable, secure, resilient, and viable as part of the future landscape. It examines technical debt and maintainability, operational support and vendor viability, security and compliance exposure, and the integration complexity that often creates the biggest hidden barriers to change. It concludes with a practical scoring model that allows these factors to be assessed consistently across the portfolio. The goal is not to create a deep engineering review for every system. The goal is to gather enough evidence to tell the difference between applications that are technically fit to retain and those that should be contained, modernized, replaced, or retired.
9.1 Technical Debt, Maintainability, Supportability, and Vendor Viability
Technical health begins with a simple but often misunderstood idea: old does not necessarily mean unhealthy, and new does not necessarily mean sound. Some older applications are stable, well-understood, economically supported, and entirely fit for their purpose. Some newer applications carry heavy technical debt because they were implemented quickly, customized excessively, poorly documented, or deployed without operational discipline. The task is not to judge by age alone, but to understand how difficult and risky the application is to sustain.
Technical debt: this is the accumulated result of shortcuts, deferred remediation, obsolete components, brittle customizations, and architectural choices that make future change harder and more expensive. Technical debt can sit in the code base, in integration logic, in manual deployment routines, in weak test coverage, or in the way the application uses infrastructure and data. It becomes visible when simple changes take too long, when upgrades are repeatedly postponed because they are too risky, or when the team no longer understands the full effect of modifying the system.
Maintainability: this refers to how easily the application can be changed, repaired, and enhanced. Maintainability is influenced by code quality, modularity, documentation, testability, version control discipline, and the clarity of the overall design. A maintainable application has a supportable structure. Teams can diagnose issues, make predictable changes, and introduce updates without repeatedly discovering hidden consequences. A poorly maintainable application may still function today, but every change becomes slower, more expensive, and more uncertain.
Supportability: this concerns whether the organization can reliably keep the application running. The questions here are practical. Is there a capable support team? Is knowledge concentrated in one or two people? Are incidents resolved quickly and consistently? Are monitoring, backup, deployment, and recovery routines documented and repeatable? Many organizations underestimate key-person risk. A system may appear stable until the last knowledgeable administrator retires, a contractor leaves, or the vendor partner that built the solution is no longer available.
Packaged applications require a further lens: vendor viability: the strength of the product’s future. Is the vendor financially stable, actively investing in the product, and still supporting the current version? Are customers being pushed to a replacement platform? Is support nearing end of life? A package can look safe because it has a known vendor name, yet still be a poor long-term choice if the product roadmap is fading, the release cadence has slowed, or the vendor is effectively steering customers elsewhere. SaaS applications require the same discipline. Ease of adoption should not distract from questions about product maturity, service stability, roadmap direction, and exit feasibility.
Custom-built applications raise additional questions. Is the programming language still actively supported? Are the frameworks current? Is there automated testing? Are builds reproducible? Can the application be deployed and recovered without relying on manual steps known only to a few people? These issues are not purely technical concerns. They shape the economic and operational case for retaining the application at all.
A practical technical health review should look for recurring signals rather than perfect engineering detail. These include repeated incident patterns, delayed upgrades, unsupported versions, high change effort, absence of documentation, narrow skill coverage, and frequent reliance on manual intervention. When several of these signals appear together, the application is usually more fragile than its users realize.
One important discipline is to distinguish between fixable weakness: problems that can be remediated without fundamentally changing the application’s role, and structural weakness: problems so embedded in the design or support model that remediation starts to resemble replacement. Rationalization depends on this distinction. Not every unhealthy application should be retired immediately, but every application should be judged honestly on whether its technical condition makes continued retention a sensible choice.
9.2 Security, Resiliency, Privacy, and Regulatory Risk
Technical health is only one side of the risk picture. An application can be maintainable and still create unacceptable exposure if it is insecure, poorly controlled, difficult to recover, or misaligned with privacy and regulatory obligations. In many portfolios, these risks are the true catalyst for action because they make the cost of delay more visible than run cost alone ever could.
Security risk: this should be assessed in terms of both exposure and control maturity. Exposure includes known vulnerabilities, unsupported components, outdated libraries, weak patching practices, open interfaces, and the sensitivity of the data the application handles. Control maturity includes identity integration, role design, privileged access management, logging, alerting, encryption, and the discipline of change control. A system that holds sensitive data but lacks modern identity controls or timely patching is fundamentally different from a low-sensitivity utility with limited access and good hygiene.
Teams should also examine whether the application sits within the current security operating model or outside it. Shadow IT tools, legacy regional platforms, and heavily customized packages often bypass enterprise controls in subtle ways. They may have inconsistent access provisioning, weak audit trails, unmanaged service accounts, or exceptions that were granted years ago and never revisited. These are common patterns in rationalization programs, and they often indicate that the application should not remain in place indefinitely even if users are satisfied with it.
Resiliency risk: this concerns whether the application can withstand failure and recover within acceptable timeframes. Backup existence is not enough. The questions are whether recovery procedures are defined, whether recovery has been tested, whether dependencies are included in the recovery plan, and whether the application relies on fragile infrastructure or manual restart steps. Many organizations discover during rationalization that an application long assumed to be critical has no credible failover path, no recent recovery testing, or no clearly documented restoration sequence.
Privacy and data governance introduce another layer. Privacy risk: depends on the types of personal or sensitive data stored, the jurisdictions involved, the legal basis for processing, retention obligations, deletion requirements, and the application’s ability to honor access and correction requests where relevant. A seemingly minor local tool can carry significant privacy exposure if it stores employee, patient, customer, or financial data outside approved controls.
Regulatory risk: should be assessed in practical terms. Does the application support regulated reporting, financial controls, product traceability, safety processes, or evidence required by internal or external audit? Does it maintain records subject to legal hold, tax rules, or industry-specific retention requirements? If so, retirement or replacement is still possible, but the organization needs to understand what control and recordkeeping obligations must survive the transition.
A useful pattern is to separate risk inherent in the application: what the system handles and supports, from risk arising from weak control execution: how poorly the application is governed or operated. A customer master platform and a local spreadsheet can both involve sensitive data, but the nature and scale of their risks differ. The assessment should capture both the importance of the process and the maturity of the controls around it.
The most reliable evidence often comes from existing risk artifacts rather than new assessments. Vulnerability reports, audit findings, privacy reviews, disaster recovery test results, access reviews, incident reports, and regulatory observations can all be used. The point is not to duplicate what security and risk teams already know. It is to bring those findings into the portfolio decision process.
What matters most is that risk be made comparable. Some applications should be retired because they are low value. Others should be retired or replaced because their risk posture is no longer tolerable. Rationalization needs both views, and it needs them expressed in a way that leadership can weigh alongside cost and business value.
9.3 Integration Complexity and Upstream-Downstream Dependency Risk
Many application decisions that look simple on paper turn out to be difficult because the real complexity of the estate sits in the connections between systems, not just inside them. An application may be small, inexpensive, or poorly loved and still remain hard to remove because it feeds critical data to downstream systems, receives files from multiple upstream processes, or sits inside a fragile chain of reconciliation and reporting. That is why integration complexity deserves separate treatment in any technical assessment.
Integration complexity: refers to the number, type, and criticality of the connections an application has with other systems, data stores, partners, and operational routines. Complexity is not only a matter of interface count. Ten simple API calls are easier to manage than three undocumented batch jobs that run overnight, populate local databases, trigger spreadsheets, and feed compliance reports. The question is not how many interfaces exist, but how much coordination and hidden knowledge the application requires to keep the broader process functioning.
Teams should identify both upstream dependencies: systems or processes that provide data, events, or approvals into the application, and downstream dependencies: systems, reports, users, or partners that consume what the application produces. This distinction matters because the retirement or replacement challenge differs depending on where the dependency sits. If the application is mainly downstream, then alternative inputs may be easier to arrange. If it is a critical upstream source, its removal can have a much larger blast radius.
Dependency risk rises when interfaces are poorly documented, logic is embedded in middleware or scripts rather than in governed application behavior, or data meanings differ across connected systems. Many organizations discover that an old application does not just move data. It applies translation rules, exception logic, calendar adjustments, or control checks that no one had formally documented. Those hidden behaviors are often why migrations take longer than expected.
The assessment should also consider synchronization and timing. Real-time interfaces, scheduled batch windows, reconciliation cycles, and external partner dependencies all affect the difficulty of change. An application that exchanges data continuously with a customer-facing platform or a production control system carries a different kind of dependency from one that sends a weekly export to a reporting mart.
A practical dependency review should answer five questions. How many material interfaces exist? How critical are those interfaces to business continuity or control? How well documented are the interface rules and data meanings? How many other applications would need to change if this one changed? Are there manual workarounds or satellite tools attached to the application that would also need to be addressed? These questions help expose hidden retirement costs and hidden operational risk.
There is also an architectural point. Some applications should be viewed not as standalone systems but as nodes in a dependency chain. A legacy platform may appear tolerable until the team realizes that three local databases, two reporting tools, and several robotic automations exist only to compensate for it. In such cases, rationalization should target the cluster, not the application in isolation. Integration complexity is often the reason why cluster-based decision-making, introduced earlier in the playbook, is so valuable.
Applications with high dependency risk are not automatically untouchable. But they do require more careful sequencing, more explicit migration planning, and more realistic economics. Ignoring integration complexity is one of the fastest ways to produce retirement decisions that look attractive in analysis and fail in execution.
9.4 Practical Scoring Model for Technical Health and Risk
A technical scoring model should do two things well. It should reduce a large amount of engineering and risk information into a form leaders can compare across applications, and it should avoid false precision. A model that is too simple hides important distinctions. A model that is too detailed becomes impossible to apply consistently. The right answer is a small number of dimensions with anchored definitions and clear interpretation.
A practical model usually includes four dimensions. Maintainability and supportability: how easy the application is to change, operate, and sustain. Security and compliance exposure: how much risk the application creates through data sensitivity, control weaknesses, or regulatory relevance. Resiliency and recoverability: how well the application can withstand disruption and recover within acceptable limits. Integration and dependency complexity: how entangled the application is with other systems and how hard it would be to change without wider impact.
Each dimension can be scored on a one-to-five scale, where one reflects strong health or low risk and five reflects poor health or high risk. For example, a score of one in maintainability and supportability would indicate current technology, broad skill coverage, good documentation, manageable change effort, and stable operations. A score of five would indicate unsupported components, narrow knowledge concentration, poor documentation, repeated operational problems, and high effort for routine change.
Security and compliance exposure should similarly be anchored. A low score suggests low data sensitivity, current controls, patchable technology, and no material unresolved findings. A high score suggests sensitive or regulated data combined with weak access controls, unresolved vulnerabilities, outdated components, or repeated audit concerns. Resiliency should reflect tested recovery capability rather than assumptions. Dependency complexity should reflect both the number and fragility of interfaces, along with how much hidden logic sits between applications.
A weighted model works well in most programs. A common starting point is:
- Maintainability and supportability: 30 percent
- Security and compliance exposure: 30 percent
- Resiliency and recoverability: 20 percent
- Integration and dependency complexity: 20 percent
This weighting keeps core technical sustainability and risk at the center while still recognizing the importance of dependency burden. Some organizations choose to increase the weight of security and compliance where regulatory exposure is especially high. That is entirely reasonable as long as the choice is explicit and applied consistently.
The output should then be read alongside business value, not instead of it. A high-risk, high-value application usually points toward modernization, replacement, or accelerated containment rather than immediate retirement without a landing path. A high-risk, low-value application is a strong exit candidate. A low-risk, low-value application may still be retired for simplification or cost reasons. A low-risk, high-value application is often a reasonable retain or invest choice.
The model should always be calibrated before broad use. Score a sample of applications from different domains, compare how reviewers apply the scales, and adjust the anchors where interpretation diverges. The purpose is consistency, not perfection. Once calibrated, technical health and risk scoring becomes one of the most useful tools in rationalization because it makes hidden fragility visible and allows it to be weighed with the same discipline as business value and cost.
