Talk to a practitioner

Core conversion

Core conversions typicallyrun in six workstreams.

When a bank or credit union changes its core, the technology conversion usually gets the most attention. In our experience, conversion leadership, servicing and operations, product, customer readiness, and risk and compliance are just as critical to its success.

Talk to a practitionerThe commercial treasury conversion guide
  1. 01Technology conversion
  2. 02Conversion leadership
  3. 03Servicing & operations
  4. 04Business & product
  5. 05Customer readiness
  6. 06Risk & compliance

What's involved

Most of a core conversion is the bank's work.

Moving to a new core from your current provider runs differently from moving to another provider. In both, the providers help map the data and run the extract and the load. Everything else is the bank's to plan, staff, and execute.

01

Technology conversion

The stages that move the bank's records and the systems around them, from architecture to stabilization.

Who owns it
Your technology leaders and your core provider, with every surrounding vendor.

Key projects

  • Architecture & integration inventoryEvery system, interface, file and batch job that touches the core, and its future.
  • Data conversionExtraction, cleansing, mapping and transformation, with history, images and documents.
  • Surrounding systemsDigital banking, cards, payments, lending, CRM, the data warehouse, fraud and AML: re-pointed, rebuilt or converted.
  • TestingSystem, integration, end-to-end and user acceptance testing, through the scenarios your business runs.
  • Mock conversions & reconciliationTimed rehearsals of the full conversion, each balanced and signed.
  • Cutover & stabilizationThe weekend runbook, the go/no-go, and hypercare through the first statements and the first close.
We lead

We own the eight stages below end to end, with your teams and your provider.

Talk with us about this workstream
02

Conversion leadership

Led by people who have run core conversions before, with one plan, one calendar and one decision log for your teams and vendors, from the signed agreement to decommission.

Who owns it
Your executive sponsor and steering committee, and a program office.

Key projects

  • OversightSponsor, steering committee, decision rights and reporting cadence.
  • Integrated technical program planEvery workstream and vendor on one plan, with the technical dependencies between systems, vendors and teams mapped and aligned.
  • Vendor coordinationThe new provider, your current provider's deconversion team and the surrounding vendors, working to the same dates.
  • Risks, issues & decisionsOne register, with owners and dates, reviewed weekly.
  • Budget & capacityThe program's cost, and backfill for the people it pulls out of their day jobs.
  • Go/no-go frameworkThe criteria, evidence and signatures, agreed months before they are needed.
We lead

We run the program office and the integrated technical program plan with your sponsor, and hold the vendors to one calendar.

Talk with us about this workstream
03

Servicing & operations

Procedures, training and staffing so branches, servicing teams, back office and contact center can run the new core on the first business day.

Who owns it
Your operations, servicing, branch, contact center and HR leaders.

Key projects

  • Process & procedure redesignToday's servicing and operations workflows rewritten for the new core, with job aids for each role.
  • TrainingRole-based training in a training environment, held close to go-live.
  • Conversion weekend rosterWho is in the command center, the branches and the back office, hour by hour.
  • Branch & contact center readinessScripts, staffing and extended hours for the first weeks, when questions peak.
  • Change managementLeaders who explain the reasons, and a way to hear what isn't working.
  • Floor support after go-liveA fast path from a teller's question to someone who can fix it.
We work alongside you

We build the readiness plan and the weekend roster from the runbook, so the people trained are the people on shift.

Talk with us about this workstream
04

Business & product

Deposit and loan products, rates, fees and statements rebuilt in the new core's terms, and a decision on which products to keep.

Who owns it
Your product owners, finance, and line-of-business leaders.

Key projects

  • Product mapping & rationalizationEach product mapped to the new core's parameters. A conversion is the cheapest time to retire products nobody sells.
  • Pricing, rates & feesRate tables, fee schedules, service charges and waivers, tested to the penny against today's results.
  • Statements & noticesStatement and notice designs, inserts, and the timing of the first cycle.
  • General ledger & financeChart-of-accounts mapping, balancing to the GL, accrual cutoffs, and a date away from quarter-end.
  • ReportingThe management, regulatory and tax reports the old core produced, rebuilt or replaced.
  • Business rules & exceptionsHolds, overdrafts, dormancy, escheat, and the exceptions your staff handle from memory today.
We work alongside you

We turn product and pricing decisions into mapping and parameter specifications, and test them against today's results.

Talk with us about this workstream
05

Customer readiness

What customers see, receive and need to do, in the order they need it and within the notice periods regulation requires.

Who owns it
Your marketing, compliance and customer experience teams.

Key projects

  • Notice planChange-in-terms and disclosure notices, timed to their legal lead times and to your own commitments.
  • Customer letters & welcome kitsWhat changes, what doesn't, and what the customer has to do, segment by segment.
  • Digital banking transitionRe-enrollment or credential changes, bill pay and transfers, and the outage window.
  • Cards, checks & account numbersReissues, new checks or new numbers if anything changes, and the direct deposit updates that follow.
  • Scripts & FAQsOne set of answers across branches, phones, chat and the website.
  • Personal outreachThe business and high-value clients who should hear it from a person, not a letter.
You own it, we feed it

We give your communications team the dates, changes and customer impact from the technical plan, and keep them current.

Talk with us about this workstream
06

Risk & compliance

The controls and evidence that examiners, auditors and your risk teams need to see the conversion was done right.

Who owns it
Your risk, compliance, BSA, information security and internal audit leaders.

Key projects

  • Regulator engagementEarly word to your examiners, and a plan you can walk them through.
  • Third-party risk managementDue diligence and oversight of the new provider, and an orderly exit from the old one.
  • BSA/AML & fraud continuityMonitoring, screening and fraud detection fed by the new core from day one, tuned to its data.
  • Information security & accessUser access rebuilt on least privilege, and a security review of every new connection.
  • Business continuityRecovery plans for the new platform, tested before you depend on it.
  • Audit & controls evidenceInternal audit involved early, with balancing sign-offs and test evidence it can rely on.
You own it, we feed it

We produce the evidence: test results, reconciliations, sign-offs and access reviews, organized the way examiners and auditors read them.

Talk with us about this workstream

The calendar

The steps from signed agreement to decommission.

Most programs are planned back from a conversion weekend. We'd rather plan forward based on the work, but either way, the order of the steps doesn't change.

  1. 01MobilizeGovernance, the integrated technical program plan, and notice to your current provider. Milestone: provider notice given.
  2. 02DesignArchitecture, product and data mapping, and interfaces. Milestone: mapping signed.
  3. 03BuildParameters, integrations, reports and environments. Milestone: build complete.
  4. 04TestSystem, integration, end-to-end and user acceptance testing. Milestone: UAT sign-off.
  5. 05Mock conversionsFull rehearsals, each balanced and signed. A small conversion with a clean mock 2 can stop there; a large one runs a final mock and then a dress rehearsal on the conversion weekend's timing, with no code changes between them.
  6. 06ReadinessCustomer notices, training, rosters and the go/no-go. Milestone: notices sent and staff trained.
  7. 07Cut overThe weekend, from the final go/no-go to Monday. Milestone: conversion weekend.
  8. 08StabilizeHypercare through the first statements and the first quarter-end. Milestone: first quarter-end closed.
  9. 09DecommissionArchive, read-only access, then the legacy core decommissioned. Milestone: legacy core decommissioned.
The date comes first

Conversion weekend is often set before the plan exists.

Your provider's conversion calendar and your current provider's deconversion notice terms can fix it in the first weeks.

Notice periods

Customer notices run on legal lead times.

Notice periods can't be shortened when the plan slips late, and a missed mailing date can move the weekend.

Choosing the weekend

Stay clear of quarter-end and your peak seasons.

Month-end and quarter-end close, tax season and your own busy periods make balancing harder and staff scarcer. A holiday weekend gives you an extra day.

How Ignite supports you

How we work on a core conversion.

Our practitioners have run core conversions inside banks and alongside the providers. We work between your teams and your vendors from the first plan to decommission.

01

Before you mobilize

A practitioner's review of your plan, your provider's conversion schedule, your team and the decisions ahead, while changing course is still cheap.

02

Lead the technology conversion

The eight stages, architecture through stabilization, owned end to end with your teams and your provider.

03

Deliver the technology platform

Data conversion and reconciliation, the integration build, or command of the conversion weekend, delivered by one accountable team alongside yours.

04

Recover a conversion that's slipping

A quick assessment of where it is stuck, then the people to fix it, without restarting the program.

What stays yours

Your decisions, your customers, your people, and your relationship with your provider.

What we take

The integrated plan, the data, the build, the rehearsals, the weekend, and the evidence that it all balanced.

See programs like yours

The technology conversion

The technology conversion runs in eight stages.

01Architecture

Map every system that touches the core before anything is built.

A core sits among dozens of systems, files and batch jobs, many of them undocumented. This stage finds each one, decides its future, and draws the target state from the systems you run.

  • Inventory of every interface, file, API and batch job
  • Target-state architecture: real-time and batch integration
  • Systems that stay, convert, re-point or retire
  • Hosting, network and connectivity to the new provider
  • Identity, access and entitlements
  • Data flows to the warehouse, reporting and downstream systems

Done when

Every interface has an owner, a target and a test, and your architects and the provider's have signed the target state.

Where it slips

The target state is drawn from the vendor's diagram instead of the systems you run, and the gaps surface in the build.

What we own

The current and target state, the integration landscape and the systems that stay, settled before the build.

02Strategy

Decide the conversion approach, including how you would roll back.

The approach sets the calendar, risk and cost: what converts and when, how much history comes across, how many rehearsals you run, and when you would stop.

  • All at once, or phased by product, region or charter
  • The conversion weekend and the blackout calendar
  • History depth: transactions, statements, images and notes
  • The mock conversion plan, with entry and exit criteria
  • Sequencing with digital conversions, commercial treasury among them, and merger events
  • Rollback criteria and the point of no return

Done when

The approach, dates and rollback criteria are written down and approved by the steering committee.

Where it slips

The approach is inherited from the provider's standard plan, and rollback is first discussed on the weekend itself.

What we own

The conversion strategy: what moves, in what order, how each rehearsal proves itself, and how you would roll back.

03Data

Profile and clean the data, then map it to the new core.

Every customer, account, balance, rate, hold, stop, relationship and note is extracted, profiled, cleansed, mapped and transformed into the new core's structures. Years of data quality problems surface here.

  • Extraction, and the deconversion files from your current provider
  • Profiling and quality: addresses, tax IDs, dormant and closed accounts
  • Field-level mapping and code translation tables
  • Transformation rules and account number crosswalks
  • History, statements, images and documents
  • Cleanup owned by the business and tracked to closure

Done when

Every field is mapped and signed, every translation table is complete, and the data quality backlog is closed or accepted in writing.

Where it slips

Data quality is treated as a minor detail, and found late to be critical to the program.

What we own

Data strategy, ETL and transformation logic, enrichment, validation and remediation, documented and reviewed, with every change tracked.

How we use AI in data mapping without exposing customer data

04Build

Rebuild the core's connections, and build what the new platform lacks.

The provider configures the core with your parameters. The surrounding systems, files and reports are rebuilt or re-pointed, and anything the new platform doesn't cover is built.

  • Product and parameter build with the provider
  • Interfaces to digital banking, cards, payments, lending, CRM, fraud and AML
  • Payment rails: ACH, wires, real-time payments, card authorizations
  • Middleware, APIs and the integration layer
  • Reports, extracts and the nightly batch schedule
  • Environments for development, testing, conversion and training

Done when

Every interface passes end-to-end tests with real business scenarios, and every gap has a build or an accepted workaround.

Where it slips

The integration team learns what the existing systems do in the last month before go-live.

What we own

Integration build and testing beside your engineers and your provider, including the software no vendor sells.

05Convert

Rehearse the full conversion until it runs clean and on time.

A mock runs the full conversion in a test environment: extract, transform, load and balance. A large conversion with a tight window typically needs three mocks and a dress rehearsal; if mock 2 is fully clean and fits inside the window, which usually happens only on small conversions, you can stop there. Nothing in the code changes between the final mock and the dress rehearsal.

  1. Mock 1The programs run end to end, and the data lands.
  2. Mock 2The data balances, and the business can find its accounts.
  3. Mock 3The final mock confirms every migration code change landed, inside the weekend's window.
  4. Dress rehearsalThe final execution of the conversion on production-like data, run on the weekend's timing by the weekend team.

Done when

The final mock balances cleanly inside the weekend's time window, with every defect closed or accepted.

Where it slips

Mocks test the provider's programs instead of rehearsing your weekend, so timing is first measured live.

What we own

The mock plan and its runs, transformation and load, with defects tracked until the final mock runs clean.

06Reconcile

Prove each dollar and account at five levels.

Balancing starts with record counts and ends with your staff checking customers they know. It runs at every mock and again on the weekend.

  1. 01Record countsCustomers, accounts and relationships: what went in, what came out.
  2. 02Control totalsBalances, accrued interest and holds, product by product.
  3. 03General ledgerEvery product tied to the GL, to the penny.
  4. 04Account levelRates, dates, fees, stops, escrow and payoffs, account by account.
  5. 05Business validationYour staff checking accounts they know, and a parallel run of interest, fees and statements.

Done when

Every level balances or every difference is explained, and finance, operations and audit have signed.

Where it slips

Validation is left to the vendor's record counts, and the first full reconciliation is on the Monday after go-live.

What we own

Each mock and the weekend proven complete and correct against the source, with the sign-offs.

How we accelerate reconciliation

07Cut over

Run the weekend from an hour-by-hour runbook.

The runbook sets owners, dependencies and checkpoints, and the weekend is run from a command center. Payments in flight settle, final files are cut, the data converts and balances, and the bank opens on the new core.

  • An hour-by-hour runbook with owners and checkpoints
  • The freeze calendar: code, parameters and product changes
  • Final files, payment cutoffs and items in flight
  • Go/no-go gates inside the weekend
  • The command center, escalation and communications
  • Day-one readiness: branches, digital, cards and payments live

Done when

Every checkpoint passes, the first business day's balancing ties, and the bank opens on time.

Where it slips

The cutover was never rehearsed, and the rollback decision is made for the first time under pressure.

What we own

Cutover planning and command, with the rollback gate agreed before the weekend.

08Stabilize

Stay through the first statements, month-end close and quarter-end.

Problems show up with the first statement cycle, month-end, interest posting and regulatory report. Hypercare lasts until each has run clean.

  • A war room, daily triage and defect burn-down
  • Daily balancing until it's routine
  • First statements, month-end close and quarter-end reporting
  • Call volume, adoption and workarounds, tracked
  • The legacy archive, read-only access and decommissioning
  • Handover to the teams who will run it

Done when

The first quarter-end closes clean, defects are back to normal levels, and the legacy system is archived and decommissioned.

Where it slips

Go-live is declared, adoption is never measured, and staff work around the new system.

What we own

Defects burned down, adoption measured, and the operating model that makes the investment pay.

Your decisions

Ten decisions only the institution can make, best made early.

Your provider and partners can recommend, but each of these moves the calendar if it's made late.

  1. 01

    The conversion date, and the weekend it lands on.

    Mobilize
  2. 02

    All at once, or phased: one weekend for every product, branch and customer, or waves by product, region or charter, each with its own mocks and its own weekend.

    Mobilize
  3. 03

    Who decides: the sponsor, the steering committee and their decision rights.

    Mobilize
  4. 04

    How the core and digital conversions are sequenced, commercial treasury above all.

    Mobilize
  5. 05

    Which products survive the move.

    Design
  6. 06

    Whether account numbers change.

    Design
  7. 07

    How much history converts, and where the rest is kept.

    Design
  8. 08

    Which surrounding systems convert, re-point or retire.

    Design
  9. 09

    What "balanced" means, and who signs it.

    Test
  10. 10

    The go/no-go criteria, and who can say no.

    Readiness

Core and commercial treasury together

If commercial treasury converts in the same program, decide the order early.

Your treasury platform reads balances, posts transactions and ties every client entitlement to core accounts, so converting the two on different dates means building that integration twice.

Option A

Core first, treasury after

CORETREASURY
Fits when
Your current treasury platform can connect to the new core, and the treasury team needs a settled core first.
The catch
Integration work for a platform you are about to retire, and commercial clients live through two changes.
Option B

Treasury first, then core

CORETREASURY
Fits when
Your commercial clients need the new treasury platform sooner, or the core date is a long way out.
The catch
The new treasury platform is integrated to the old core, then again to the new one, and it has to be in every core mock.
Option C

The same weekend

CORETREASURY
Fits when
A merger or a provider exit forces one date, or your clients can absorb only one change.
The catch
All the risk on one weekend, no treasury waves, and a rollback that takes both with it.

ConversionIntegrated a second time

It depends on whether your current treasury platform can connect to the new core, how many clients send files from their own systems, whether account numbers change, and how much your teams can carry at once.

We help you make this decision in the first weeks, because it sets the calendar.

Read the commercial treasury conversion guide

Questions

What executives ask before a core conversion.

How long does a core conversion take?

It depends more on decisions than on size: how early the date, the approach and the mapping are settled, whether you stay with your provider or move to another, and how many mocks it takes to balance. Many programs run a year or more; with those decisions made early, it can be done faster.

How many mock conversions do we need?

Three plus a timed dress rehearsal is typical for a large conversion with a tight window. A small conversion whose mock 2 is fully clean and fits inside the window may need neither mock 3 nor a dress rehearsal.

Will our customers' account numbers change?

Usually not, and keeping them is worth considerable effort. Mergers and number collisions can force changes, and every change brings notices, new checks, card reissues and direct deposit updates. Decide early.

Do we need to run both cores in parallel?

A full parallel run is rare and expensive. Most conversions rely on mock conversions plus a parallel of interest, fees and statements on converted data, which catches the calculation differences that matter.

Should we convert on a holiday weekend?

Many institutions do, for the extra day. Weigh it against staff availability, and keep clear of month-end, quarter-end and your peak seasons.

What does our provider do, and what's left to us?

The providers help map the data, run the extract and the load, build your parameters from your decisions, and run their side of the weekend. A move between cores from the same provider runs differently from a move to another provider. The mapping decisions, data quality, surrounding systems, testing, balancing sign-off, training, customer communications and the go/no-go are yours. That gap is where most conversions slip, and where we work.

Spend 30 minutes with us

Talk with us about your core conversion.

No pitch, no obligation. And if we're not the right team for it, we'll tell you that too.

Talk to a practitionerThe commercial treasury conversion guide
Commercial treasury conversionMoving commercial clients, entitlements and payments to a new platform.Conversions Conversion reconciliationProving a conversion, with AI-accelerated data mapping.Conversions Bill pay conversionPayees, recurring payments and the cutover weekend.Conversions

Spend 30 minutes with usThe program register

Bring your roadmap.Partner with us.Let's connect.Send me the program register.

We'd love to hear what you're working on. No pitch, no obligation, and if we're not the right team for it, we'll tell you that too.The programs we have finished, by line of work and institution segment, and the stages each one ran through. We email it to you.

Enter your work email.