Decommission in order: stop traffic, confirm nothing depends on the component, archive or migrate data, revoke credentials, remove network and DNS entries, then delete code and infrastructure. Verify each step with evidence. A component that is switched off but not cleaned up can still leak data or be taken over.
Why the end is risky
In the strangler fig pattern, you remove the legacy system once all functionality has moved and nothing depends on it, then remove the facade. Teams are tempted to stop at "no traffic". Leftovers cause incidents: forgotten servers with old software, credentials that still work, DNS records pointing at released addresses, and databases with live data nobody watches.
The checklist
- Confirm zero traffic. Check facade and server logs over a full business cycle. Look for batch jobs and scheduled callers as well as users.
- Confirm zero dependents. Search code, configuration and the service catalog for references to the component, including other teams' systems.
- Handle the data. Migrate what is needed. Archive what must be kept for legal or business reasons, encrypted and access controlled. Delete the rest, following your retention rules.
- Revoke credentials. Rotate or delete service accounts, API keys, database users and certificates tied to the component.
- Remove network access. Close firewall rules, load balancer entries and peering routes.
- Clean up DNS. Remove records that point at the component. Dangling records can be claimed by someone else.
- Remove monitoring and alerts that would otherwise fire forever, but keep the audit logs for your retention period.
- Delete the infrastructure and code. Keep a tagged final copy of the source if policy requires it.
- Update inventories. Asset lists, SBOM records and the dependency map should show the component as retired, with a date.
- Record the sign off from the owner, with links to the evidence.
| Area | Evidence to keep |
|---|---|
| Traffic | Log query results |
| Dependents | Search output and owner confirmation |
| Data | Migration or deletion record |
| Credentials | Revocation records |
| DNS and network | Change tickets |
Staged shutdown
A common safe pattern is to disable the component but keep it recoverable for a set period. If nobody complains and no alert fires, proceed to deletion. Announce the date widely first.
Do not forget the facade
Azure's guidance describes removing the facade at the end and pointing clients directly at the new system. Before that step, move any controls the facade enforced, such as rate limits and authentication, to the new services or a standard gateway.
Why inventories matter
The most common failure is a component that no inventory lists. Keep your asset records current throughout the project so retired systems are removed and unknown ones are noticed. See legacy software supply chain risks.
Safeguard's asset discovery and SBOM inventory can help confirm that retired components are gone from your records.
Quick check
Is switching a server off enough?
No. Credentials, DNS records, data and network rules may still create risk.
How long should I keep logs?
Follow your retention policy and any legal requirements. Ask your legal or compliance team for the period.
Sources
Last reviewed: 19 October 2026.
