When a System Is Decommissioned While Still in Use

Turning tribal knowledge into repeatable, enforceable standards

In enterprise environments, it’s not unusual for teams to rely on systems that were built and maintained elsewhere – sometimes by a central IT group, sometimes by a global function, sometimes by an external vendor.

These systems often become deeply embedded in the way business is done. Teams build processes, applications, and even customer experiences on top of them.

But what happens when the owners of that system announce: “We’re decommissioning this.”

And worse – it’s still in use.

The Risk of “Business as Usual”

At first, the temptation might be to carry on until the switch is flipped. “We’ll cross that bridge when we get to it.”

But here’s the reality:

• Decommissioning usually comes with a timeline, and when the deadline hits, support disappears overnight.
• Teams that haven’t prepared face sudden outages, compliance risks, or broken dependencies.
• The people who know the most about the system may already be gone, making migration even harder.

The longer you delay, the higher the risk.

The Challenge of Replacing a Live System

Replacing a system while it’s still actively used is far harder than starting fresh.

• You need continuity – the business can’t simply pause operations during the change.
• You need parity – the replacement must meet today’s needs before it can improve tomorrow’s.
• You need consistency – across teams, so no one drifts into “local variations” of the solution.
• And you need speed – because the deadline is often fixed by someone outside your control.

In other words, you’re not just building a new system. You’re migrating in-flight, without dropping the baton.

Reframing Decommissioning as an Opportunity

It’s easy to view decommissioning as a setback. But there’s another way to see it: an opportunity to modernise.

When a system is being retired, you’re forced to ask hard questions:

• Which parts of it do we really need?
• What rules and standards have been implicit, but never documented?
• How can we eliminate duplication and fragmentation across teams?
• How can we design the next version to be faster, safer, and more maintainable?

The change is coming whether you want it or not. The opportunity lies in using the moment to rebuild smarter.

The Role of Automation and Codification

Traditionally, replacing a live system meant weeks of workshops, manual documentation, and handover checklists. The process depended heavily on people remembering the right steps – which meant mistakes were common and timelines slipped.

A better approach is to codify the process.

But what is Codification,

codification is the act of taking knowledge that usually lives in people’s heads, scattered documents, or informal practices, and turning it into a clear, structured set of rules or instructions that anyone can follow and repeat. In engineering, this means translating tribal knowledge – like naming conventions, file structures, or migration steps – into artefacts such as playbooks, templates, or configuration files. Once codified, the process becomes transparent, version-controlled, and enforceable, removing ambiguity and reducing reliance on individual memory or interpretation. It’s the bridge between “this is how we’ve always done it” and “this is how it must be done, every time.”

In better terms, codification,

• Extract the repeatable steps from documentation.
• Turn them into executable workflows or automation scripts.
• Enforce the guardrails (what’s allowed, what’s not) so teams can’t drift off course.
• Build once, repeat everywhere.

This shifts the migration from being knowledge-dependent to being process-driven.

The Bigger Picture

When a system is decommissioned while still in use, the real risk isn’t just losing the system.

The bigger risks are are losing time to manual, repetitive rework losing consistency across teams and losing control to external deadlines.

By codifying the migration process – and automating as much as possible – you turn risk into resilience.

• For business stakeholders, this means predictable delivery and lower risk.
• For engineers, it means less grunt work and fewer mistakes.
• For the organisation, it means local control and the ability to adapt faster.

---

Having a system decommissioned while you’re still using it feels like a crisis. But it doesn’t have to be.

Handled well, it becomes a catalyst to take ownership, to modernise, and to rebuild with speed, consistency, and safety.

It’s never just about replacing what’s lost. It’s about reimagining how you deliver, when change is forced upon you.

In this series of post which I will add more in the future, I will explain the strategy that can be used to drive these situations.