Four gateways, one platform: a European bank's consolidation, one year on

A year ago, one of our customers, a retail and corporate bank operating in four European countries, completed a migration it had been circling for years: 1,400 APIs, spread across four gateways from three vendors, moved onto a single governed platform. We recently sat down with the program's leaders to ask the only question that matters twelve months on: was it worth it?

The short answer is yes, but the details are more instructive than the verdict, because almost nothing landed exactly where the business case predicted.

What the business case got right

Licence and infrastructure costs fell roughly as projected, about a third below the previous run rate, once the last legacy contracts expired. Audit preparation, which had consumed six to eight weeks of assembly work per exercise across four systems, now takes days: the evidence exists in one place, in one format, with one retention policy. With DORA supervision beginning in earnest that year, the timing proved better than planned.

These were the numbers that got the program approved, and it matters that they held, because consolidation cases are often sold on savings that never quite materialize. Here they did. But the leaders were candid that if the case had rested on these figures alone, the payback period would have looked merely acceptable. The reason they now call the program a clear success lies in the effects nobody had put in the spreadsheet.

What nobody predicted

• Incidents fell by more than half. Not because any single gateway was unreliable, but because most incidents had lived in the seams: certificates expiring on the system nobody owned, policies diverging between platforms, changes coordinated by email across three teams.
• The estate shrank. Migration forced an inventory, and the inventory found nearly 200 APIs with no remaining consumers. They were retired instead of migrated, each one a small permanent reduction in attack surface.
• Delivery got faster after the freeze. Teams feared the migration would stall roadmaps, and for two quarters it did. But a year on, publishing a new API takes days rather than weeks, because there is one pipeline, one review, one way of doing things.

"We expected to save money. What we actually bought was the ability to answer questions about our own estate without launching an investigation." — Head of Integration Platforms

What links these three surprises is that each one came from removing fragmentation rather than from any single new feature. The incidents lived between the platforms; the dead APIs survived because no single inventory ever spanned them; the slow delivery came from having four ways to do everything. Consolidation did not so much add capability as remove the friction that four separate systems had quietly imposed on everything the bank did.

Advice they would give their past selves

Migrate by consumer, not by API, so each partner moves once rather than piecemeal. Retire before you migrate. And resist the temptation to reproduce every legacy behavior on the new platform: half of the exotic configurations existed only because someone worked around a limitation in 2016.

That last point drew the most emphasis in the conversation. The instinct during a migration is to preserve everything, on the theory that any behavior might matter to someone. In practice, treating the migration as a chance to question each oddity, rather than faithfully recreate it, was where much of the eventual simplicity came from. The bank's team estimates that honoring those three rules earlier would have shortened the program by a quarter. The rest, they say, went exactly as consolidations should: quietly.