Most internal tools are launched with a plan and retired without one. The new system goes live, the old one is "still there for now", and a year later nobody is sure who uses it, whether it holds the only copy of some records, or what will break if it is switched off. A short sunset plan removes that doubt.
Find out who uses it
Start with facts, not with the list of people you think use the tool. Check:
- Login records for the last three months: who signed in, and how often.
- Scheduled jobs and integrations: reports, imports, exports or other systems that read from it.
- The people who do not sign in but receive its emails or printouts.
Ask each team lead one question: "What would you miss if this tool stopped on Friday?" The answers are often a single report or a monthly export, and that is what the replacement must cover. If the tool has no owner, name one now. Without a named person the plan will stall.
Export the data and check it
Decide what must survive. Usually that means customer or order records, attachments, and the history of changes where it matters for accounting or legal reasons. Check how long you must keep each kind of record under your own rules.
Then export in a format that does not need the old tool to read it, such as CSV or JSON for records and the original files for attachments. Verify the export before you rely on it:
- Compare record counts in the tool and in the export.
- Open ten records at random and check that fields, dates and special characters are intact.
- Confirm that attachments open.
- Store the export in a place with access control and a named owner.
If the data moves into the new system, do the same count and sample check after the import. The thinking is similar to the checks in the first 30 days after launching a new internal tool, only in reverse.
Announce and set a notice period
Send one clear message to all users and to the teams found in the first step. It should say what is ending, the exact last day, where the work moves to, who to ask for help, and what happens to old data. A notice period of four weeks suits most small tools; use longer when the tool supports month-end or quarter-end work.
Repeat the date at four weeks, one week and one day before the end. Make the tool show a banner with the date. People tend to ignore the first message, so a banner does more than a second email.
Switch to read-only before switching off
One or two weeks before the last day, make the tool read-only if you can. New entries now go to the replacement, and anyone who still tries to work in the old tool will notice and ask. This is the cheapest test of what you missed. If someone shows up with a real need, extend the date once and note why; do not extend it again without a new reason.
Last-day checks
On the last day, one person runs a short checklist:
- The final export is taken, verified and stored.
- Scheduled jobs, emails and integrations that point to the tool are switched off or redirected.
- Bookmarks, links in documents and the intranet page now point to the replacement or to a short explanation.
- Backups of the old system exist and the restore has been tried at least once.
- The owner has written down the date, what was exported and where it is.
Only then switch the tool off. Keep the server or account for a short grace period, for example 30 days, so that a missed item can be recovered. A related point from handling change requests after launch applies here too: write down every late request with the person who asked, so it is answered rather than lost.
Close accounts and keep an archive
After the grace period, finish the job:
- Remove user accounts, API keys and service access, and cancel the licence or hosting.
- Keep a read-only archive, or the verified export, for the retention time you decided on, and set a date to delete it.
- Remove the tool from your list of systems and from any access review.
An old system left running without updates becomes a security risk, which is why this last step matters as much as the export.
Common mistakes
- Announcing before knowing the users. A forgotten team finds out on the last day.
- Trusting an export that nobody opened. Problems appear after the old system is gone.
- No read-only phase. Late needs surface when it is too late to react.
- Switching off integrations by accident. A report quietly stops arriving.
- Never closing accounts. The tool is dead but still reachable.
Summary
List the real users, export and verify the data, announce a fixed date and repeat it, go read-only first, run a last-day checklist, and then close accounts and keep a small archive. For a modest internal tool the work takes a few days spread over four to six weeks, and it replaces a "temporary" system that lingers for years with a clear ending.
Sources
- Common practice for small teams, offered as a practical guide. No client results or market figures are claimed in this article. Adjust the notice period, the retention time and the grace period to your own tool, contracts and legal obligations.