Retiring a legacy system can look like an obvious saving once its replacement is live. Yet an unused interface does not mean that services have stopped depending on the application. A periodic report may still consume its exported file, an integration may call one of its functions, or a team may need historical records that the replacement does not contain.

Before approving retirement, the decision owner needs to understand changes beyond the application boundary. This article proposes a practical dependency map and transition record, not an official standard or a universal retirement procedure. Enterprise architecture connects the decision to services, data, applications and technology, making confirmed relationships and unresolved uncertainty visible.

Define what retirement includes

Distinguish disabling an interface, pausing processing, uninstalling an application and removing its hosting infrastructure. Each has different consequences. New submissions may stop while historical access remains necessary. The application may share a database or identity service with other systems. A single retirement label should not conceal these separate decisions.

Record the system identifier, owner, reason for retirement, environments in scope and functions that will remain temporarily. Compare complete retirement with restricted retention or a phased transition. Assess total costs, including data and integration migration, validation, archiving and transitional operations, rather than treating an expiring licence as a saving already achieved.

Turn the inventory into verified relationships

Start with the supported business service, then follow inputs and outputs. Record interfaces, files, scheduled jobs, reports and technical users. For each relationship, identify the endpoints, direction, purpose, frequency, owner and consequence of losing it. Follow indirect dependencies too: a system reading a file from a shared folder can be affected without connecting directly to the legacy application.

AWS guidance on application retirement warns that architecture diagrams and institutional knowledge can be incomplete, and recommends examining connections and downstream consumers. [1] Treat this as a verification principle, not a claim that one discovery tool captures every dependency. Combine authorized operational evidence with owner reviews, without collecting sensitive payloads that the analysis does not need.

Choose observation periods around business cycles. A quiet day cannot rule out a monthly job or a rare process. Mark relationships unverified where evidence is missing and assign an owner to resolve them. An absent observed connection is not conclusive proof of no dependency, and a fully populated register does not establish complete coverage.

A hypothetical direct and indirect dependency requiring verification before retirement.

Give each dependency an impact owner and treatment

Consider a hypothetical request application that exports a monthly file for a monitoring report. This is not a customer case or a reported project. The replacement accepts requests but does not yet generate the file. Successful use of the new interface does not establish report readiness. The team must provide and test an alternative feed with the report owner before removing the original source.

Separate service ownership, application ownership, data ownership, change execution and decision authority. One person may hold several roles where governance permits, but acceptance of residual risk must have an accountable owner. Security, contractual and regulatory specialists review matters within their authority; an architectural recommendation does not replace their decisions.

Prepare transition and recovery before testing a stop

The transition record identifies what will migrate, be archived or remain available for reading, together with an owner and acceptance evidence for each action. Check completeness, field meaning, permissions and record retrieval, not just transferred file counts. Specialists verify applicable retention periods and restrictions before deletion. Retiring an application is not, by itself, permission to destroy its records.

AWS discusses controlled stops, reassessment when an unacceptable impact emerges and testing recovery. [1] In the proposed approach here, any production test requires an authorized change, an appropriate window, communications, monitoring and agreed stop conditions. The test method depends on the system; this article does not recommend stopping a live service merely to complete a form.

Document recovery triggers, who can invoke recovery, required dependencies and treatment of transactions created during transition. A backup alone does not prove that the service can be restored. If data has changed in the replacement environment, recovery may require reconciliation rather than simply restarting a server.

Retirement depends on evidence for continuity, retention and recovery; an unresolved gap returns the proposal for treatment.

Close with a documented decision

Give the authorized decision maker a summary of coverage, resolved dependencies, remaining gaps, test outcomes and service-owner recommendations. The outcome may be phased retirement, deferral with a defined treatment, or restricted retention because a dependency remains. Do not record final retirement before it actually happens. A successful limited test does not guarantee continuity of every service.

After execution, update the architecture repository and relevant asset, integration, operations and access records. Record closure and evidence for each affected element. Verify savings only after commitments have actually ended; another service may still require retention, licensing or support.

The Digital Government Authority’s 2022 guidance on establishing enterprise architecture addresses current-state documentation, transition roadmaps, decision support and collaboration across functions. [2] It is cited as explanatory guidance, not as authorship of this proposed model or confirmation of the latest requirements for every entity. Organizations apply current requirements according to their sector, scope and authorities.

RMG’s enterprise architecture office page describes current and target-state modelling, relationships and transition planning. [3] If your organization is reviewing legacy systems, discuss a scoped dependency map and the evidence needed before retirement with RMG. Start with a defined service and decision, rather than an inventory without a practical use.