The new system has been running for weeks. Most people have moved over. Then someone asks whether the old one can finally be switched off, and nobody is quite sure. A month later a finance colleague discovers that a monthly export, which nobody remembered, came from the old system and has been silently missing.
This article is for a technology or operations lead who has already chosen a replacement and now has to close down the old system without losing anything. It is a checklist for the last 90 days, and it works for an ordinary business application, not only for a large platform. If you are still deciding what to replace first, our article on modernizing a legacy system in pieces covers that step. For the same question about an AI agent, see how to retire or replace an AI agent safely.
Why the last 90 days need their own plan
Migration is usually planned as a project with a start and an end. Shutdown is often treated as the tail of it: "and then we turn it off." In practice the old system holds years of small habits. People use it for lookups, exports, reminders and workarounds that were never written down. The last three months are when you find those out, so it is better to find them on purpose.
Name one owner for the shutdown, separate from the person running the new system. Give that person a single list, the one below, and a date for each item.
Days 90 to 60: find out what the system really does
Ask who still uses it. Check the access log or the list of accounts. Contact everyone who logged in during the last three months and ask what they used it for. Do not rely on the original requirements; they describe what the system was meant to do.
List every report and export. Include scheduled emails, files dropped into shared folders and numbers that someone copies into a spreadsheet each month. Each one needs a replacement in the new system, a decision to stop it, or a named person who will do without it.
List every integration. For each connection to another system, write down what flows, in which direction, how often and who depends on it. Include the dull ones such as a nightly file to the accounting tool.
Check the legal and contractual side. Some records have to be kept for a set period, and some contracts have notice periods or minimum terms. Ask whoever handles legal or finance now, not in the final week.
Days 60 to 30: archive, freeze and rehearse
Archive the data in a readable form. An archive that only opens in the old software is not an archive. Export the records to common formats such as CSV or PDF, keep any attachments with their original names, and store a short description of what each file contains. Open a few files from the archive and check them against the old system.
Set the last-write date. Choose a day after which nobody can create or change anything in the old system. From then on it is read-only. This is the most useful single step in the plan: it turns a moving target into a fixed one, and it exposes anyone who still depends on the old system for daily work while you still have time to help them.
Move the remaining data once, then compare. Do a final transfer after the last-write date, and compare record counts and a sample of values with the new system. Write down the result.
Rehearse the shutdown. On a copy, or in a quiet period, switch off one integration and watch what breaks. It is better to learn this while you can switch it back on.
Days 30 to 0: tell people, remove connections, cross the line
Tell users in plain language. Say what is ending, on which date, where to go instead and who to ask. Send the message early, repeat it once, and send a short reminder in the last week. Include where the archive is and how to request something from it.
Remove integrations one at a time. Switch off each connection, wait for a normal working cycle, and check that nothing complains. Doing it in one afternoon makes it hard to tell which change caused a problem.
Decide the point of no return. Until a certain date you can still reopen the old system. After it, you delete or decommission it. Agree this date in advance and write down what must be true before you cross it: archive checked, reports replaced, integrations removed, no unresolved questions from users.
Then switch it off, and keep one safety net. Before deleting servers or licences, keep a backup of the system and its data for an agreed period, with a named person who can restore it. When that period passes without a request, remove it and close the item.
After the shutdown
Do a short review a month later. Did anyone ask for something that was not in the archive? Was a report missing? Write down what you learned, so that the next shutdown starts from a better list. Also remove what the old system left around it: accounts, access rights, firewall rules, monitoring alerts and entries in documentation.
What to avoid
- Switching off on the date the new system goes live. Give people time between the last write and the shutdown.
- Archiving "everything" without checking it. An unchecked archive is a hope, not a backup.
- Assuming the old system is used only by the people who own it. Look at the logs.
- Having no point of no return. Without it the old system lingers for years, and it still costs time, licences and risk.
What to do this week
Name the shutdown owner. Ask for the list of accounts that were active in the last three months. Write down three dates: the last-write date, the point of no return and the shutdown. Everything else in this checklist follows from those three.
Sources
- Our related articles linked above.
- The checklist is a general approach and does not describe a particular company, system or supplier.