An AWS migration that retires a mutual bank's legacy banking system in stages

The legacy core a mutual bank can’t simply switch off

A customer-owned mutual bank runs on a core banking system that is often older than some of its members’ accounts. It holds the ledger, the loans, the deposits and the rules, and it has done so reliably for years. That reliability is exactly why it becomes a trap. The system works, so replacing it never reaches the top of the list, and the cost of keeping it quietly compounds.

The pressure shows up in specific places. The overnight batch that closes the books and posts interest keeps creeping later, eating into the window before the bank opens. Every new channel, a mobile app, an open-banking feed, a broker portal, wires straight into the core through a bespoke integration that someone has to build and then maintain forever. Reporting runs against the same system that members transact on, so a heavy query and a busy morning compete for the same machine. Meanwhile the people who understand the platform are retiring, and the vendor’s roadmap is heading somewhere the bank does not want to follow.

A mutual carries the obligations of a bank on a fraction of a major’s budget. The Australian Prudential Regulation Authority (APRA) holds it to the same prudential standards, including CPS 230 on operational risk management and CPS 234 on information security, and member data sits under the Privacy Act 1988. So the bar is high and the room for error is low. The instinct to fix it all at once, a clean rewrite onto a shiny new platform, is the move that has sunk plenty of larger institutions. The ledger is the system of record. You cannot stop the bank to migrate it.

Why Amazon Web Services, and a staged path off the core

The aim is a modern platform the bank can build on for a decade, reached without ever putting the whole ledger at risk on a single night. We headline these migrations on Amazon Web Services (AWS) for reasons that matter to a mutual specifically. It offers Australian regions, so member data stays onshore. It has the documented controls and shared-responsibility model that a bank’s risk team needs to map against APRA’s outsourcing and cloud expectations. And its managed services let a small team run a serious platform without standing up a data centre’s worth of operations.

The approach is the strangler-fig pattern, not a big-bang rewrite. Rather than replace the core in one cutover, we put an abstraction layer in front of it and move one capability at a time onto new services running behind that boundary. Each new service is containerised with Docker and runs on AWS, with its data in PostgreSQL, an open and well-understood database that keeps the bank off a proprietary dead end. The legacy core stays the system of record throughout. A capability is built, synchronised, reconciled against the core, and run in parallel until the figures match. Only then does traffic move to it, behind a switch that can route members straight back to the legacy path if anything looks wrong.

We start where the risk is lowest and the relief is highest, usually the read-heavy and reporting work that strains the core without owning the ledger. Lifting that off first eases the batch window and proves the pattern on traffic that cannot corrupt a balance. The harder, write-side capabilities follow once the team trusts the machinery. Nothing about this is fast, and that is the point. Each slice is a contained, reversible step rather than a leap.

Building it, and where it got hard

The architecture diagram is the easy part. The hard part is that the bank never stops, the core is the system of record, and two copies of the truth must agree while both are live.

The friction lived in data consistency during the parallel run. Once a capability is served by a new PostgreSQL-backed service while the legacy core still holds the master records, you have the same balances and transactions in two places, changing through the day. Early in a build, a reconciliation between the new service and the core drifted by a handful of cents on a small number of accounts. The cause was timing. In-flight transactions and overnight adjustments landed in the two systems at slightly different moments, so a snapshot taken mid-window compared two valid but non-simultaneous states. In banking, “off by a few cents most of the time” is not a rounding note. It is a reason to stop.

The fix was discipline, not cleverness. We synchronised changes from the core on a defined cadence, reconciled against a consistent point rather than a live snapshot, and tracked estimated and in-flight states explicitly so nothing was counted twice. Each capability stayed in parallel-run until its reconciliation had been clean for long enough to trust, and every cutover was reversible per capability, so switching members onto the new path was a decision we could undo within minutes rather than a one-way door. We proved each slice in parallel before a single member moved.

Two constraints shaped the rest. The work was documented against APRA’s CPS 230 and CPS 234 expectations as it went, not bolted on at the end, because operational-risk and information-security evidence is far cheaper to gather while you build than to reconstruct afterwards. And the whole platform was kept in an Australian AWS region with a written exit plan, so the bank’s data residency and its ability to leave were never in question.

What changed

In a representative engagement the staged move took real pressure off the core. Lifting reporting and several read-heavy functions onto AWS trimmed the overnight batch, easing a window that had been creeping past its deadline. Replacing point-to-point connections with one governed service boundary cut the work to add a new channel from weeks of bespoke wiring to days. And because every capability moved behind a reversible switch, no single step ever put the whole bank at risk, which is the outcome a board cares about most.

These figures are illustrative. They describe the pattern we see rather than a published result for a named bank. The shape is the point. The legacy core stops being the thing that dictates the day and starts being one component among several, retired capability by capability, on a platform the bank can keep building on. The bank modernises without ever betting the ledger on a single cutover.

Where this fits

A staged core migration is one application of our Legacy System Migration service, built on AWS, for Australian FinTech and Banking. It is the unglamorous groundwork that everything else depends on. Modelling credit risk, detecting fraud or adding member-facing AI all need clean, governed access to current data, and none of it runs well on an ageing core. If your batch window is creeping and every integration is a custom job, the place to start is to map your core dependencies and pick the first capability safe to lift.