A retirement plan for a legacy system is a short list of dated milestones with owners: decide the replacement, map dependencies, migrate data and users, switch off, and verify. Tie each milestone to a review date, so the exception expires with the system instead of lasting forever.
Why exceptions need an exit
Compensating controls cost money and attention every month. They also age: a segment that was well understood in year one is a mystery by year four. NIST's plan of action and milestones control asks organizations to document planned remediation actions for known weaknesses and to update the plan based on assessments, audits and continuous monitoring. Treat the retirement plan as exactly that for the system you cannot fix.
NIST's text on unsupported components also lists replacement of components when support is no longer available as the first option, with alternative sources of support as the second. Retirement is the default. Everything else is an exception to it.
The milestones
| Milestone | Output | Typical owner |
|---|---|---|
| Name the replacement | A chosen path: new product, upgrade, rebuild, or retire without replacement | Application owner |
| Map dependencies | List of systems, jobs, files and people that depend on the old one | Application owner with infrastructure |
| Fund and schedule | Budget line and calendar slot | Business sponsor |
| Migrate data | Data moved and checked, with a rollback | Data owner |
| Migrate users and integrations | Cutover plan and communications | Application owner |
| Run in parallel | Short period where both exist, with a stop date | Project lead |
| Switch off | Access removed, network rules deleted | Infrastructure |
| Verify and close | Evidence the old system is gone, exception closed | Security |
Make the milestones hold
- Date every row. "Q3" is a hope. A specific week is a commitment.
- Name a person, not a team. One accountable name per row.
- Review quarterly with the sponsor. If a date slips, record why and what the compensating controls cost in the meantime.
- Put a hard stop on extensions. Allow one extension with a written reason. A second goes to a senior reviewer.
- Link the exception to the plan. The exception record should point to the plan, and expire when the plan's final date passes.
Handle the awkward cases
If no replacement exists, say so and write down what would have to be true to retire it, such as a process change or a contract ending. If the vendor is gone, consider the alternatives NIST describes: developing in-house support for critical components, or hiring external providers who support unsupported components through contracts.
If the system is rarely used, the cheapest plan may be to archive the data and switch it off. Check retention obligations first.
Close it properly
Switching off is not closing. Remove firewall rules, delete accounts and keys, take it out of the monitoring list, remove DNS entries, wipe or dispose of storage according to policy, and update the inventory. Keep the closing evidence with the exception record.
Quick check
How long should a legacy retirement plan be?
One page is usually enough: milestones, owners, dates and the link to the exception. Detail belongs in the project plan.
What if the replacement project is cancelled?
Reopen the exception with a fresh risk assessment and a new date, and tell the risk owner. Do not let the old date quietly pass.
Sources
- NIST SP 800-53 Rev 5 control catalog (OSCAL JSON, NIST oscal-content repository) (CA-5 Plan of Action and Milestones and SA-22 Unsupported System Components)
Last reviewed: 19 October 2026.
