Core Banking Conversion Readiness: What to Settle Before You Sign

Everything expensive about a core conversion is decided before anyone technical is deeply involved. Data migration scope, integration re-work, and what happens if you ever want to leave are all settled by contract language agreed during a sales process, and then discovered by an engineering team eighteen months later.

The conversion itself is a project. The contract is the architecture.

The vendors, and what each optimizes for

The credit union core market is concentrated. Fiserv operates several platforms, Jack Henry's Symitar has a long-standing credit union base, and Corelation's KeyStone has been taking share among institutions that want a more modern data model.

Rather than rehearse feature comparisons that vendors publish better than we can, the useful framing is what each relationship optimizes for:

Breadth of bundled services means fewer integrations to manage and more of your stack with one counterparty. That is genuine operational relief and genuine concentration risk. Both are real; the question is which you can better absorb.
Data model openness determines what you can build without asking permission. Institutions that intend to do serious analytics or in-house digital work should weight this far more heavily than the demo suggests.
Migration tooling maturity determines how much of the conversion is product versus services. This shows up directly in cost and in schedule risk.

Cornerstone Advisors' What's Going On in Banking 2026 reports that more than 80% of banks and credit unions plan to increase technology spending, alongside a persistent gap between planned system replacements and actual deployments. Our own reading of why that gap persists: spending tends to be vendor-led rather than strategy-led. A conversion is the single largest opportunity to correct that, or to entrench it for another decade.

Data migration is the real project

Conversion plans routinely treat migration as a workstream. It is closer to the whole thing.

History is where the cost lives. Migrating current balances is tractable. Migrating twenty years of transaction history, closed accounts, charge-offs, and the artifacts of two previous conversions is where schedules go. Decide explicitly how much history moves, how much goes to an archive, and who can query the archive when a member or an examiner asks.

Data that only exists in one place will be found late. Every institution has fields used for something other than their label, notes in free-text that carry operational meaning, and at least one process depending on a report nobody documented. These surface during parallel testing, which is the worst possible time.

Reconciliation between old and new is a deliverable, not a checkbox. You need to prove balances match, and you need to prove it in a way that satisfies an auditor. Budget for that as work.

The readiness question to answer before signing: can you produce a complete data dictionary for your current core? If the answer is no, that is not a reason to delay the conversion, but it is a reason to fund the discovery work before you commit to a date.

The integration inventory nobody has

Ask any institution how many systems touch the core. The answer given is usually between eight and fifteen. The real number is routinely two to three times that, because it includes the things nobody counts: a nightly file drop to an analytics tool, a spreadsheet a branch manager maintains from a report, a fraud vendor pulling via a service account created in 2019.

Building the real inventory before the RFP is the highest-value preparatory work available, and it takes weeks rather than months. For each item: what it connects to, how (API, file, direct database), who owns it, what breaks if it stops, and whether the new core supports the same pattern.

That inventory is also the honest basis for cost. A conversion quoted without it is quoted against a fiction.

Contract terms that decide your next decade

This is the part where an hour of attention is worth more than a month of implementation planning.

Term length and renewal mechanics. Five to seven years is normal. Auto-renewal with a short notice window is also normal and is where institutions lose leverage. Know the notice date. Put it in a calendar owned by a person, not a department.

De-conversion assistance and data extraction, priced now. The single most important clause in the agreement. If you ever leave, you need your data in a documented, usable format, and you need it at a price agreed while you still have negotiating leverage. A de-conversion fee left unspecified at signature is a fee set by someone who knows you have no alternative.

What is included versus billable. Custom reports, additional integrations, and training after go-live are commonly assumed to be included and commonly are not.

Service levels that mean something. Uptime figures are easy. What matters more is response commitment on a production incident during month-end, and whether it is contractual or aspirational.

Change of control. Core vendors acquire each other. What happens to your terms if yours is acquired is worth reading before it becomes relevant.

The readiness questions to answer before the RFP

If these have clear answers, the process will go reasonably. If they do not, the process will make the answers for you.

What business outcome is the conversion serving? "The current core is old" is not an outcome.
What does the integration inventory actually contain?
How much history moves, and where does the rest live?
Who internally owns this, full-time, for the duration? Not as an addition to their existing role.
What is the realistic staffing impact during parallel testing, and who covers normal operations?
What is the board's tolerance for a schedule slip, and has anyone said that number out loud?

When the honest answer is "not yet"

Sometimes the right call is to defer, and it is worth naming the conditions under which that is true.

Defer if you are inside twelve months of another major program that competes for the same people. Defer if you do not have a full-time internal owner and cannot create one. Defer if the primary driver is dissatisfaction with service rather than a capability gap, because a conversion is an extraordinarily expensive way to change account managers.

Do not defer because the current core still works. It will keep working right up until the point where the thing you need to do next is impossible, and by then the conversion is happening under pressure with a compressed timeline. Conversions run from strength go better than conversions run from necessity.

We provide senior engineering ownership through conversions, independent of any core vendor, so the advice serves the institution rather than the contract. See technology leadership for community banks and for credit unions, or book a call.