The business case for decommissioning legacy systems

Most organisations are carrying the cost of systems they no longer use.

When a business moves from one core platform to another, it migrates only what it needs to run day to day and leaves decades of history behind in the old system. That old system cannot simply be switched off, because the data still has to be kept for legal, tax and regulatory reasons. So it keeps running, and it keeps costing money.

Decommissioning breaks that trap. It extracts the data an organisation is required to keep, moves it into a system built to hold and report on it, and switches the legacy system off for good. The result is lower cost, lower risk, and data that stays accessible. The business case can be further improved by enabling insights that were never seen before with AI-powered natural language search and analytics across your data.

This paper sets out why decommissioning has become a board-level priority, what it involves, and the value it releases.

Over time, organisations change their core systems. They may move from Oracle to SAP, from SAP to Microsoft, or a vendor encourages the change by releasing a new product that every customer eventually has to adopt. When that happens, no one typically migrates everything. A typical move brings across the master data, meaning customers, vendors and materials, along with around two years of transactions. Carrying twenty or so years of history into a new platform is unnecessary and expensive.

The complication is that the historical data still has to be kept, and retention rules vary around the world: seven years under many tax regimes, ten in others, and as much as a hundred years in China. So the old system stays switched on purely to preserve data that no one uses day to day. In effect, the organisation pays for two systems at once, the new one that runs the business and the old one that simply holds the past.

Keeping a legacy system in production is far more expensive than it looks. There is the software licensing, the hardware, which typically needs refreshing every five years, a database that may no longer be supported in ten years’ time, and the operating system beneath it. Every layer carries cost and demands specialist attention. And the older a system becomes, the more exposed it is: unsupported software stops receiving security patches, which makes ageing systems an increasingly attractive target for cyber-attack.

15%   of IT budgets is typically spent supporting legacy systems

80%   of total cost of ownership can be removed by decommissioning

These industry benchmarks put the scale of the waste plainly. Beyond the direct cost is the opportunity cost: skilled people spend their time keeping obsolete systems alive, instead of working on the things that move the business forward.

Decommissioning is the complete retirement of a system an organisation no longer wants to run. It goes a step further than archiving, which moves inactive data aside while the original system keeps running. Decommissioning switches the source system off altogether.

The process is straightforward in principle. You identify the data you are required to keep, which might be just finance, just production, or the whole system, and however many years of it you must retain. You extract that data and move it into a system that can hold it, let business users view it easily, and report on it whenever it is needed. The old system, with all of its licences, hardware and risk, is then shut down.

• Pull out the data you are legally required to keep, at whatever depth and history you need.
• Hold it in a system designed to keep it accessible, searchable and compliant.
• Let business users and auditors find and report on it without the original application.
• Switch the legacy system off, and remove its cost and risk for good.

One of the most common surprises in a decommissioning programme is scope. An organisation sets out to retire one system, then discovers the system before it, and the one before that. Cella and its partners have decommissioned around 42 different ERP systems, including Oracle, SAP, Navision and JD Edwards, alongside bespoke mainframe systems that customers wrote themselves. The rule of thumb is simple: anything with a database can be decommissioned.

The challenge grows with age. Cella has retired systems that had been running since the early 1980s, where the organisation still needed the data but had lost all knowledge of how the system worked. In those cases the work becomes almost forensic, understanding the system table by table to see how it fits together. The older the system, and the less institutional knowledge that survives, the more valuable it is to retire it before that knowledge disappears entirely.

The business case is not theoretical. One global energy company has decommissioned 142 systems with Cella, a mix of SAP, including ECC 6 and S/4HANA, and non-SAP platforms, and continues to retire more each year.

Programmes on this scale are typically self-funding. The saving released by decommissioning the first, most expensive system pays for the next, so the programme builds its own momentum, taking cost out of the estate year after year rather than adding it.

Retiring a system is only worthwhile if the data remains genuinely useful afterwards, and that means more than moving it into cheap storage. Business users need to view records easily, and finance and audit teams need to report on them, sometimes many years later.

This is why a data lake or warehouse is not the answer on its own. Enterprise data is multi-tiered: a single product’s master data can span twenty to thirty tables, a supplier can sit nine or ten layers deep, and a purchase order deeper still. Move that into a data lake and the relational structure, the schema, is lost, leaving you to reassemble everything about a supplier or product by hand. The data has to be held somewhere that understands the schema.

“Without the schema, you end up extracting the data with a pair of tweezers.”

A modern decommissioning platform goes further still, bringing historical data back together with the live system when it is needed. A single asset, such as a section of pipeline, might have two years of history in the new system and ten years in the retired one. Combined reporting presents both in a single view, so nothing is lost by switching the old system off.

Legacy systems rarely announce themselves as a problem. They sit quietly in the background, consuming budget, tying up specialists and widening the organisation’s exposure to risk, until a migration, an audit or a security review brings them into focus. Decommissioning turns that liability into a controlled, one-off exercise that removes cost permanently while keeping every record that matters.

The best place to begin is an assessment: identify the systems that are no longer core, quantify what each one costs to keep running, and confirm what data must be retained and for how long. From there, the most expensive system is usually the one to tackle first, because the savings it releases can fund the rest.