A core banking migration checklist is a control document, not a project calendar. It should show which data moves, who verifies it, what blocks cutover, and how the bank proves that the target ledger agrees with the source.

Short answer: inventory data and interfaces first, rehearse the same path more than once, reconcile before and after the final transfer, freeze transactions during cutover, and keep a usable rollback point until the target passes financial and operational checks.

At a glance

  • Preserve contractual account data, not only current balances.
  • Separate data conversion from interface and operational readiness.
  • Use production-shaped rehearsals and repeatable controls.
  • Reconcile source and target before and after final data transfer.
  • Keep posting closed until finance and operations sign off.

This guide uses Oracle Banking Accounts migration documentation for release 14.8.2, published in April 2026. Its field names are product-specific, but the control questions apply more broadly.

1. Define the migration perimeter

List every record the new core must operate on from day one: customer and account identifiers, product terms, rates, fees, maturity dates, balances, holds, limits, standing instructions, transaction history, accounting entries, accruals, restrictions and exception flags.

Oracle’s historical-data guide says a migration may need to preserve original account and maturity dates, interest rates, event history, accounting entries and prior liquidations. A balance-only export is not enough when those fields determine what the target posts next.

For each field, record its source, target, transformation, owner and reconciliation test. If something will stay in an archive, document how staff retrieve it and how long it remains available.

2. Lock identifier and file-version rules

Oracle’s account-migration guide calls for unique identifiers across migration files and a controlled upload and validation sequence. The runbook should answer which identifier is authoritative, whether the target creates a new one, how customer and transaction IDs map, and how corrected files are versioned.

Keep the mapping under change control. Support, disputes, statements and regulatory retrieval all depend on it after cutover.

3. Stage and validate before booking

Do not write unvalidated conversion data straight into the production ledger. Oracle describes prerequisites, file upload, Stage 1 and Stage 2 processing, approval, verification, final data transfer and post-processing. The labels are vendor-specific, but the separation matters.

For every load, retain the file version, accepted and rejected counts, balance and accounting control totals, transformation errors, approved exceptions, operator and approval time. A batch can report success while the financial result is wrong.

4. Recalculate time-sensitive values

Interest, fees and accruals depend on dates, rules and prior events. Oracle says current-cycle interest and accruals can be recalculated through end-of-day processing, while running balances can be rebuilt from migrated events.

Choose which values are imported and which the target calculates. Then test both the opening position and the next event. Include backdated adjustments, matured deposits, delinquent loans, reversals and accounts that change status during the freeze.

5. Rehearse the operating day

A conversion can pass while the bank is unable to operate. Rehearsals should include payment and card posting, the general-ledger export, statements, fraud and AML feeds, digital banking balances, customer-service lookup, regulatory extracts, and end-of-day and start-of-day jobs.

Use production-shaped volume and the same ordered runbook intended for cutover. For an example of continuous posting requirements around a core, see FedNow participation: how banks and cores connect.

6. Reconcile twice

Oracle explicitly describes reconciliation before and after final data transfer.

Before transfer: prove that the approved source package agrees with the source system and signed scope.

After transfer: prove that the target received and booked the same economic position.

Compare counts and money by product, currency, status and ledger account. A grand total can hide account-level mistakes, so automate record comparisons for high-risk fields and retain the exception list.

7. Control cutover and rollback

Oracle recommends a weekend or long weekend and says transactions should not be processed during cutover. The runbook still needs exact rules for the last source transaction, channel freeze, queued incoming files, scheduled payments, urgent customer work and release order.

Name the go-live authority and the latest safe rollback point. A rollback is credible only if the team knows which transactions must be reversed or replayed on each side.

8. Require business sign-off

Technology can confirm jobs ran. Finance and operations must confirm the bank can use the result. Sign-off should cover balances, holds, limits, interest and fees, payment and card posting, general-ledger agreement, statements, customer servicing, exception queues and reports.