Retiring the old system properly
The half-decommissioned system is the most common artefact of a software migration and the most expensive to leave alone.
Migrations are declared complete when the new system goes live. The old one keeps running, because a few people still need it, because nobody is sure what is in it, and because switching it off is nobody's task.
Two years later it is still there: still licensed, still holding data, still unpatched, and still occasionally used. For a concrete example of annual work-hour calculations after purchase, further details can be used to identify the behaviours and measures that rollout should actually change.
Set the retirement date at the start
Decide during planning when the old system goes read-only and when it goes off, and publish both dates. Retirement without a date does not happen, because there is never a convenient moment.
Read-only first is the useful intermediate step: it stops new data being created there, which is what makes the eventual shutdown safe, while leaving the history available.
Work out what is actually in it
Before switching anything off, establish what the old system holds that the new one does not: attachments, historical records, audit trails, reports, and — commonly — configuration knowledge that exists nowhere else.
This is the step that gets skipped and is the reason systems stay alive. An explicit inventory converts an unbounded fear into a list of specific items to deal with.
Not a backup in the vendor's format — an export in something readable, stored somewhere you control, with a note explaining what it contains. This is what makes shutdown safe.
Decide what history you must keep, and why
Retention obligations do not disappear when a system does. Financial records, employment records and anything with a statutory period must remain accessible for that period.
Equally, a decommissioning is the natural moment to delete what should not be kept. Migrating an entire old database into a new system is common and frequently carries forward data that should have been deleted years ago.
Cancel the contract, and check
Switching a system off is not the same as ending the agreement. Auto-renewal continues regardless of use, and organisations routinely pay for years for systems nobody has opened.
Serve notice within the window, get written confirmation of termination, and confirm the data is deleted at their end. Then check the next invoice actually stopped.
Clean up the surrounding debris
Integrations pointing at it, scheduled jobs, API keys, service accounts, DNS entries, bookmarks and links in documentation. Each is small and each is a loose end.
Dormant service accounts and forgotten subdomains are a recurring source of security problems precisely because nobody owns them any more. A decommissioning checklist that includes them takes an hour and closes a category of risk permanently.
For practical operational guidance after deployment, CISA resources and tools provides public reference material.