Application Retirement Checklist: Prove It Is Safe to Switch Off

By Content Team · October 15, 2026

Retire an application only when you can prove that its users and dependent systems have moved, required records remain retrievable, and the team can recover from a failed cutover. An unused login screen or a completed migration ticket is insufficient evidence. The shutdown decision needs named owners and test results.

This checklist starts after a system has been selected for retirement. It focuses on the last operational handoff: what must be demonstrated before access, infrastructure, integrations, and recurring costs are removed.

Define exactly what will disappear

Create a retirement record for the application and its environments. List the service, database, storage, scheduled jobs, integrations, accounts, licenses, and network endpoints in scope. Mark shared components explicitly so a cleanup task cannot accidentally remove something another application still needs.

Separate three milestones: the old system stops accepting changes, its service stops running, and its recoverable assets are finally removed. These dates may differ. Each milestone needs an owner, an approval, and an explanation of what remains available afterward.

Add the replacement destination or archive for every business function. “Moved to the new platform” is too broad if historic attachments, audit history, or a recurring report still exist only in the old system.

Find the consumers that do not log in

Look beyond user activity. A reporting job may read the database overnight; a partner may collect files weekly; an integration may call an endpoint only when a customer cancels. Ask the relevant teams to identify those consumers and verify them against connection logs, schedules, and application configuration.

AWS retirement guidance recommends investigating inbound and outbound connections rather than relying only on architecture diagrams or institutional knowledge. It also warns that an observation period must account for infrequent workloads.

Keep a dependency register with five fields: consumer, interface, business purpose, run frequency, and replacement owner. For each dependency, attach evidence that the new route works or an explicit decision that the function is no longer required. Follow file transfers through to their eventual consumer; successful file delivery does not prove anyone can use the replacement output.

Prove that the export is usable

A completed export is an intermediate result. Define what must be preserved, who may retrieve it, and how it will be interpreted when the old application is unavailable. Have the appropriate data and records owners approve retention and any legal-hold requirements; avoid choosing a universal retention period.

Build an export acceptance pack containing:

• A manifest of datasets, attachments, date ranges, and export times.
• Field definitions, identifiers, relationships, and time-zone conventions.
• Reconciled counts and relevant business totals, with exceptions explained.
• A retrieval test performed by an authorized business user.
• An owner for storage, access, retention review, and future retrieval requests.

Use a representative record with history and attachments for the retrieval test. Can the reviewer find it, understand its status, and connect it to the right customer or transaction without the original interface? Check whether exported documents are actual files or links that will stop working when the subscription ends.

Keep archival retrieval and operational recovery separate in the acceptance pack. A readable archive may satisfy a historical lookup while lacking the software, configuration, or licenses needed to restart the service.

Specify who can write during cutover

Record the last permitted write to the old application and the point at which the replacement becomes authoritative. Identify imports, queued messages, mobile clients, scheduled tasks, and external integrations that could continue changing old records after users move.

Plan how late-arriving changes are detected and reconciled. In a hypothetical customer-system replacement, an agent could update an address in the new platform while an overnight job restores yesterday's value from the old database. The cutover plan needs a rule for resolving that conflict, with traceable evidence of the chosen value.

For incremental transitions, Microsoft's Strangler Fig guidance highlights coexistence and cross-system dependencies. It also explains why restoring removed legacy data structures and replaying changes can make later rollback substantially harder. Identify that boundary before final cleanup.

Give rollback an owner and a stopping point

Write a short decision record that answers:

• Which failure conditions trigger a pause or rollback?
• Who can make that decision, and who executes it?
• What must be restored, reconnected, or replayed?
• How will changes made after cutover be preserved?
• Which irreversible step ends the simple rollback option?

Rehearse recovery with representative data and record the result. Do not equate a snapshot's existence with a proven restart path. Application dependencies, authentication, configuration, and external connections may also be necessary.

Make the escalation contact usable during the planned window. If the migration lead is unavailable, the team needs a named substitute rather than an approval that cannot be obtained when a failure occurs.

Run a controlled stop before final removal

Use an approved, reversible stop to observe whether the expected business process continues without the old service. Choose the observation period around actual usage cycles. A few quiet days cannot establish that a quarterly consumer has been handled.

During the stop, watch for failed jobs, missing reports, integration errors, and support requests. Record what was checked, when it ran, and who accepted the result. An unresolved dependency should reopen the retirement decision.

AWS decommissioning practices address controlled shutdown, preserving necessary settings and data, removing schedules that could restart an application, and updating operational assets. Translate those principles into a system-specific runbook rather than executing a generic deletion list.

Close access, assets, and costs with evidence

After acceptance and the agreed recovery window, review application-specific accounts, credentials, connectors, monitoring, licenses, and infrastructure. Check shared use before removing anything. Preserve the archive and recovery materials that remain subject to approved retention requirements.

For storage disposal or sanitization, use an appropriate documented process. NIST SP 800-88 Revision 2 provides guidance for a sanitization program based on information sensitivity and applicable techniques. Deleting an application's visible files alone does not establish that every copy has been handled.

Finish with a closure record: approvals, export and retrieval evidence, resolved dependencies, recovery-test results, asset changes, and confirmed contract or billing outcomes. Treat savings as verified only when the relevant charges actually end.

Hexagon's custom software and modernization services support connected-system planning and validation. Discuss an application retirement to scope the dependencies, data handoff, and acceptance evidence needed before shutdown.

Frequently asked questions

How long should an application remain available after migration?

Base the period on dependency cycles, retrieval needs, recovery risk, and approved retention obligations. Document the exit criteria; a convenient calendar date alone does not demonstrate readiness.

Is a database backup enough to retire the application?

No. Verify that required records can be retrieved and understood. Operational recovery may also need application code, configuration, authentication, dependencies, and a tested way to reconnect the service.

Who should approve the final shutdown?

Name the business owner, technical owner, and relevant data or records owner. Obtain acceptance from dependent teams where applicable, and identify who has authority to pause the shutdown.

What if a hidden dependency appears during the controlled stop?

Pause the retirement and restore the affected service through the approved recovery process. Identify the consumer, arrange its replacement, and repeat the relevant acceptance tests before proceeding.