A core banking migration moves balances, contracts, installments, limits and history from one platform to another while the institution keeps operating. The safest programs split the base into waves, run the same migration engine for each one and reconcile every account before the next wave starts.
In practice, a migration is judged by one moment: the morning after cutover, when customers open their app and either see the right balance or don't. Most of what decides that moment happens months earlier, in choices that rarely make the vendor shortlist conversation: how the customer base is split, what moves first, and how the team proves that every account arrived with the right value.
Those choices are getting more attention because more institutions are facing them. In the American Bankers Association's Core Platforms Survey, 19% of banks said they were likely to switch core providers at their next renewal (ABA). Fintechs and card issuers are moving too, often from first-generation processors to cloud-native platforms such as Pismo, now part of Visa (Visa).
Some core contracts run as long as 15 years, according to The Financial Brand. That means the people who ran the last conversion have often moved on by the time the next one starts.
The track record explains the caution. In a McKinsey review of core conversions tied to bank mergers, integration and modernization efforts overran their initial cost estimates by 50 to 100 percent (McKinsey). If you are still weighing the architecture choices behind a new core, our guide to core banking modernization covers them in depth. This article covers the execution side, based on the migration programs NTConsult has run for banks and card issuers, including moves to Pismo.
What does a core banking migration actually move?
The core is the system of record, so the migration carries far more than customer accounts:
- Accounts and balances, including holds, blocks and account status.
- Contracts and their schedules: installments, rates, delinquency status and payoff amounts.
- Product configuration: fees, limits, billing cycles and interest rules, which often have to be rebuilt on the destination rather than copied.
- History needed for statements, disputes and regulatory reporting.
- Connections to satellite systems such as collections, payments, card processing, lending, accounting and regulatory reporting.
Satellites are where scope tends to grow. A collections engine or a limits system that reads directly from the legacy core has to be repointed, retested and sometimes replaced. One way to shrink the problem, suggested by The Financial Brand, is to move some third-party products, such as bill pay or card issuing, before the core conversion itself, so fewer things change in the same window.
What are the main core banking migration strategies?
There are four common ways to move a customer base from one core to another. The right one depends on the size of the base, the number of products and how many surrounding systems cannot be switched off at once.
| Approach | How it works | When it fits | What to watch |
| Big bang | The whole base moves in a single cutover window | Small bases, few products, a short regulatory window | No way back: any failure hits every customer at the same time |
| Phased, in waves | Groups of accounts move in successive windows, by product, segment or another criterion | Large, multi-product bases that cannot stop operating | Requires a repeatable migration engine and reconciliation after every wave |
| Extended coexistence | Both platforms run together for months, with routing rules deciding where each account lives | Dependencies that cannot be turned off in one go | Double running cost and more complex integration |
| Mandatory plus voluntary | Required waves combined with customers opting into a new product | Migrations that come with a portfolio repositioning | A residual base that can take a long time to empty |
Phased migration is the most common choice for large, complex institutions today, according to 10x Banking. Oliver Wyman reaches the same conclusion: coexistence "is now preferred due to numerous high-profile failures of the conventional 'big bang' strategy" (Oliver Wyman). Platform vendors have moved the same way. Leonardo Collado, who leads Pismo at Visa, told PYMNTS that Pismo favors modernizing service by service over big bang replacements, because of the operational risk they carry (PYMNTS).
Visa's Pismo team splits phased migration into three variants (Visa Issuing Solutions). In a greenfield build, new products launch on a modern stack and the existing business moves later. A side core runs alongside the legacy system, so new products can ship while the old core keeps operating. A thin ledger is a lightweight ledger placed beside the legacy core that takes over accounts gradually. Those patterns decide where new business lands. The wave plan decides how existing accounts get there, and most programs need both decisions. Each variant also accepts a period of coexistence in exchange for lower cutover risk, so the coexistence rules covered below apply to all of them.
Picking a path is the first decision of the program, and it should come out of a mapping exercise. Defaulting to whatever the last project did is how institutions end up running two cores longer than they budgeted for.
What should be decided before anything is built?
A readiness assessment answers three questions: what migrates, in what order and at what risk. We usually scope it at 8 to 12 weeks, with a small team (a project manager, a data architect, a specialist in the destination platform and a business analyst). It produces:
- A business deep dive with process owners: products, billing rules, limits and cycles.
- A technical deep dive of the source platform: integrations with surrounding banking systems, satellite systems and historical databases. Our full guide to banking systems integration shows how to map them in detail.
- Field-by-field data mapping from source to the entities the destination platform expects.
- A gap analysis separating what is native in the destination from what has to be built or adapted.
- A wave strategy, a roadmap and an effort and investment estimate.
The gap analysis matters more than it looks. McKinsey found that successful migrations adopted at least 80 percent of the new core's out-of-the-box functionality. Every gap closed by customization becomes something to build, test and reconcile in every wave.
Two items from Visa's migration readiness checklist belong in this phase as well. The first is a data audit, with automated cleansing and regression tests, so bad records are fixed at the source instead of being migrated. The second is confirming that the destination meets the security and compliance standards the institution answers to, such as PCI DSS and ISO 27001.
This is also where the less obvious risks surface. In a migration we supported at a Brazilian digital bank, 1.6 million accounts and 1.6 million personal and payroll loan contracts moved to a new core over about 12 months. The old and new architectures ran in parallel until the legacy platform stopped creating accounts and contracts. The hardest problems had little to do with the new core:
- Hybrid customers. For a while, some customers had their account on one platform and their loan on the other, and downstream systems were not built for that. Hybrid states need to be mapped in the coexistence rules before the first wave.
- Satellites that were not ready. Collections, recovery and some products were not yet prepared for the new platform. A readiness check per satellite, tied to the wave that depends on it, keeps a wave from moving customers to a platform their servicing cannot reach.
- A source that kept growing. New accounts and contracts had to be routed to the destination while the migration ran. Otherwise the legacy base keeps filling up behind the waves.
None of these show up in a platform demo, and any of them can stop a wave.
How do you plan waves the operation can absorb?
A typical sequence runs from a full rehearsal in a non-production environment, to a pilot with a controlled base in production, to wave one, then waves two through N, a residual base and finally the shutdown of the source platform.
Waves are usually formed by card brand, BIN or product; by product and modality; or by customer segment and risk profile. The volume each window can handle, integration dependencies and billing or network calendars set the limits. Each window has a volume cap, an entry criterion and an exit criterion, and nothing advances until the previous wave is reconciled. That rule slows the calendar slightly, but it removes the most expensive failure: finding a mapping error after it has been copied into three waves.
The master plan has to cover more than dates. It needs coexistence rules (how routing, customer service and collections follow each account while two platforms run), the critical paths that can stop a wave, observability by wave and by record, and a defined rollback procedure with the criteria for using it.
Customers should hear about the change before it reaches them. Leonardo Collado, SVP and General Manager of Pismo, recommends "communicating the changes clearly and early while also providing an avenue for people to share feedback." In a wave plan, that means tying customer notices to the wave calendar, so each group hears from the institution before its own window, and making sure customer service knows which platform every account is on that day.
Why does the migration engine need to be repeatable?
When a base moves in ten or twenty waves, extraction and transformation stop being a one-off script and become a production process. The engine we build follows a fixed path: extraction by batch and by wave, a raw layer that preserves source data untouched, a canonical model that gives every record one representation (we cover this principle in depth in our article on financial data integration), transformation and validation rules, and delivery to the destination by file or API.
The raw layer is easy to skip and expensive to miss. When a reconciliation flags a difference weeks later, the team can go back to exactly what the source sent instead of extracting again from a system that has kept changing. The canonical model pays off when there is more than one source: each source needs only one mapping into the model, and the rules downstream stay the same.
Every account and contract carries its identity, version, status and evidence through each step. That record-level trail lets the team spot a problem in a wave before customers do, and it gives auditors something concrete to review.
In a card-processing migration for a large Brazilian retail issuer, more than 5 million accounts are moving from two source processors to Pismo, with separate migration scenarios by card brand and product. The engine receives batches from each source, validates what arrived, applies the data mapping and sends the result to Pismo, following each return. Two sources feeding one destination is exactly the case where an ad hoc approach breaks down.
How do you prove the migration worked?
Reconciliation is where many programs underinvest, and it is what regulators, card networks and the institution's own finance team will ask about. We run three reconciliations in every wave:
- Source vs. engine. Was everything that left the source read, understood and classified? Counts, keys and integrity.
- Engine vs. destination. Was everything sent accepted by the destination in the expected state? Returns, events and rejections.
- Source vs. destination. Do balances, statements, installments and outstanding debt match, account by account? Values, dates and status.
Coexistence makes this harder: when products move at different times, customer data may need to live in several systems at once, which demands continuous syncing, reconciliation and strong change control.
To keep reconciliation from becoming a manual bottleneck, NTConsult built an AI-assisted reconciliation engine. Business teams write reconciliation rules in natural language, so there is no code to maintain. The AI applies each rule and records the rule, the evidence and a confidence score for every decision. Cases below the confidence threshold go to an analyst with the context already assembled. Analysts stop checking every record and spend their time on the exceptions, which arrive with the evidence already gathered.
What changes when the destination is Pismo?
Pismo is a cloud-native platform for core banking and card-issuer processing, covering cards, deposit accounts, lending and corporate banking. For an in-depth look at its architecture, read our full article, Pismo: Cloud-Native Core Banking and Issuer Processing. Its design favors gradual moves. Pismo's migration toolkit connects to the existing core or card management system through APIs and also accepts file uploads for large volumes. For cards, an authorization redirector forwards transactions to the legacy system while cards are still there and is switched off once all cards in a BIN have moved. Institutions that receive authorizations directly from the networks can migrate by BIN in batches, while fintechs using a BIN sponsor usually move all cards in a BIN at once (Pismo).
These capabilities make waves possible on the destination side. They do not decide what goes into each wave, how source data is cleaned and mapped, how satellite systems are prepared, or how each wave is proven correct. The card migration described above taught us three lessons that apply to most cloud-native destinations:
- Map to the destination's entities, not to the source's tables. A modern core expects its own data model, so mapping is done field by field into the entities the platform defines.
- Two sources need two mappings and one model. Consolidating processors is where the canonical model earns its cost.
- Reconciliation includes the card network. For card portfolios, the destination processor and the network both have to agree with the source.
API delivery makes smaller and more frequent waves practical. It does not reduce reconciliation work, which grows with the number of products and scenarios.
How long does a core banking migration take?
Durations depend on the size of the base, the number of products, and how many satellite systems have to change. For a large, multi-product institution, a typical plan looks like this:
| Stage | Typical duration |
| Readiness assessment | 8 to 12 weeks |
| Engine build and rehearsals | 4 to 6 months |
| Migration waves | 9 to 12 months |
| Reconciliation | During the waves and up to 2 months after the source is shut down |
| End to end, from assessment to shutdown of the source | 18 to 24 months |
Engine work and reconciliation overlap from the pilot wave onward, and smaller bases with simpler product sets move faster. For US banks and credit unions, the calendar often starts with the current core contract.
The Financial Brand advises institutions facing a core retirement to “negotiate wisely, plan deliberately, and take control of their own timelines before someone else does.” Knowing when the current platform will be retired also shows how much of those 18 to 24 months is actually available.
The platform will be different in every project. What repeats is the order of decisions: decide before building, and prove before switching anything off.
How NTConsult can help
NTConsult runs core banking and card-processor migrations for banks and issuers, from the first assessment to the shutdown of the source platform. The cases in this article, a core conversion of 1.6 million accounts and 1.6 million loan contracts and a move of 5.4 million card accounts to Pismo, follow the same method, NT MOVE. Each of its stages (assessment, wave planning, migration engine and reconciliation) can be contracted on its own. Our teams pair specialists in the source platform with specialists in the destination, and reconciliation runs on an AI-assisted engine we built and maintain.
If you are planning a core or processor migration, a readiness assessment gives you the data map, the gap matrix, the wave strategy and a cost estimate in 8 to 12 weeks, before you commit to a cutover plan. Talk to our platform migration team.
FAQ
What is core banking migration?
It is the process of moving accounts, contracts, balances, product rules and history from one core banking platform to another while the institution keeps operating. It also includes repointing the systems that depend on the core, such as payments, cards, collections and regulatory reporting.
Is core banking migration the same as a core conversion?
Mostly, yes. US banks and credit unions usually say core conversion when they move from one core processor to another. Core banking migration is also used for moves to a new architecture, such as a cloud-native core, where data models and integrations change more deeply.
What is the safest core banking migration strategy?
For large bases with several products, a wave-based migration is usually the safest. Accounts move in groups, each wave has entry and exit criteria, and no wave starts until the previous one is reconciled. Big bang can work for small, simple bases.
How do you reconcile data after a core migration?
By comparing three pairs in every wave: what left the source against what the migration engine processed, what the engine sent against what the destination accepted, and the source against the destination, account by account, for balances, installments, dates and status.
How long does a core banking migration take?
It depends on the size of the base, the number of products and the integrations involved. For a large, multi-product institution, a full program, from the first assessment to the shutdown of the source, can take 18 to 24 months, with the migration waves taking most of that time.
Sources
- American Bankers Association, Core Platforms Survey
- McKinsey & Company, Core banking migration during M&A: Seven keys to success
- Oliver Wyman, 5 key considerations to transform core banking systems
- The Financial Brand, Your Core Is Being Retired. Now What?
- Visa, Visa Completes Acquisition of Pismo
- Visa Issuing Solutions, Core Banking Modernization and Migration
- Visa, Transform with Visa and Pismo: Next-gen processing and core banking
- PYMNTS, Visa's Pismo Says AI Has Exposed Banking's Old Tech Problem
- 10x Banking, Core banking migration strategies
- Pismo, How Pismo helps banks migrate to cloud-based computer systems
- Pismo, Pismo continues migration success as more than 1.5 million accounts go live
