Case study: 144 applications, and what deserved to survive

The merger was announced with a promise. When the global card network I worked for was acquired by a larger bank, the deal came with a public commitment to cost savings. Before long, that promise had become a question on my desk: across 144 partner and payment applications, which ones deserved to survive?

An estate built one sensible decision at a time

Nobody had designed the estate we had. It had grown the way most estates grow: one sensible decision at a time. Functionality was duplicated across systems. Some applications carried compliance gaps and open vulnerabilities. And custom functionality had been built on SaaS platforms that were never meant to carry it. Every one of those cost money to run, and every one made the partner experience harder to change.

The fast answer, and why I didn't take it

The fastest answer was to lift everything and shift it onto the target platform on AWS: one big move, simple to explain. But it carried too much risk and investment at once, and it would have moved our problems rather than removed them. Moving everything off SaaS was just as tempting and just as wrong, because licence commitments meant some functionality was better left where it was, for now.

The hardest scoping call was the mainframe. Leaving it out felt like leaving the job unfinished, but its exit could not be completed within three years, and the programme had to deliver inside that window. A plan that promises everything and finishes nothing helps nobody.

Rules before systems

Before we classified a single application, we agreed the principles every decision had to follow. It turned out to be the most useful thing we did: once the rules were agreed, debates were about the rules, not about whose system it was.

• Move to the cloud: the target platform on AWS is the default home.
• Fix compliance and vulnerabilities first: anything less compliant moves up the list.
• One capability, one home: remove duplicated functionality rather than migrate it twice.
• Use SaaS for what it is for: custom functionality built on a SaaS platform where it doesn't belong comes back to the target platform.

Then, area by area, we sat down with subject-matter experts and business owners and placed every application in Gartner's TIME model: Tolerate, Invest, Migrate or Eliminate. Functionality earmarked for retirement was marked as such, so nobody spent money improving something we planned to switch off.

The people behind the Eliminate box

On a diagram, Eliminate is just a box with 15 applications in it. In a meeting room, it is people. Some owners and their teams heard 'eliminate' and feared it meant their jobs, or a smaller role. That fear was understandable, and helping them through it was the biggest ask of the whole programme.

So I didn't lead with the grid. I sat down with them and walked through their path: the part their role would play in the journey, and where their knowledge would be needed next. Sometimes the honest message was simple: this functionality is being retired here, but your role is still needed elsewhere. The system was being retired. The person was not.

The move I stopped

Consolidation builds momentum, and sometimes the momentum is the risk. An application on a SaaS platform was due to move to our in-house platform within 120 days, before its licence came up for renewal. The decision had been made before I looked at it closely. When I did, there were no requirements documents behind it.

My team reverse-engineered the application and found more than 15 functional gaps and a compliance risk. That left me asking the Investment Council for the opposite of the saving they expected: keep paying for the SaaS platform. It took several presentations. The evidence won, and the move was stopped. A saving that creates a compliance risk isn't a saving.

Making the case

I didn't present the convergence as an architecture project. I built the story around the merger's own goal: what we could realistically deliver toward the promised savings in the first three years, which duplication and risk we would remove, and in what order. Quick wins and compliance fixes came first, to show progress and reduce risk early; longer strategic roadmaps followed.

The final decision sat with the divisional CIO. My job was to give him the facts, the figures and the reasoning behind every recommendation, so the decision was his, backed by our evidence. He agreed the proposal, and the Investment Council approved £40M for a three-year programme against four targets.

What I'd do differently

Discovery is the slow part of any convergence: finding every system, what it really does and where functionality is duplicated. Next time I would let AI do the first pass, mapping the systems and flagging likely duplicates from code, configuration and documentation, so the experts start from a draft map rather than a blank page.

What I'd tell another leader

• Agree the principles before you classify anything. They turn arguments about systems into decisions about rules.
• Separate the system from the person. Retiring functionality isn't retiring the people who know it, so tell them early where their role goes next.
• Scope to what you can finish. Leaving the mainframe out kept the programme credible inside three years.
• Tie the case to the business goal, not the architecture. The decision-makers funded measurable targets for cost and risk, not the diagram.
• Be willing to argue against the saving when the evidence says so.

Convergence isn't about moving everything. It's about deciding, application by application, what deserves to survive, and bringing the people with you.