Why ME Bank's Engineers Aren't to Blame

The pattern is older than the internet

Large-scale platform migrations follow a predictable arc. A business decision is made — consolidate platforms, cut costs, modernise. A timeline is set. Milestones are locked. And then, as the go-live date approaches, the gap between what was planned and what was actually built gets papered over with optimism and organisational pressure.

The engineering team raises concerns. Those concerns get logged in Jira. The go-live happens anyway.

We do not know exactly what happened inside ME Bank. What we do know, from public reporting, is the outcome: 300,000 customers migrated, BSBs changed, direct debits wiped, house settlements delayed, call centres overwhelmed.

This is not a story about bad engineers. It is a story about a process that gives engineers no objective way to say this batch is not ready.

They shipped before a long weekend

The latest tranche of customers migrated just before the Easter long weekend in Australia. This is one of the most well-documented deployment anti-patterns in the industry: ship before a public holiday, when support staff are reduced, on-call engineers are unavailable, and customers have four days to discover everything that is broken before anyone can respond.

It is so common it has a name. Never deploy on a Friday is a joke in engineering circles — except when it is not.

Deployment timing is a measurable risk signal. Friday afternoon deployments have a 3x higher change failure rate than Tuesday through Thursday deployments, according to DORA research. Shipping before a multi-day public holiday compounds that risk further. This is something that can be flagged automatically — before the code merges — not discovered on Saturday morning when the call centre queue is six hours long.

The compounding problem

Single-commit failures are easy to catch. Your CI pipeline flags the test. The deploy fails. You roll back.

The ME Bank migration was not a single commit. It was dozens of interdependent changes — schema migrations, identity verification flows, card provisioning systems, direct debit references — shipped in tranches over weeks. Each change, reviewed in isolation, probably looked fine. Together, they had a blast radius nobody fully modelled before each batch went live.

This is the hardest class of deployment failure to prevent: not one bad decision, but the compounding effect of many reasonable ones.

What good looks like

Organisations that ship large migrations safely tend to do a few things differently.

They score risk before merge, not after incident. Every pull request gets evaluated against signals — schema migrations, change entropy, file churn history, the blast radius of affected downstream services, CODEOWNERS compliance. A high score triggers a conversation before code ships, not a post-mortem after customers call in.

They treat schema migrations as hard gates. A DDL change that modifies account identifiers or BSB fields should never slip through a standard review. It should require explicit sign-off, a rollback plan, and a migration window — automatically flagged by tooling, not by someone remembering to check.

They model blast radius across services. A change to an account identifier does not just affect the account service. It propagates — to direct debits, to card provisioning, to identity verification, to the call centre scripts. Blast radius propagation means understanding the full surface area of a change before it ships.

They flag high-risk deployment windows automatically. A deploy scheduled for the Thursday before Easter should trigger a risk escalation — not because the code is bad, but because the recovery window is four days long and support is at half capacity.

They give engineers a number they can show a steering committee. The hardest part of a large migration is not the code. It is saying we are not ready to a room full of people with a launch date on their slides. An objective risk score — this batch scores 87, our threshold is 70, we should not ship Friday — takes the politics out of it.

The engineers were not flying without instruments. They were flying with the wrong ones.

DORA metrics tell you what broke after it broke. Sprint velocity tells you how fast you are going. Neither tells you whether the next deployment is safe to ship.

That is the gap Koalr is built to fill. Every pull request gets a 0–100 risk score based on 36 pre-merge signals — before it merges, before it reaches customers, before the call centre is overwhelmed.

We cannot speak to what tools ME Bank's team had available. What we can say is that the pattern — large migration, compounding changes, no objective pre-merge risk signal, catastrophic customer impact — is one we see across the industry. And it is preventable.

Source: ME Bank customers rage as nightmare app rollout blocks access to their money — news.com.au, April 1, 2026