A core banking migration, often called a core conversion, is the process of moving a bank’s accounts, balances, ledgers and transaction processing from one core system to another. Banks do it either in one event, with every account cut over at once, or in phases, with old and new cores running side by side. Both paths run through the same steps: exiting the old contract, mapping data, test conversions, cutover and post-conversion review.
What is being moved
A core is the bank’s system of record. The Federal Reserve’s proposed community bank guide describes it as the system that manages customer accounts, processes daily deposit and loan transactions, maintains the general ledger, generates regulatory reports and connects other applications. For the full definition, see what is core banking. This article covers only the move.
The Fed’s guide lists common reasons a bank converts: a more modern and reliable system, a platform the vendor is sunsetting, better pricing and contract terms, more control over its own data, and more responsive support. It also says plainly that “core conversions can be expensive and involve significant operational complexity.”
Four ways to migrate
| Approach | How it works | Where it is described |
|---|---|---|
| Full conversion (“big bang”) | All accounts and products move to the new core in one migration event | Thought Machine says this is “usually reserved solely for the smallest and simplest banks” |
| Phased or tranched migration | Accounts move in batches, by product, segment or account, with data loaded ahead and switched on later | Thought Machine (account-by-account cutover, dormancy flags); Mambu (product by product, geography by geography) |
| Coexistence, dual core or sidecar | New products launch on a new core while existing “back book” products stay on the old one | Thought Machine “coexistence” deployment; Mambu “dual core – on the edge” |
| Integration layer (“hollow out the core”) | A middleware or platform layer sits beside the legacy core and gradually takes over functions | Fed proposed guide (integration platform as an alternative to full conversion); Jack Henry Platform |
Each approach trades one risk for another. A single event keeps one system of record but concentrates risk in one weekend. Thought Machine’s 2023 migration white paper notes that parallel run and phased migration bring “coexistence complexities and costs around routing of requests and consolidation of cross-core reporting.”
The integration route is not free either. The Fed’s guide says adding an integration platform “extends the value chain and presents different inherent risks than a conversion.” Jack Henry’s fiscal 2026 10-K describes the Jack Henry Platform as a public cloud-native, API-first platform “which we are developing into a fully functional modern alternative for existing core functions.” Its current services include wires, general ledger and deposit servicing.
The steps of a core conversion
1. Decision and contract exit. The bank reviews what leaving will cost under its current contract. Jack Henry’s 10-K says clients who outsource core processing “typically sign contracts for six years that include ‘per account’ fees and minimum guaranteed payments.” The Fed’s guide lists potential early termination fees for the existing provider among the direct costs of conversion.
2. Vendor selection and due diligence. The Fed’s guide suggests weighing the new provider’s current and planned offerings, the ease and cost of integration with other systems, historical error and exception reports, and testimonials from other institutions. It notes many banks benefit from specialized conversion consultants or special counsel.
3. Data mapping and extraction. Legacy fields, product rules and account histories are mapped to the new core. Thought Machine’s July 2024 case write-up names data mapping, data quality, transformation, load and reconciliations as the parts of a migration its client’s approach simplified. It adds that often only one or a handful of people at a bank understand exactly how a legacy product works.
4. Test conversions. Banks run trial loads and compare results before going live. The FFIEC’s Development, Acquisition, and Maintenance booklet calls for system, integration and regression testing, and warns about using live customer data in test environments. Thought Machine describes “time-series testing,” which replays a known past period to show the new core behaves as the old one did.
5. Cutover. The Fed’s guide says banks “may benefit from closely controlling for and resolving any ledger reconciliation issues prior to going live following a core conversion.” It also says card or loan systems may need their own migrations and that phasing these “can aid the TCBO in managing risk.”
6. Post-conversion review. The FFIEC Audit booklet says the IT auditor should conduct a post-implementation review “shortly after” a conversion is accepted for production. That review covers program logic, calculations, error conditions, edits and controls.
What regulators expect
On September 11, 2026, the Federal Reserve, FDIC and OCC issued a joint statement on community banks’ engagement with core service providers (OCC Bulletin 2026-47). It calls core providers community banks’ “most material, complex, and highest-risk third-party relationships.” It says the agencies will weigh three factors when deciding how closely to supervise a core provider: transparency, contract features and technology. It also says certain core providers may qualify as “institution-affiliated parties” under the Federal Deposit Insurance Act, which would expose them to direct enforcement.
The same day, the FDIC, Fed, OCC and NCUA proposed new interagency third-party risk management guidance (FDIC FIL-58-2026), covered in our note on the third-party risk management guidance proposal. The Fed also proposed a companion guide for Federal Reserve-supervised “traditional community banking organizations,” banking organizations with less than $30 billion in assets that focus on serving their local communities. That guide has a dedicated “Core Conversion” section. Comments on both proposals are due November 16, 2026.
The FFIEC IT Examination Handbook covers the contract side. Its booklets say default and termination language should be negotiated in the initial contract, along with data return and an exit strategy.
| Contract point | What the regulator text says | Source |
|---|---|---|
| Deconversion fees | Agencies will consider “unsupported or contractually undefined core deconversion fees,” especially where the provider breached terms or missed SLAs | Joint statement, Sept. 11, 2026 |
| Back billing | “Extensive ‘back billing’ windows” for retroactive charges are listed as a concern | Joint statement; Fed proposed guide |
| Third-party integration | “Excessive limitations” on unaffiliated providers integrating with the core are listed | Joint statement |
| Termination rights | Consider rights for change in control, convenience, cost increases, repeated SLA failures, bankruptcy and insolvency | FFIEC Outsourcing Technology Services booklet |
| Data return | Contract should provide “timely return of the institution’s data and resources in a machine readable format” | FFIEC Outsourcing Technology Services booklet |
| Conversion assistance cost | “Any costs associated with conversion assistance should also be clearly stated” | FFIEC Outsourcing Technology Services booklet |
| Term and renewal | Weigh initial term length and automatic renewal conditions | Fed proposed guide |
| Contract buyout | Termination costs may include whether a new provider will buy out the remaining term | Proposed interagency TPRM guidance, footnote 18 |
| Exit plan | Develop an exit strategy during procurement; define time frames for transferring services | FFIEC Development, Acquisition, and Maintenance booklet |
The FFIEC Business Continuity Management booklet adds a warning about timing. If a provider stops operating, “the length of time required to convert to an alternate system would, for most applications, exceed a reasonable RTO,” meaning the recovery time objective.
The vendor side of deconversion
Deconversion fees show up in vendor filings. Jack Henry’s 10-K defines them as “amounts due from the early termination” of its cloud, processing and long-term support contracts. It says early termination “most commonly occurs due to the acquisition of one of our clients by another financial institution.”
Jack Henry reported $42.8 million of deconversion revenue for the fiscal year ended June 30, 2026, up from $33.9 million a year earlier. It excludes this revenue from its non-GAAP figures. The same release reported “a record 58 competitive core wins for the year, including 14 institutions with more than $1 billion in assets.” Each competitive win means a bank converting away from another provider’s core.
If you are a fintech on a converting sponsor bank
A sponsor bank’s core conversion touches every program that posts to it. The 2024 interagency statement on bank-fintech deposit arrangements warned that weak bank access to the system of record “can impair the bank’s ability to determine its deposit obligations.” For background on why ledger records matter, see synapse bankruptcy. Questions worth asking your bank:
- APIs and integration. Will your integration change? Does the bank connect through middleware or a banking-as-a-service platform that must be re-certified against the new core? Is there a test environment and a regression test window? See also api banking.
- FBO and sub-ledger reconciliation. How will the for-benefit-of (FBO) account and your end-user sub-ledger be reconciled across cutover? Who signs off that balances match before go-live?
- Posting times and cutoffs. Will ACH posting windows, wire cutoffs, end-of-day processing or real-time payment handling change?
- Account and routing data. Will account numbers, statement formats or file layouts change? What do end users need to be told, and when?
- Freeze windows and rollback. When do new accounts, product launches or config changes freeze? What is the rollback plan if reconciliation fails?
- Cards. If the card processor also moves, the Fed’s guide says a bank may consider coordinating with outgoing and incoming BIN sponsors to migrate cardholder data, test network access and reissue cards if needed.
These questions belong in the same diligence you would run when you look at how to choose a sponsor bank.
