Everyone Tests the Cutover Weekend. Almost Nobody Tests the Six Months Either Side of It.
Everyone Tests the Cutover Weekend. Almost Nobody Tests the Six Months Either Side of It.

Everyone Tests the Cutover Weekend. Almost Nobody Tests the Six Months Either Side of It.
New Zealand is quietly entering its biggest wave of core banking replacement in a generation. Several major banks have already signed with new core banking platforms, and more will follow, because the legacy cores running much of NZ banking are at the end of the road and everyone knows it.
Here’s what I keep noticing in how these programmes are planned. The go-live weekend gets rehearsed like a moon landing. Runbooks, war rooms, rollback plans, dress rehearsals. And it should — it deserves that attention.
But almost nobody prepares properly for what comes next: the parallel run. Months of operating two cores, two general ledgers, two sets of interest logic, with real customers split across both. That’s not the victory lap after go-live. That’s where core banking programmes get found out.
Why the parallel run is the real test
Big-bang cutovers are nearly extinct, and for good reason. Regulators want contingency plans nobody can afford, so banks migrate in waves instead. Sensible. But phased migration doesn’t eliminate risk — it trades one enormous risk for a long tail of smaller ones that compound quietly.
Four in particular.
Reconciliation drift. Your daily reconciliation between old and new core is “within tolerance.” Great. But a small daily variance, left unexplained, compounds across a quarter. By the time finance asks the hard question, you’re archaeologists digging through three months of postings. A tolerance you can’t explain isn’t a tolerance. It’s a defect you haven’t found yet.
Period-end only fires once. Month-end close, interest capitalisation, tax year processing — these events run once per cycle. You get exactly one shot at seeing them behave correctly with live data. If your test environments never genuinely exercised period-end across both cores simultaneously, your first month-end in parallel run is your test. With customers attached.
Downstream systems pointing at the wrong core. Statements, cards, internet banking, regulatory reporting — every one of them now needs to know which customers live on which core. One misrouted integration and a subset of customers gets statements generated from stale data. Nobody notices until a customer does.
Regression debt on a moving target. Hotfixes go into the new core while the old one keeps running. Every patch during parallel run is a change to a system that’s half in production. If your regression coverage doesn’t keep pace, you’re accumulating risk in the exact period the programme is declaring victory.
The uncomfortable part
None of this shows up in the systems integrator’s status report. Not because anyone is lying — but because the implementation partner’s incentives point at delivery milestones, and parallel run stability is a milestone nobody gets a bonus for. “Cutover complete” is a headline. “Ninety days of clean reconciliation” isn’t.
That’s why the readiness view that matters is the one the bank owns, not the one the vendor produces. If the only people telling your board the migration is going well are the people paid to migrate it, you don’t have assurance. You have marketing.
What good looks like
If you’re a programme director three months out from your first migration wave, three things are worth fighting for now:
Reconcile the full population, not a sample. A 99.9% reconciliation rate sounds excellent until you do the maths — on 180,000 accounts, that’s 180 customers with wrong balances. Automated full-population reconciliation is entirely achievable, and it’s the only version that lets you sleep.
Agree the tolerance model with finance before cutover, not after. What variance is acceptable, for how long, and who signs off on exceptions? If that conversation happens post-launch, it happens as a negotiation under pressure.
Test period-end as an event, not a date. Build the capability to run month-end across both cores in a controlled environment before you have to do it live. The first real one shouldn’t be the first one.
The banks that get this right won’t be the ones with the flashiest cutover. They’ll be the ones that treated the boring six months afterwards as the main event — because it is.
Brendon Lang is a director at Resync, an independent quality engineering consultancy working across New Zealand’s public and private sector.
