How to decommission a system in a controlled way

When a new system finally goes live, everyone celebrates, and the old one is often left to its fate. But a half-decommissioned system isn’t gone – it’s a lingering risk with old personal data, unpaid licenses, and dependencies nobody remembers anymore. The final phase deserves the same care as the launch. Here are the three parts you can’t skip.

Inventory dependencies before you shut it down

The most dangerous assumption in a decommissioning is that an old system stands alone. In practice, it’s often wired into other things in ways nobody has full visibility into anymore.

An aging system might feed data to other services, receive files from an integration, or be the silent source behind a report some department relies on every month. Pull the plug without knowing that, and you can knock out something entirely different – and the fault only surfaces weeks later, when the connection is hard to trace.

So run an inventory before shutdown: which integrations go in and out, which systems pull data from here, and who actually uses it? A safe approach is to first run the old system in read-only mode for a while – it stays accessible for reading but stops accepting new data. If anyone’s missing it, it shows up then, while the damage is easy to repair.

Archive or delete: a legal fork in the road

Once the system can actually be shut down, the question of the data remains. And it’s not a question of keeping everything or throwing everything away, but two separate and deliberate decisions.

Archiving is preserving data in a readable format for the future – because the law requires it, or because it might be needed. Deletion is deliberately erasing data that may no longer, or no longer needs to, be kept. Just letting the system go dark is neither, and can breach rules in both directions.

The two requirements often pull in different directions, too:

• Accounting rules require that financial records be kept for a statutory period in Sweden. You can’t delete that early, even if the system is going away.
• Data protection (GDPR) conversely requires that personal data not be kept longer than necessary. Archiving the entire old database “just in case,” out of convenience, can therefore breach data minimization.

An orderly decommissioning therefore goes through which data is which: what must be preserved, what must be deleted, and in what format the archive should sit so it stays readable even once the system itself is gone.

Cancel the contracts that keep ticking otherwise

The third part is the most straightforwardly financial, and yet the one most often missed. Ceasing to use a system doesn’t stop its costs.

Licenses, cloud accounts, support agreements, domains, and integration services keep running until someone actively ends them – and many have notice periods that mean the last invoice arrives long after the system has gone dark. A decommissioned system that nobody has formally closed out can quietly cost money for years, a line item nobody thinks to question because “we don’t even use that system anymore.”

So go through every linked contract as part of the shutdown: what are we paying for, what commitment and notice periods apply, and when can each be ended? This is often where the entire decommissioning pays for itself.

A scenario: the system that never died

A company switches business systems and launches the new one with fanfare. The old one is left running “for now.” Nobody inventoried dependencies, so a nightly file feed to the payroll system quietly stops arriving – discovered only at the next payroll run. Nobody made a decision on the data, so the old customer database sits there with personal data long after it should have been deleted. And nobody cancelled the contracts, so the license keeps getting charged every quarter for two years before a new finance manager asks what the line item is.

None of this was inevitable. It was just a final phase that never happened.

How to use this

Treat decommissioning as its own small project with three questions: Do we know what depends on the system before we shut it down? Have we decided what to archive and what to delete? And have we cancelled all contracts and licenses? If you can answer yes to all three, the decommissioning is controlled instead of a lingering risk.

At Weapp, we’re glad to build an orderly decommissioning into the work when we help replace a system, so the old one closes as carefully as the new one opens. See our services or get in touch and we’ll walk through the plan.