← All projects

Retiring Legacy Applications: A Migration Playbook

A playbook for retiring old applications safely, and the project that proved it.

The problem

Between 2017 and 2023, our finance technology group set out to shrink an ageing application portfolio.

Old applications are hard to switch off. Nobody clearly owns the data. Nobody wrote it down. Many groups depend on it, often without knowing.

Switch one off too fast and something breaks downstream. Leave it running and you keep paying for it.

The playbook

We built a migration playbook from the lessons of earlier retirement projects. It has one goal: no surprises.

Before any work starts, we answer five questions:

  • Who are the business and technology stakeholders, and how do we know we have them all?
  • When should change management start?
  • How do we handle change requests while the old system still runs?
  • Why this deadline, and can we phase it?
  • What is the business case, and who pays for changes upstream and downstream?

Then the work runs in four phases:

  • Discovery. Inventory every component. Scan the access logs to find every input, every output and every hidden user. Map the data end to end. This phase takes the longest, and it does not stop until the system is gone.
  • Replace or consolidate. Some functions are still in use. Agree the real need with the business. Then move it to an existing system (tactical) or build the long-term fix (strategic). Simplify on the way out.
  • Decommission. Four streams run in parallel. Downstream users come first, because they have the most to lose. Upstream feeds come last. Core components sit in the middle. Quick wins run throughout: I switch off obsolete pieces early to cut risk and prove I understand the system.
  • Retire. Back up the data to retention standards. Then switch it off.

Design thinking sits under all of it: empathize, define, ideate, prototype, test. A project sponsor, change management and infrastructure partners run across every phase.

In 2021, I used it to retire a mainframe general ledger application with dozens of feeds in and out.

The proof: a 17-year-old reporting tool

I had one year to replace a 17-year-old mainframe reporting tool before its licence came up for renewal.

I spent the first nine months on alignment: stakeholders, governance approvals and the solution concept. It felt slow. It made the build fast.

  • June 2020. Defined the problem. Years of technical debt had built up.
  • August 2020. I compared options and chose Power BI in the cloud. It was low-code, worked on web and mobile, and was easier for users.
  • Proof of concept. The team built a working prototype so users could touch it and decide if it met their minimum needs. Senior management approved it after a business demo.
  • Users at the centre. Surveyed about 55 users. Set up a Teams channel for help, a wiki for manuals and videos, and a self-serve issue form.
  • February to April 2021. One of the first teams to use the Power BI deployment pipeline, with separate development, test and production workspaces. In under four weeks the team went through 13 versions of the data model and 15 report layouts. Each release took minutes.
  • June 2021. Also volunteered for a pilot of a new automated server decommission workflow. One service request assigned tasks to every infrastructure team. The servers were retired in 25 days. That normally takes two months or more.
  • October 2021. Final state.

Results

For the reporting tool:

  • A 17-year-old application retired
  • The yearly licence and upgrade cost removed
  • 4 servers decommissioned
  • 28 reports and 11 interfaces eliminated
  • Reports now on web and mobile

At the end, our business partners wrote to thank the team. That mattered most to me.

For the finance portfolio, 2017 to 2021:

  • Finance, treasury and regulatory applications: 90 down to 54
  • Mainframe applications: 33 down to 11
  • Average application age: 21.3 years down to 13.8
  • The 22 retired mainframe applications had a combined age of 590 years

What I learned

  • Discovery never ends until the system is off.
  • Engage downstream users first. They have the most to lose.
  • Quick wins build momentum and confirm what you think you know.
  • Time spent aligning people early is not wasted. It is what makes delivery fast.
  • Let users touch a prototype before you ask them to commit.

If you are planning to migrate from and retire an old system, I am happy to compare notes.