Modernising banking integration infrastructure with decommissioning funded from the start, per-interface rollback, and a plan that does not treat every interface the same.
Integration platform programmes are measured in interfaces migrated. The number that matters is interfaces retired, because until the last consumer has moved, the institution is running two platforms, paying for both, and maintaining skills in both.
The default plan is to move everything to the new platform. It is the usually the most expensive plan and it preserves whatever was wrong with the estate. Each interface deserves one of six decisions.
Middleware approaching end of support
Which converts a choice into a deadline.
Skills concentrated in very few people
And a retirement date is a programme risk.
Point-to-point connections on the platform
The platform was bought to prevent exactly this.
Proprietary tooling and formats
Which makes every estimate a guess.
Deployment that requires an outage window
So changes batch up and get riskier.
No observability inside the flows
A message in flight is invisible until it fails.
Licence and maintenance cost rising
Usually the reason the programme gets funded.
Two platforms from the last migration
Because the previous decommissioning was cut.
Ask what happened to the platform the last migration was supposed to replace. In a large share of institutions it is still running, carrying a handful of interfaces nobody would fund moving. That is the most relevant evidence available about how this programme will end, and it is also the strongest argument for funding decommissioning at the outset rather than hoping for it at the end.
Every part of a migration programme has a sponsor except the last one. Building the new platform is visible, migrating interfaces shows progress, and turning the old one off produces nothing anybody can demonstrate.
So we plan backwards from the decommissioning date, treat it as the programme’s actual deliverable, and sequence the work so that the residual interfaces are dealt with while there is still money and attention available.
Step 1
Discover the full integration estate, including the undocumented parts
Step 2
Analyse dependencies and identify the consumers of each interface
Step 3
Classify every interface against the six decisions in section 2
Step 4
Assess the target platform on operability, not on feature lists
Step 5
Define the target architecture and the delivery practice together
Step 6
Set the decommissioning date and fund it as a deliverable
Step 7
Sequence by risk and by counterparty availability
Step 8
Migrate in waves, with a rollback path for each interface
Step 9
Run in parallel and compare outputs before cutover
Step 10
Cut over per interface, with the consumer agreeing the outcome
Step 11
Track interfaces retired as the primary programme measure
Step 12
Decommission the old platform, and verify nothing still calls it
For the next interface you plan to cut over, ask who decides to roll back and at what point. If there is no name and no threshold, the decision will be made in a conference call during an incident, by whoever is most senior and least informed. Agreeing both takes ten minutes beforehand and it is the difference between a controlled reversal and an hour of discussion while the interface is failing.
Grouped by what each part does. The retirement group is the one that determines whether the programme finishes or simply stops.
Platform modernisation
Middleware and enterprise service bus modernisation, including migration away from proprietary tooling
Messaging platform migration, with queue and topic semantics preserved or deliberately changed
API management modernisation, including gateway migration and policy rebuild
Event-driven architecture adoption where it suits the flows, rather than as a wholesale conversion
Cloud and hybrid integration, including the connectivity between what moves and what does not
Containerised integration services, where that improves deployment and recovery rather than for its own sake
Migration delivery
Integration estate discovery and dependency analysis, which is where every one of these programmes should begin
Interface classification against the six decisions, with retirement and consolidation identified first
Phased migration with per-interface rollback and a tested switch
Parallel running and output comparison before each cutover
Counterparty coordination, including the scheduling work that is usually the critical path
Delivery practice
Pipelines for integration artefacts, so a change is deployed rather than installed
Infrastructure and configuration as code, so the estate can be rebuilt rather than recovered
Reusable integration templates and patterns, which is what stops the new platform filling with bespoke flows
Self-service onboarding for new interfaces within a governed pattern
Observability built into the platform rather than added per interface
Retirement
Interface-by-interface retirement tracking as the primary programme measure
Residual interface resolution, including the ones whose owner has left
Verification that nothing still calls the old platform before it is switched off
Decommissioning itself, including licence termination and the removal of the connectivity
These are the shapes this work takes. In each case the engineering is well understood and the underestimated part is named alongside it.
Legacy middleware replacement
An end-of-support or end-of-life platform that has to be replaced, usually with a date attached.
Point-to-point consolidation
Replacing a web of direct connections with governed, reusable interfaces.
Messaging platform migration
Moving queues and topics to a supported or cloud-native messaging platform.
API gateway migration
Moving API traffic, policies and consumers to a new gateway.
Batch to event transformation
Converting batch flows to event-driven ones where the business value justifies it.
Hybrid cloud connectivity
Connecting integration services in cloud with systems that are not moving.
Enterprise integration standardisation
Establishing patterns, templates and ownership so the next five years of interfaces are built consistently.
Before consolidating interfaces, run the old and the new side by side and compare the output. Not the design, the output, message by message. Every difference is either a deliberate adjustment you have just rediscovered or a defect you are about to ship. This is a few days of work per consolidation and it is the single most effective control available on this kind of migration.
We work within your platform decisions, hosting policy and operating model. Two properties separate a modern integration estate from a legacy one, and neither of them is a feature in a product comparison.
Integration runtime
On premises, cloud or platform as a service, per your hosting policy.
API management
Gateway, policies, versioning, consumer visibility.
Messaging and streaming
Brokers and event streams, with semantics stated explicitly.
Containerised services
Where it improves deployment and recovery, not by default.
Hybrid connectivity
Between what moves and what stays, with the network as a component.
Pipelines
Build, test and deploy for integration artefacts.
Infrastructure as code
So the estate can be rebuilt rather than restored.
Observability
Built into the platform, as the sub-section below argues.
Most of this page is about reducing risk over the long run. During the migration, risk goes up, and that period needs controls of its own rather than the controls designed for steady state.
Interface ownership
Named, recorded, and established before migration not after.
Security standards
Authentication, encryption, secrets and key management to your standards.
Change governance
Each cutover through your change process, with rollback stated.
Versioning
Contracts versioned so consumers are not forced to move in lockstep.
Backward compatibility
Maintained through the migration, as the sub-section below sets out.
Data integrity
Nothing lost, duplicated or reordered across the cutover.
Resilience
Recovery behaviour verified on the new platform, not assumed from the old.
Rollback
Per interface, tested, with an owner and a threshold.
Decommission control
Retirement approvals recorded and evidence retained, since switching off a banking interface is a change that will be asked about.
Connect banking systems, payment platforms, and external services to enable secure data exchange and connected financial experiences. From core banking and payment integration to open banking APIs, application connectivity, and integration platform modernization, help banks streamline workflows, improve interoperability, and support digital innovation.
A migration programme reports what is easy to report, which is interfaces built on the new platform. That number rises steadily while the old platform stays exactly where it is.
The programme measures, in order of honesty
Interfaces retired from the old platform, which is the only measure that corresponds to the programme finishing
Interfaces remaining on the old platform, with named owners, because the residual is the risk and it should be visible from the first month
Consumers still to migrate per interface, since an interface is not done until the last one has moved
Compatibility layers live and their expiry dates, which prevents temporary becoming permanent
And the old platform’s licence, support and hosting cost still being paid, which is the number the business case was built on
The platform measures, once it is carrying load
Interface reliability and error rate per flow, trended rather than counted
Throughput and latency, as percentiles, with capacity headroom stated
Integration incidents by cause, which identifies the next thing to fix
Platform utilisation and cost, since a modern platform makes cost visible in a way legacy middleware did not
Deployment frequency and lead time for an interface change, which is the practice measure
Recovery time from a failed flow, measured rather than estimated
Change failure rate alongside deployment lead time, because faster delivery that breaks more often is not an improvement and reporting lead time alone hides it
The proportion of flows that have both tracing and a named owner, which is the single best measure of whether the new estate is actually better than the old one
Age of the oldest pending item per flow, which is the earliest warning most estates do not have
And technical debt: interfaces outside the pattern catalogue, which is how the new estate starts to resemble the old one
Put interfaces retired on the programme report, next to interfaces migrated, from the first month. The gap between those two numbers is the programme’s real position and it will be uncomfortable early, which is the point. A programme that reports only what it has built can run for two years and end with two platforms. A programme that reports what it has removed cannot.
Outcomes depend on your estate, your target platform and how much of the practice work is included. These are the changes the work is aimed at.
One integration platform rather than two, with the old licence, support and hosting cost ended
Interfaces that nobody consumed are retired rather than migrated at full cost
Duplicate interfaces are consolidated, with each difference found and decided rather than discovered
An interface change is deployed in days rather than scheduled into a window
An operator can see a message in flight without a developer and without a log search
Configuration lives in version control, so the estate can be rebuilt and every change is reviewable
Each cutover has evidence attached, so the programme can demonstrate its own control to audit
Skills risk falls, because the platform uses capabilities available in your market
And new interfaces are built within a pattern catalogue, which is what stops this recurring in eight years
Bring us your integration estate, documented or not, and we will inventory it, classify every interface against the six decisions, identify what can be retired before anything is migrated, and set out a sequence with a decommissioning date attached.
CaliberFocus modernises banking integration infrastructure with decommissioning funded from the start and measured in interfaces retired rather than interfaces migrated. We classify every interface before moving it, choose target platforms on operability, migrate with per-interface rollback and parallel running, and change the delivery practice so the new estate does not become the old one.
- Interfaces retired tracked as the primary programme measure
- Every interface classified, with retirement and consolidation first
- Per-interface rollback with a named owner and a tested switch
- Configuration as code and observability built into the platform
Security & Compliance
