The step that gets postponed
Once a new system is working, the old one often lingers. It seems safer to leave it running, nobody is sure who owns it, and there are more urgent tasks. But a system left running has ongoing costs: licences, hosting, support effort, and security exposure from software that may no longer receive updates. It also keeps a second version of the data in existence, which can confuse people.
Decommissioning is the structured process of retiring the old system in a way that keeps what must be kept and removes what should be removed. It is a project phase in its own right, and it usually deserves an owner and a date.
Step 1: Confirm it is safe to proceed
Do not retire a system just because the main users have moved. Check:
- Dependencies. Does any other system, report, scheduled job or process still read from or write to it? A current state assessment from the start of the project is the best baseline for this, but it should be re-checked, since things change.
- Usage evidence. If logs are available, look at who is still connecting and for what. A system that appears idle may be used once a quarter or once a year.
- Open items. Are there transactions, cases or approvals still in flight?
- Stabilization exit. Has the new system run through at least one full business cycle, such as a month-end or year-end, without needing to fall back to the old one? This relates to the rollback plan, because once the old system is retired the option to go back largely ends.
A formal sign-off from the business owner, using criteria agreed beforehand, is a good practice.
Step 2: Decide what happens to the data
For each data set in the old system, decide among a few options:
- Already migrated, and verified, so the source can be removed after a hold period.
- Archived in a secure, accessible form, because it must be kept but is not needed for daily work.
- Deleted, because it has no continuing value and no obligation requires keeping it.
Retention decisions depend on the type of record and on legal and regulatory requirements, which vary by country, industry and record type. This is general information, so involve legal, records and compliance specialists. Existing data retention schedules provide the starting point, and a records owner should approve the final decisions.
If you archive, consider:
- Readability. Will the archive still be readable in several years, without the old software? Exports to common formats are often used, but preserve the context, such as field definitions, so the data remains understandable.
- Searchability. Who may need to find a record, and how quickly?
- Integrity. Can you show the archive has not been altered?
- Access control. Who is allowed to open it? Archived data can still be sensitive.
- Location and cost. Where is it stored, for how long and who pays?
Test that you can actually retrieve a sample of archived records before the source is switched off. An archive you cannot read is not an archive.
Step 3: Remove access
Retiring a system includes cutting off the ways in. This involves:
- Disabling user accounts, service accounts and shared logins.
- Revoking privileged accounts and administrative credentials, which deserve particular care.
- Removing the system from single sign-on and other identity and access management connections.
- Closing network paths and integrations that point to the system.
- Retiring API keys and certificates tied to it.
Access reviews are a useful way to confirm that nobody is left with unnecessary rights. Follow your organization’s security procedures and consult qualified security staff on the specifics, since retiring a system badly can leave stray credentials or open connections behind.
Step 4: Shut down in stages
A cautious sequence reduces risk:
- Make it read-only. Users can look up information but cannot change anything.
- Observe for a defined period. Watch for attempts to use it, and listen for complaints.
- Switch off. Take the system offline but keep the ability to restore it for a defined period, such as holding a final backup.
- Remove. Delete or dispose of the environment once the hold period ends.
The length of each stage depends on how quickly problems would surface. For something used at year end, a short observation window may miss the point.
Step 5: Handle physical and contractual items
- Hardware and media. Disks and devices may hold sensitive data. They should be wiped or destroyed according to an approved method and a record kept. Asset registers, including IT asset management records, should be updated.
- Licences and subscriptions. Check notice periods and renewal dates. Cancelling too late can mean another term of payment, while cancelling too early can remove the ability to restore.
- Support and maintenance contracts. End or reduce them as appropriate.
- Third parties. Tell any supplier or partner who connected to the system.
- Documentation. Retain key documents about the system’s design, data structure and retirement, since they help explain archived data later.
Step 6: Close out
- Record what was done, when and by whom.
- Update inventories, diagrams and the configuration records.
- Capture lessons for the next migration.
- Confirm savings only if you measured the costs before, since the benefit is not guaranteed and may be smaller than expected once archive and support costs are counted.
Risks to keep in mind
- Forgotten dependencies that surface after switch-off.
- Lost context, where archived data cannot be interpreted.
- Unreviewed copies, such as old backups and test environments that still hold production data.
- Single knowledgeable person leaving before the retirement is done.
- Premature deletion that conflicts with a retention obligation or an audit.
A deliberate, documented decommissioning protects the organization’s records and closes the migration cleanly.