Application retention is an explicit choice to keep a system running. It applies when the application still serves a required purpose and moving or removing it is not the selected action for the current planning period. The decision includes continuing ownership and operating work; it is not an absence of a decision.
Why an application may be retained
A system may depend on hardware that has no supported replacement, implement a stable process that does not justify immediate change, or remain necessary until another programme removes a shared dependency. Contract, regulatory, data-access, and timing constraints can also affect the decision.
| Retention reason | Evidence to record | Condition for review |
|---|---|---|
| Required capability | Named users and business owner | Replacement capability becomes available |
| External dependency | Interface and dependent owner | Dependency is removed or replaced |
| Migration risk | Specific failure or continuity concern | Risk can be controlled and tested |
| Timing constraint | Related programme or fixed event | Dependency milestone is reached |
| Record access | Data and retrieval requirement | Archive meets access obligations |
The reason needs to be specific enough to revisit. “Too difficult” does not identify what must change before another strategy becomes possible.
What a retention decision contains
A legacy codebase audit should record retention as a bounded decision with an owner and review point. The record includes:
- Scope: The application, component, or capability being retained.
- Reason: The current requirement or constraint that supports retention.
- Dependencies: Systems, data, people, and processes that still rely on it.
- Operating obligations: Security updates, access reviews, backups, monitoring, and support.
- Exit conditions: Evidence that would allow rehosting, replatforming, rearchitecture, or retirement.
- Review point: The event or date that triggers a new decision.
This turns retention into managed scope rather than an indefinite exception.
Retention does not freeze the system
Keeping an application does not remove the need to manage its technical debt. Unsupported dependencies, expiring certificates, access controls, and recovery procedures still require attention. The team may also need small changes to preserve compatibility with systems around it.
Application Rehosting can be paired with retention when the application remains structurally unchanged but its current infrastructure cannot continue. Application Replatforming may be appropriate when a bounded platform change is required to keep the retained capability supportable.
How retention fits the migration portfolio
Retention and Application Retirement answer different questions. Retention states why a system must remain active now and what would reopen the decision. Retirement states how its remaining responsibilities and records will be removed from active service.
A portfolio can contain retained and migrating systems at the same time. Their shared dependencies determine the order in which work can proceed. Recording those relationships prevents a retained application from silently blocking another move and helps the migration plan separate deliberate stability from neglected work. That distinction matters when estimating the real cost of taking over and maintaining a legacy codebase.
