You are moving a bank's existing accounts onto a new core platform. How do you cut over so there is never a moment when a customer's true balance is unknown?

The property you have to be able to prove

A core banking migration is not a data-loading exercise with a deadline. It is an assertion that at one instant the new platform holds exactly the same financial position as the old one, and everything else in the plan exists to make that assertion checkable. State it as a gate: for every account, the opening balance on the new platform equals the closing balance on the old one; the sum of all balances on the new platform equals the sum on the old one; and the two-sided total still balances, so debits equal credits and the general ledger you migrate to reconciles to the general ledger you migrated from.

Both halves matter and they catch different faults. Account-level equality catches individual records that failed to load or loaded with a truncated or misparsed amount. Control totals catch the population problems that account-level checks miss: a whole product portfolio omitted from the extract, a currency loaded at the wrong scale, a set of dormant accounts filtered out by a where-clause somebody added to make the run faster. A migration that reconciles in aggregate but not per account has moved money between customers. A migration that reconciles per account for the accounts it loaded but not in total has silently dropped a portfolio.

This is also why the extract is taken from a genuinely quiesced source. If the old platform is still accepting postings while you extract, your closing position is a moving target and the reconciliation you produce afterwards will disagree for reasons nobody can attribute. Hence the freeze window, and hence the fact that the length of that window is the single hardest commercial negotiation in the programme.

flowchart TD
  Q[Quiesce old platform] --> X[Extract closing position]
  X --> L[Load new platform]
  L --> P[Prove per account and in total]
  P --> G[Go decision]
  P --> R[Restore and reopen old platform]
  G --> O[Open new platform to customers]

The branch that matters is the one out of the proof step, because it only exists if the plan gives someone the authority and the time to take it.

Balances are the tractable half

Migrating a number is easy. What defeats programmes is everything attached to the account that is not a balance, and the honest way to answer this question is to walk the inventory.

Standing orders and direct debit mandates carry a schedule and a history: the next due date, the amount, the originator's identifier, and how many collections have already been taken against a mandate with a limit. Losing the next due date means a payment is taken twice or not at all, and both are visible to the customer within days. Losing the mandate reference means the originator's collection is rejected, which generates arrears at the other end of a relationship you do not control.

Interest is worse, because it is usually accrued daily and applied periodically, so at any instant there is an amount earned and not yet posted. Migrate the balance and not the accrual and you either pay interest twice or lose part of a customer's entitlement, in a way that will not surface until the application date weeks later and will then apply across the whole book at once. The same is true of fee counters, free-transaction allowances, introductory rate periods with an end date, and arrears counters that determine what letter goes out next.

Then there is the identity that the outside world uses. Account identifiers, card numbers and mandate references are held by third parties you cannot ask to change, so either they migrate unchanged or you run a mapping layer, and the mapping layer has to be in the payment path on day one rather than added later.

The boundary is not a line

Payments are in flight across the cutover in both directions, and each type needs an owner named in advance. An outbound payment instructed on the old platform and not yet settled has to be either completed by the old platform before it closes or restated on the new one, never both. An inbound payment arriving during the freeze has to be held somewhere with a defined release, and the somewhere must be able to hold it without rejecting it back to the sender. Card authorisations approved before the freeze will present for settlement after it, so the holds have to migrate or the settlements will find no matching authorisation. Cheques, where they still exist, and any instrument with a multi-day clearing cycle straddle the boundary by design.

Value date is the concept that makes this tractable. A transaction belongs to a date rather than to a platform, and back-dated activity keeps arriving after the cutover with a value date before it. Deciding in advance whether such items are posted on the new platform with a back value or corrected through an adjustment account is a decision with an accounting consequence, and leaving it to be handled case by case on the day is how a suspense account acquires a balance nobody can explain a quarter later.

Reversibility, and when it expires

Every plan says it has a rollback. Very few say when the rollback stops being real, and that is the sentence an interviewer is waiting for. Before customers transact on the new platform, rollback is genuine: you restore the old platform's state and reopen it, having lost only time. Once a customer has spent money, received a payment or drawn on an overdraft on the new platform, going back means replaying those transactions onto the old one, and that is a data migration in the opposite direction performed under pressure by people who have been awake for eighteen hours. In practice, the moment you open the doors you have committed to fixing forward.

That changes where the effort belongs. It goes into rehearsal rather than into contingency: full-volume trial migrations against production-scale copies, run end to end enough times that the elapsed duration is a measurement rather than an estimate, with the reconciliation output reviewed each time. It goes into a go decision defined by evidence and owned by someone with the standing to refuse — a named reconciliation passing, a named set of business validation checks, a named clock time after which you abandon and reopen the old platform because the remaining window is too short to finish safely. And it goes into a coexistence design, because migrating a large book in tranches over months is usually safer than one night with everything on it, at the cost of running a routing layer and two platforms with one customer's products split between them.

The corollary is that the scaling properties of the new platform must be known before the cutover, not discovered on the Monday. A platform that holds the balances correctly and cannot carry the login volume of the whole customer base arriving at once has failed in a way that looks identical to the customer.

What this failure looks like in the wild

In April 2018, TSB moved its customers onto a new core banking platform before that platform was ready to carry them, and the consequences ran for months rather than hours: customers locked out of accounts, balances shown wrongly, and in some cases other people's account details displayed. It ended in a parliamentary inquiry and the resignation of the chief executive. The lesson an interviewer is looking for is that the scaling properties of a core banking system cannot be separated from how you cut over to it, and that a migration needs a rehearsed, evidence-based decision to proceed and a genuine route back.