Bank core conversion: what it involves

What a core conversion is

A core conversion moves a bank's system of record from one core banking platform to another. Every customer record, account, balance, loan, transaction history and general ledger entry has to be mapped to the new system's structure, moved, and then proven correct before the bank starts running on it.

That last part is what makes it hard. Moving data is a solved problem. Proving that 40,000 accounts carry the same balances, the same accrued interest, the same maturity dates and the same year-to-date figures after the move, and that every downstream system still reconciles, is the actual work.

A conversion is also a people project. Staff have to learn new screens before customers meet them. Statements, notices and disclosures have to be reproduced correctly. Every connected system, from online banking to the card processor to the imaging archive, needs a working interface on day one.

How long a bank core conversion takes

Measured in months, not weeks. The honest answer is that it depends on the bank's size, its product set, how many systems connect to the core, and the condition of its data.

The sequence is what sets the pace. Data mapping has to finish before a mock conversion can run. A mock conversion has to be reconciled before testing means anything. User acceptance testing has to be signed off before a cutover date can be committed. None of those steps compress well, and skipping the reconciliation step is how banks end up discovering problems in production.

Worth separating from the conversion itself: the decision. Banks commonly start evaluating alternatives 18 to 24 months before their current contract expires, because selection, due diligence and contract negotiation all happen before any conversion work begins. A bank that starts looking six months out has usually already lost its negotiating position.

What a core conversion costs

Anyone quoting a single number without seeing the bank's contracts and data is guessing. What can be described honestly is what drives the cost:

• Volume and history: the number of accounts, and how many years of transaction history are carried forward rather than archived.
• Connected systems: every interface to digital banking, origination, cards, payments, imaging and reporting has to be rebuilt or re-pointed. Interface counts drive cost more than account counts at most community banks.
• Deconversion fees: what the outgoing provider charges to extract the bank's own data and end the relationship. These are set in the original contract, they are often substantial, and they are the single most commonly underestimated line item.
• Data condition: inconsistent customer records, legacy product codes and undocumented workarounds all add mapping effort.
• Staff time: testing and training are absorbed by people who still have their normal jobs. This cost is real and rarely budgeted.
• Parallel running: where it is used, the bank carries two systems for a period.

Read the deconversion and interface fee clauses in the existing contract before the evaluation, not after. They frequently change which option is actually cheaper.

The phases of a core banking system conversion

Names vary by provider. The sequence does not.

• Discovery and current-state assessment. What the bank runs today: the ledger, the integrations, the product set, the workarounds nobody documented.
• Target design and configuration. Products, parameters, accounting rules and user roles built in a reference environment.
• Integration and adapter planning. Every connected system inventoried, with an owner and a method for each interface.
• Data mapping and extraction. Field-by-field mapping from the old structure to the new, including the fields that do not have an equivalent.
• Mock conversion. A full rehearsal against production data, loaded into a test environment and reconciled against the source. Usually run more than once.
• Reconciliation. Balances, accruals, histories and general ledger totals proven to match. This is the step that decides whether a cutover date is real.
• User acceptance testing. Bank staff running their own scenarios on their own data, with defects tracked and re-tested.
• Training. Role-based, on a sandbox, before go-live rather than during it.
• Cutover, or a parallel run where applicable. The weekend everyone remembers, which should be uneventful if the preceding steps were done.
• Post go-live support. A defined hypercare period with stated exit criteria.

Where core conversions go wrong

The failures are consistent enough to list.

Data quality discovered late. Duplicate customer records and legacy product codes are survivable in year twelve on an old core. They become blocking problems during mapping. Finding them in the second mock conversion is expensive. Finding them after cutover is worse.

Interfaces treated as an afterthought. The core moves on schedule and the imaging archive does not connect. Interface work is where schedules slip, and it is usually the piece with the most third parties involved.

Testing signed off under schedule pressure. When UAT is compressed to protect a cutover date, the defects do not disappear. They move into production, where customers find them.

Nobody clearly accountable. When the platform vendor, an implementation partner and an internal project manager each own part of the outcome, the gaps between them are where problems live. A bank should be able to name one party accountable for the conversion result.

Staff trained too late. Training delivered the week before go-live produces a branch that cannot serve customers on Monday. The cost shows up as service quality, not as a line item.

Core conversion consultants, or the provider's own team?

Both have a place, and the distinction matters.

Independent consultants are genuinely useful for the parts where the bank's interests and the vendor's interests are not identical: selecting a provider, negotiating the contract, pricing the deconversion, and reviewing whether a proposed plan is credible. Bankers' banks and advisory firms do this work regularly, and a bank with no recent conversion experience is usually better off with help at that stage.

What a consultant does not do is the conversion. Data mapping, mock conversions, reconciliation and cutover are executed by whoever operates the platform. The question a bank should settle early, in writing, is which party owns each of those steps, and who makes the call on cutover readiness.

How Genesis approaches a conversion

Genesis runs conversions as a managed program with one bank-facing team accountable for the result. The team that scopes the work delivers it, and a named conversion lead stays accountable through go-live and the hypercare period that follows.

The sequence above is the sequence Genesis uses: discovery and current-state assessment, reference configuration, integration and adapter planning, migration planning, UAT scenario design, migration reconciliation, UAT sign-off, then controlled cutover or a parallel run where the bank's operating model calls for it.

For banks in the Design Partner Program, the bank's current core remains the system of record throughout discovery, configuration and testing. Production conversion is considered only after agreed UAT and migration reconciliation, not before.

Frequently asked questions

What is a bank core conversion?

Moving a bank's system of record from one core banking platform to another. Every customer, account, balance, loan, history record and general ledger entry has to be mapped, moved, tested and proven correct on the new system before the bank runs on it.

How long does a bank core conversion take?

Months rather than weeks, paced by data mapping, mock conversions, user acceptance testing and reconciliation, each signed off before the next begins. Separately, banks commonly start evaluating alternatives 18 to 24 months before the current contract expires, because selection and negotiation happen before conversion work starts.

How much does a core conversion cost?

There is no single figure. Cost is driven by account volume and years of history, the number of connected systems needing new interfaces, deconversion fees in the outgoing contract, staff time during testing and training, and any parallel running. Deconversion and interface fees are the items most often missed in early budgeting.

What is a mock conversion?

A full rehearsal. Production data is extracted, converted and loaded into a test environment exactly as it would be on cutover weekend, then reconciled against the source. Banks typically run several, because each surfaces mapping errors while there is still time to fix them.

What are deconversion fees?

Charges from the outgoing core provider for extracting the bank's data and ending the relationship. They are set in the original contract, they are frequently substantial, and they are a common reason a conversion costs more than first estimated. Read them before deciding, not after.

Do we need core conversion consultants?

It depends on who is accountable for the outcome. Independent consultants are valuable for vendor selection, contract negotiation and validating a provider's plan. They do not replace the team doing the conversion. Settle early which party owns data mapping, reconciliation and the cutover decision.

Keep reading

What is a core banking system? covers what the core does, how it differs from a core processor, and how to evaluate one. Genesis core conversion and implementation services describes how the work is staffed and sequenced. Why core modernization is hard for community banks is a longer perspective on the same problem.