Modernising Payments Infrastructure Without a Big-Bang Migration
Legacy payment infrastructure almost never announces itself with a failure. It does not fall over on a Monday morning and force a decision. It just quietly makes everything harder.
A new payment method takes nine months to support instead of nine weeks. A batch window cannot be shortened, so settlement reporting arrives a day late and nothing downstream can move. A third acquirer cannot be added without a change to the core, so the commercial team stops asking. A regulatory change that should be a configuration update becomes a project with a business case. None of these is an outage. Collectively, they are the reason the organisation cannot do what its strategy says it will do.
The instinctive response is replacement. Choose a modern platform, run a programme, cut over, retire the old system. It is a clean story and it is easy to fund. It is also the version of payments infrastructure modernisation that most often disappoints, not because the target platform was wrong, but because the sequencing was never designed with the same rigour as the architecture. A payments modernisation strategy that opens with platform selection is answering the second question first.
This article is about that sequencing. It looks at why full-replacement programmes carry disproportionate execution risk, what the alternative actually involves, and how organisations contain risk across a migration that will realistically run for years rather than quarters.
Legacy payments systems rarely fail, they constrain
It helps to be precise about what "legacy" means in a payments context, because legacy payments systems modernisation is rarely a question of age.
A twenty-year-old system that is well documented, cleanly integrated and understood by people still employed at the organisation is not a serious problem. A seven-year-old system with undocumented business logic embedded in stored procedures, three bespoke integrations built by a departed contractor, and a release process that requires a weekend outage is a serious problem.
The constraint usually shows up in four ways.
Change cost. Every modification requires regression testing across flows that were never isolated from one another, so the cost of a small change is set by the blast radius rather than by the change itself.
Data limitations. Older payment systems were built around fixed-length fields and constrained reference data. As richer message standards arrive, the system becomes the narrowest point in the chain, it can receive structured data but cannot store or pass it on.
Coupling. Payment logic sits inside the core banking system, the order management system or the ERP rather than in a distinct layer, so changing how payments work means changing systems that have nothing to do with payments.
Operational fragility. Recovery depends on specific individuals, batch dependencies are undocumented, and nobody is willing to test failover in production hours.
Each of these is technical debt with a measurable carrying cost. What makes it dangerous is that the cost is paid in slowed delivery rather than in an invoice, so it accumulates without ever triggering a decision.
Why the big-bang case is so persuasive, and so risky
Core system replacement is attractive for reasons that are not irrational.
It promises a clean end state with no permanent duplication. It avoids the awkward interim period where two systems both hold part of the truth. It is easy to explain to a board, easy to procure against, and it gives a vendor a defined scope to price. And it removes the hardest political problem in modernisation: deciding what to do first, and defending that decision for three years.
The risk is that it concentrates every unknown into a single event, which is the least manageable shape migration risk can take. In a big-bang cutover, data migration, functional parity, performance under production volume, operational readiness, reconciliation continuity, third-party certification and staff competence are all validated at the same moment. If any one of them is wrong, the fallback is a reversion that itself carries risk, because transactions have already been written to the new system.
There is also a structural problem with duration. The longer a programme runs, the more the environment changes beneath it. Requirements captured in year one are re-baselined in year two. The regulatory landscape moves. Key people leave. The target platform releases two major versions. A programme that is three years long is not a two-year programme with more time; it is a materially different risk proposition.
What the evidence says about long programmes
This is one of the better-studied questions in delivery management, and the findings are consistent.
McKinsey, working with the BT Centre for Major Programme Management at the University of Oxford, analysed more than 5,400 IT projects and found that large projects, those with initial budgets above US$15 million, ran on average 45% over budget and 7% over time, while delivering 56% less value than predicted.
The more useful finding for anyone planning a migration is about duration specifically: the same research found that the longer a project is scheduled to run, the more likely it is to exceed both time and budget, with every additional year adding an average of around 15% to cost overruns.
And the distribution matters more than the average. In the companion academic work published in Harvard Business Review, Bent Flyvbjerg and Alexander Budzier examined 1,471 projects and found that roughly one in six was a "black swan", an average cost overrun of 200% and a schedule overrun of nearly 70%. The risk in large programmes is not that they typically overshoot a little. It is that a meaningful minority overshoots catastrophically.
None of this argues against modernisation. It argues against structuring modernisation as one long, indivisible commitment. If duration itself is a risk multiplier, then the design objective is not simply a good target architecture; it is a sequence of shorter commitments, each of which delivers something and can be stopped.
Australia has just watched this play out at industry scale
There is a live domestic example that makes the point better than any vendor case study, and it is instructive precisely because the organisations involved are sophisticated.
The Bulk Electronic Clearing System (BECS) is Australia's primary system for account-to-account payments, carrying salary, welfare, pension and bill payments. In November 2023, following consultation with members, the Australian Payments Network set a target end date of June 2030 for decommissioning the BECS framework, with volume migrating to the New Payments Platform. In 2024 the Payments System Board asked the Reserve Bank of Australia to assess the risk of that proposal, and the RBA's March 2025 Risk Assessment issued 20 recommendations addressing the risks of a disorderly transition.
On 16 December 2025, AusPayNet announced it was removing the June 2030 target end date. The stated reason was that the majority of BECS members no longer believed the industry could achieve it, and that a clear roadmap was needed to address the underlying challenges before a target date could be set again. The RBA's March 2026 update noted that with this revised approach, the nearer-term risks of a disorderly transition had largely subsided, while several areas of risk persisted.
The lesson is not that the industry failed. It is that a date was set before the sequencing was designed, and once the sequencing was examined properly, the date could not hold. A national payments migration with 87 member institutions, regulatory oversight and years of lead time still arrived at the conclusion that the roadmap has to come before the deadline.
If that is true at industry scale, it is true inside a single organisation. The end date is an output of the migration plan, not an input to it.
The incremental alternative: abstract, coexist, migrate
The pattern that works is well understood in software architecture and under-applied in payments. It has three components.
The first is a payments abstraction layer. Rather than integrating each consuming system directly to a payment processor, you introduce a layer that owns payment intent, initiate, authorise, capture, refund, query status, and expose it through a stable internal API. Consumers talk to the abstraction through API-led integration. The abstraction talks to whichever underlying processor or rail is current.
This is the single highest-value early move, and it is worth understanding why. On its own it delivers no new capability. What it does is decouple the pace of change of the front end from the pace of change of the back end. Once consuming systems no longer know which processor handles a payment, you can change processors without changing consumers. The migration stops being an enterprise event and becomes a routing decision.
Building this layer well requires resisting a specific temptation: it must not become a passthrough that leaks the underlying platform's semantics. If your internal API exposes fields that only exist because the current processor requires them, you have added a hop without buying independence. The interface should express what the business does, not what the incumbent platform happens to need.
The second is coexistence architecture. Old and new run in parallel, each handling a defined subset of traffic, with a routing mechanism deciding which flow goes where. This is what makes progressive migration possible: you are never choosing between old and new at an enterprise level, only for a specific flow at a specific moment.
The third is the strangler pattern, named by Martin Fowler after the strangler fig that grows around a host tree and gradually replaces it. New capability is built around the legacy system and traffic is progressively redirected, until the old system is handling nothing and can be switched off without ceremony. The decommissioning becomes an anticlimax rather than a cutover weekend.
Together these give you what a big-bang programme cannot: reversibility. At every point in the migration, the previous state still exists and traffic can be routed back to it in minutes rather than restored from backup over a weekend.
Sequencing: which flow goes first
Once you can migrate flow by flow, the question becomes which flow, and this is where most phased migration plans go wrong in one of two directions.
Starting with the hardest flow is defensible in theory, prove the hardest case and the rest follows, but it means the longest possible time before anything is demonstrated, on the flow with the most stakeholders and the least tolerance for disruption. Programmes that start here often spend eighteen months without a production migration, which is exactly the profile that loses executive support.
Starting with the most trivial flow has the opposite problem. You migrate something so peripheral that it exercises none of the real integration, reconciliation or operational questions, declare success, and then discover on the second flow that nothing you learned transfers.
The useful selection criteria are narrower than "easy" or "hard":
Volume high enough to be a real test of performance and reconciliation, but not so high that a failure is a headline.
A contained blast radius, a flow whose failure affects one channel, one product or one customer segment rather than everything.
A clean reversion path, meaning you can route back without leaving orphaned state behind.
Real representativeness, in that it exercises the integrations, exception paths and reporting that later flows will also need.
An engaged business owner, because a migration with no owner on the business side will stall at the first ambiguity.
Contrary to instinct, the sequence should usually be driven by risk containment rather than by business value. The first migrations are learning exercises that happen to be in production. The value case is realised in the middle of the sequence, not the beginning.
Containing risk during a multi-year coexistence
Dual running is where incremental modernisation earns its reputation for being messy, and the criticism is fair if it is done casually. A few disciplines make the difference.
Shadow processing before live routing. Send a copy of production traffic to the new platform without acting on the result, and compare outputs. This surfaces the difference between "the new system works" and "the new system produces the same answer as the old one for the same input", which are not the same claim.
Reconciliation across both platforms from day one. During coexistence, the organisation's payment position is split across two systems. If the reconciliation model is not extended to cover both before the first flow moves, the finance function loses visibility at precisely the moment it most needs it. This is the most commonly underestimated workstream in payments platform migration.
Explicit reversion criteria, defined in advance. Not "we will roll back if there are problems", but a named set of thresholds, error rate, latency, exception volume, settlement variance, and a named person authorised to invoke reversion without convening a steering committee.
One source of truth per flow, never two. Coexistence means different flows live on different platforms. It must not mean the same flow is half-processed on both. The moment a single flow's state is split across two systems, reconciliation and support both become intractable.
A decommissioning trigger for every migrated flow. The characteristic failure of incremental modernisation is not a bad migration; it is a migration that stops at eighty per cent. The legacy system stays alive for a residual set of flows nobody wants to touch, and the organisation now pays for two platforms permanently. Every flow moved should have a defined date and owner for retiring its legacy path.
The costs of incrementalism nobody mentions
Intellectual honesty requires acknowledging what the incremental approach costs, because a plan that pretends otherwise will not survive its first budget review.
You will run two platforms for longer, and you will pay for both. Integration and routing logic is real engineering work that produces no visible business feature. Coexistence adds operational complexity, support teams need to know which platform a given transaction lives on, and runbooks have to cover both. Total programme cost, measured end to end, is often higher than the theoretical cost of a clean replacement.
The argument for it is not that it is cheaper. It is that it is more likely to finish, that value arrives progressively rather than at the end, and that failure at any point is a contained incident rather than an enterprise event. Given what the delivery research says about the distribution of large-programme outcomes, paying a premium to convert a low-probability catastrophic risk into a series of manageable ones is usually a rational trade.
The resilience and governance dimension
There is also a control argument that has sharpened in Australia.
Since 1 July 2025, APRA's Prudential Standard CPS 230 has required regulated banks, insurers and superannuation funds to manage operational risk and maintain critical operations through severe disruption, with clear accountability and demonstrable controls. Payment processing is a critical operation under any reasonable reading.
A big-bang cutover of a critical operation is, by construction, a period of concentrated operational risk with limited reversibility. A phased migration with shadow processing, defined reversion thresholds and flow-level rollback is easier to evidence as a controlled change, because it produces the artefacts a regulator or auditor would ask for as a by-product of how it runs. Operational resilience, in the sense the standard uses, is easier to demonstrate when change is reversible by design.
The same logic applies to the near-term change agenda. The cross-border migration to ISO 20022 completed its coexistence period on 22 November 2025, and the Reserve Bank's reforms to card surcharging and interchange take effect on 1 October 2026. Both compete for exactly the delivery capacity a modernisation programme consumes. An architecture that lets mandatory changes be absorbed at the abstraction layer, rather than requiring core changes mid-programme, is worth a great deal in that environment.
What Australian technology leaders should take from this
The diagnostic questions are more useful than any target architecture.
If you had to add a new acquirer or payment method next quarter, how many systems would need to change? If the answer is more than one, you do not yet have a payments abstraction layer, and that is the first piece of work regardless of what platform you eventually run.
Can you route a single payment flow to a different processor without a release? That capability is what converts a migration from an event into a series of decisions.
What is your reversion time for a flow that has been migrated, minutes, hours, or a weekend? If it is a weekend, you are running a sequence of small big-bangs rather than a phased migration.
Does every flow already on the new platform have a named date and owner for switching off its legacy path? Without that, the programme will stall at partial completion and the saving will never arrive.
And is your end date derived from your sequence, or is your sequence being compressed to fit an end date that was set first? The BECS experience is a reminder of which order works.
Getting payments infrastructure modernisation right
The outcomes worth aiming for are commercial: the ability to add rails, methods and providers in weeks rather than quarters; regulatory and scheme changes absorbed as configuration rather than as projects; reduced operational fragility in a critical business function; and a modernisation path that delivers value progressively instead of at a single distant point.
Getting there depends less on platform selection than most business cases assume, and far more on sequencing, interface design and the discipline of the coexistence period. The abstraction layer has to express your business rather than your incumbent vendor. The migration order has to be chosen for risk containment. Decommissioning has to be planned at the same time as migration, not afterwards.
This is where implementation experience counts. Conexxia works with Australian banks, insurers, telcos and travel businesses on payments infrastructure modernisation, designing abstraction and coexistence architectures, sequencing migrations for reversibility, and keeping settlement and reconciliation intact while flows move. It is the same approach we bring across our payments consulting practice, from payments orchestration strategy and payments operations through to cross-border payments and payments compliance and risk.
None of this requires committing to a full replacement to begin. Most organisations get there by building the abstraction first, migrating one contained flow to prove the pattern, and only then deciding how far and how fast the rest should follow.
If your payments roadmap currently depends on a single cutover weekend, that is the assumption worth testing first.
Aftab Khan
Head of Payments Consulting
On a mission to help change the world, one experience at a time
I collaborate with progressive businesses to deliver successful business outcomes in 4 key areas: Increasing Revenues, Improving Operational Efficiencies, Regulatory Compliance and Elevating Customer Experience, leading to sustainable business growth.
Comments