Most large organisations know their legacy estate is too big. They can even name the number - the millions a year spent maintaining applications that overlap, duplicate one another, or serve a shrinking handful of users. What they usually can't produce is a roadmap: a clear, sequenced plan showing which applications can be retired, in what order, and what each retirement saves. Without one, the estate never shrinks. The cost is treated as fixed, the risk of switching anything off feels too personal to take, and the legacy simply persists.

This guide sets out how to change that. An application decommissioning roadmap is a prioritised, sequenced plan for retiring legacy applications - built on a clear inventory, an honest map of dependencies, and a categorisation of what to keep, replace, or eliminate - so cost comes out safely and predictably. Done well, it turns a diffuse, unmanaged cost into a funded programme, and it typically pays for the very transformation meant to replace it.

Why legacy estates persist

Before the method, it's worth being honest about why this rarely happens on its own. Legacy estates persist not because leaders don't care about cost, but because retiring a system is exposed in a way that keeping it is not. If a retirement goes wrong - a process breaks, a report disappears, a dependency no one knew about surfaces - the blame is immediate and personal. If nothing is ever retired, the cost is diffuse and easy to defer. So the licences renew, the servers keep running, and the estate accretes another layer with each new project.

The other reason is simple: no one can see the whole picture. In estates grown over years, often through acquisitions, no single person can say with confidence which applications are still needed, who depends on them, and what would break if they were switched off. Without that visibility, inaction is the only safe choice. A decommissioning roadmap exists to remove both problems - to make the estate visible, and to make retirement a planned, governed activity rather than a personal gamble.

What a decommissioning roadmap actually is

A good roadmap answers four questions clearly: what do we have, what depends on what, what should happen to each application, and in what order do we act. It is not a one-off audit that produces a report and gathers dust. It's a living plan, tied to the organisation's target architecture, that sequences retirements to release cost and reduce complexity while managing risk. Crucially, it names the savings - so the programme has a business case and a way to prove progress.

The five steps to build it

1. Build the application inventory. You cannot rationalise what you cannot see. Catalogue every application in the estate with the facts that matter: what it does, who owns it, how many people use it and how often, what it costs to run and license, and when its contracts renew. This last point is easy to overlook and vital - you can only retire a system in line with its notice periods, so knowing when each contract can be exited is what makes the roadmap actionable rather than theoretical.

2. Map the dependencies. This is the unglamorous archaeology most programmes skip, and it's where risk hides. For each application, understand what data flows in and out, which systems and processes it integrates with, and which parts of the business genuinely rely on it. The goal is to know, before you touch anything, exactly what would be affected if a given application were switched off. Good governance and cataloguing tooling - for example Microsoft Purview for the data side - helps by making data flows and lineage visible rather than tribal knowledge.

3. Assess and categorise. With the inventory and dependencies in hand, decide the fate of each application. A widely used approach sorts them into four categories: tolerate (keep for now, it works and isn't worth touching), invest (business-critical, worth enhancing), migrate (move to the new platform), and eliminate (redundant, low-value, or duplicated - retire it). The eliminate and migrate categories are where your savings live. Be especially alert to duplication: applications doing the same job that arrived through different projects or acquisitions are prime candidates for consolidation.

4. Sequence the retirements. Not everything can or should go at once. Build the sequence around three factors: quick wins (low-risk, low-dependency, high-cost applications you can retire early to prove value and fund the programme), contract timing (align retirements to notice periods so you stop paying as soon as possible), and dependency order (retire in an order that never pulls the rug from under something still in use). Tie the sequence to your migration plan, so applications are retired as their replacement capability goes live - never before, and never left running long after.

5. Execute with governance and track the savings. Run the retirements as a governed programme with clear ownership, a defined process for each decommission, and a register that tracks cost removed against plan. Measuring realised savings is what keeps the programme funded and credible, and what turns "we should rationalise" into a number the board can see improving quarter on quarter.

Decommission as you build

The single most important principle is that decommissioning and transformation are the same programme, not sequential ones. When you consolidate onto a modern platform such as Microsoft Fabric, each workload you migrate should trigger the retirement of what it replaces. This is what makes transformation self-funding: the savings from the retired estate help pay for the new platform, and the business case shifts from "spend more on technology" to "spend differently and end up spending less." A programme that stands up the new without ever retiring the old has missed half the point - and doubled the running cost in the meantime.

The question of ownership

There is a reason so many estates lack a roadmap: someone senior has to own the unwinding of systems other people built and still defend. Decommissioning is as much an organisational act as a technical one. It needs a named owner with the authority to decide a system has reached the end of its life and the resolve to see the retirement through when something proves more entangled than expected. If your estate has drifted because no one owns its reduction, that ownership gap is the first thing to fix - the roadmap is only as real as the person accountable for delivering it.

What good looks like

A mature approach looks like this: a complete, current inventory of the estate with cost and usage attached; dependencies understood well enough that retirements rarely surprise anyone; every application categorised with a clear decision; a sequenced plan tied to the migration and to contract timing; and a savings register that shows cost coming out on schedule. At that point the estate is no longer a fixed cost to be tolerated. It's a managed portfolio that gets simpler and cheaper by design.

Turn a fixed cost into a funded programme

The legacy estate isn't an immovable line on the budget - it's an unmanaged one. A decommissioning roadmap makes it visible, sequenced, and owned, so cost comes out safely and the savings help fund what comes next. The organisations that do this well stop treating legacy as a burden to endure and start treating its reduction as a source of funding and focus.

Talk to our team about building an application rationalisation and decommissioning roadmap for your estate - one that ties retirement to your migration and proves the savings as they land.