01Why do core banking transformations go wrong?
Core banking transformations go wrong in seven places, and each one has a control that works when it is put in early.
- Data. Quality problems surface in the first mock migration, months after the plan assumed clean data. Control: profile and cleanse from month one.
- Integration. The core feeds payments, cards, channels, the ledger and regulatory returns, and every interface is a release risk. Control: an interface inventory, each with a named owner.
- Scope. Every product variant and legacy exception gets carried across. Control: retire products and variants before they migrate.
- Sequencing. Too much is packed into one big release. Control: a value-dense first release, then waves.
- Cutover. It is rehearsed once, or never at full volume. Control: timed dress rehearsals with the people who will do it on the night.
- Vendor dependence. The program plan is the vendor's implementation plan, and the bank can't see its own critical path. Control: the bank owns one integrated plan across every vendor.
- People. Training lands at the wrong time, and the few people who understand the old core leave mid-program. Control: training timed to each wave, and cover for key people.
02Should you replace the core, rebuild it, modernise progressively or simplify first?
The first decision is which of four options fits, and sometimes the safest core banking replacement is a delayed one.
- Simplify first. Cut products and variants, close dormant accounts, fix the data and retire satellite systems, then decide with less to move.
- Modernise progressively. Keep the ledger and move product, origination and customer capability onto modern components around it, one piece at a time.
- Replace. Implement a new core platform, migrate products and customers in waves, and retire the legacy core last.
- Rebuild. Build a new core for a new proposition or brand beside the existing bank, prove it with new customers, then move existing customers across.
A decision test. Answer five questions before any platform is chosen:
- Will the current core be supported for the life of the strategy?
- Can it deliver the next three products the strategy depends on, including real-time payments?
- How many products, variants and known data problems would move with the customers?
- Can the bank fund and staff a multi-year program alongside business as usual and regulatory change?
- Is a merger or a shared platform on the horizon?
Support ending and products the core can't build point to replacement or a rebuild. A supported core that is slow to change points to progressive modernisation. A long answer to question 3 means simplify first, whatever else is true. For mutual banks, question 5 can decide the whole answer: read Lead, Follow, or Merge.
03What core banking migration strategy keeps the risk down?
A core banking migration strategy keeps risk down when value arrives early and customers move in small, rehearsed steps, with the legacy core retired last.
- Choose a value-dense first release. One product, one segment, real customers and real volume, chosen because the strategy needs it: a new transaction account or a term deposit, for example.
- Run old and new side by side. Agree which core is the source of truth for each product, and give staff one view of the customer across both.
- Pilot, then move in waves. Staff accounts first, then a small customer segment, then waves sized to what reconciliation and the contact centre can absorb.
- Retire the legacy core last, once the final wave has reconciled and hypercare has closed.
A worked example: a regional bank launches a savings product on the new core for staff, opens it to new customers, then moves existing savings accounts in three waves. Home loans wait until several month-end cycles have run cleanly.
The first release sets the pace for everything after it. In one core banking transformation, a value-dense first release meant the core banking platform was delivered in nine months: the world's fastest SAP core banking rollout at the time, with 30+ systems integrated.
Read the core banking transformation case study →
04How do you reduce core banking migration risk in the data?
Most core banking migration risk sits in the data, and it is reduced by proving that every account moves correctly, to the cent, before any customer moves.
- Profile early. Measure legacy data quality in the first month, and fix it at the source.
- Map everything that defines an account. Balances, accrued interest, transaction history, fees, offsets, mandates, direct debits and scheduled payments.
- Run mock migrations at full volume. Several, each timed, with the defect trend reported to the steering committee.
- Reconcile automatically, account by account. Balances, accrued interest, transaction counts and general ledger totals, compared by code for every account, with no sampling.
- Own every exception. Each one gets an owner, a fix and a re-test before the next rehearsal.
- Sign off formally. Finance and risk sign the reconciliation before each wave moves.
Migration to this standard has been done at scale. One banking platform migration moved $9.6B and 500k+ accounts with zero major incidents and cent-accurate reconciliation.
Read the banking platform migration case study →Data Migration & Data Services →
05How should integration and testing work in a core replacement?
Integration and testing work when the new core is proven against every system around it, with realistic volumes, before any customer depends on it.
- High-fidelity test harnesses. Simulate payment schemes, card processing, channels and downstream feeds, so testing never waits on an external party.
- End-to-end tests by customer journey. Open an account, pay a bill, take a card payment, receive interest, close the account, run end of month.
- Parallel runs. Process the same days of real activity through both cores and compare balances, interest, fees, statements and ledger postings line by line, fixing every difference before the first wave.
- Peak-volume performance testing. Payday, month end and end of financial year.
- Regression on every release, automated where possible, because the core keeps changing while migration continues.
06How do you run a safe core banking cutover?
A safe core banking cutover is rehearsed until it is routine, decided at gates agreed in advance, and backed by a rollback that has been tested.
- A timed runbook. Every step, owner and dependency, minute by minute, across the bank and every vendor.
- Dress rehearsals. Full rehearsals of the cutover weekend, with the people who will run it, until the timings hold.
- Go or no-go gates. Criteria set weeks ahead (reconciliation results, open defects, vendor readiness, contact centre staffing) and signed by the accountable executive.
- A tested rollback. A defined point of no return, and a rollback rehearsed as seriously as the cutover.
- A command centre. One room, one decision log and one escalation path.
- Hypercare. Extra support, service guardrails and daily reconciliation, with exit criteria agreed before go-live.
Regulation makes these controls a board matter. Under APRA's CPS 230, fully in effect for every APRA-regulated entity from 1 July 2026, payments and deposit-taking are critical operations for an authorised deposit-taking institution, each with board-approved tolerances for maximum disruption, data loss and minimum service levels. Set the cutover window, rollback point and hypercare service levels inside them.
Cutover & Transition Management →
07How should a bank govern the program and its vendors?
The bank governs the program safely when it owns one integrated plan, one accountable executive and one view of risk across every vendor.
- One plan. The core vendor, integrator, payments and card providers and hosting partner all work to the bank's critical path.
- Milestones tied to commercials. Payments to vendors follow proven outcomes: a reconciled rehearsal, a passed parallel run.
- A steady cadence. Weekly delivery forums, a monthly steering committee, and independent assurance reporting to the board at each stage gate.
- Material service providers. CPS 230 requires a bank to manage the risks of the providers its critical operations rely on, and a core platform provider will usually be one of them.
Assess platform options on business value, cost and risk, not tied to any one vendor, so the board's choice stands up to scrutiny.
08What do customers and staff need during the move?
Customers need to know exactly what changes for them and when, and staff need to be trained and supported in time for the wave they serve.
Customers. Tell them what changes: account details, cards, direct debits, online banking access and statements. Give notice well ahead of each wave, remind them close to the date, and watch complaints and call volumes daily afterwards.
Staff. Train each team just before its wave, in a practice environment loaded with realistic data. Give the contact centre scripts, extra staff and a direct line to the command centre, with floor support in branches for the first days.
09What should the board ask at each stage?
The board de-risks a core banking transformation by asking a few direct questions at each stage, and expecting evidence in return.
| Stage | Questions for the board |
|---|---|
| Decision | Why replace now? Which option did we reject, and why? What does the decision test say? |
| Plan | What is in the first release, and why? Who owns the integrated plan? Which products are being retired before they migrate? |
| Build and test | How many interfaces are tested end to end? What did the parallel run show? |
| Rehearsal | How many full-volume mock migrations have reconciled to the cent? Are the cutover timings holding? |
| Go or no-go | Are the criteria met, in writing? When is the point of no return? When was rollback last rehearsed? |
| Hypercare | Are complaints, call volumes and reconciliation within the agreed limits? What has to be true to close hypercare? |
10Where should a bank start?
Start by finding out how ready the program is for migration and cutover, before committing to a date.
The Transformation Maturity Assessment for core banking scores your readiness for migration and cutover across 6 weighted dimensions in 5 minutes, and sends an instant PDF report with strengths, blind spots and next steps.
Take the core banking assessment →
Related reading: Financial services →
Notes and sources
- Critical operations and tolerance levels for an ADI: APRA, Prudential Standard CPS 230 Operational Risk Management
- CPS 230 commencement (1 July 2025) and full effect for all entities (1 July 2026): APRA, Response to submissions, CPG 230
- Transformativ case studies: core banking transformation and banking platform migration (linked above).