Transformation

How to bring in a new core system while the old one keeps running

The new core promises to change how the business works. Bringing it in without stopping the old one is the design problem that matters.

By Zakir Hoosen, Director, Fuzzelogic Solutions. Plain English guidance for business leaders.

A new core system means a new platform that becomes the system of record for the work the business actually does. In banking, that is a new ledger. In insurance, that is a new policy administration system. In manufacturing, that is a new ERP. In every case, the problem is the same: the old core cannot stop. The new core has to start.

This is the hardest transformation pattern. The old system is live. The new system is untested. The business cannot pause between them. The design has to be good enough that a CIO, an enterprise architect, and a risk committee can read it and challenge it.

"Ninety percent of companies have launched some flavor of digital transformation, and only a third of the expected revenue benefits, on average, have been realized."

Source: McKinsey, Rewired to Outcompete

Core system replacements fail more often than other transformations because they concentrate all risk into one programme. The old system is the business. The new system is the future. The cutover is the moment of maximum exposure.

Fuzzelogic Solutions has been modernising banking, insurance, healthcare, retail, manufacturing, and government platforms since 2007. Nine regulated financial institutions sit among our clients. Platforms run on three continents. This article is the playbook we use to talk about the work, not a claim that every programme looks the same.

Why new cores are different from other upgrades

A version upgrade changes the software. A database upgrade changes the engine. A new core changes the business. That is the difference, and it changes everything about the programme.

The old core is not just software. It is the accumulated process, the tribal knowledge, the workarounds that became official process, and the data that everyone trusts because it has been there for years. Replacing the core means replacing all of that, and doing it while the business keeps trading.

The old core is the business. You cannot shut it down to test the new one. You have to run both.
The data is the hard part. The new core needs clean, consistent data. The old core has years of accumulated mess.
The integrations are load-bearing. Every other system in the organisation connects to the core. Changing the core changes every connection.
The people know the old system. Training on the new system is not a one-day event. It is a months-long process.
The regulator is watching. In banking and insurance, the core system is part of the regulatory environment. Change it without proper controls and you have a compliance issue.

The design you should be able to review

A new core replacement has a written design. Not a slide with boxes and arrows. A design an architect can challenge. Three patterns cover most high-stakes work.

New book writing: new business on the new platform

The most common pattern in banking and insurance. New business (new policies, new accounts, new loans) is written on the new platform from a defined date. Existing business (the old book) stays on the old system. Over time, the old book runs off through normal business processes: policies lapse, accounts close, loans are repaid.

This is not a workaround. It is a controlled design. The new platform proves itself on new business before anyone touches the existing book. The old book remains on the old system until it is small enough to convert or run off.

The risk is that the old book never shrinks. If the old business is long-lived (policies with twenty-year terms, for example), the old system may need to stay alive for years. Plan for that. Budget for it. Do not pretend the old book will disappear in twelve months.

Parallel run with defined tolerance

The old system remains the system of record. The new system processes the same inputs. You compare outputs until they match within a defined tolerance, for a defined period, with named owners signing the comparison.

Parallel run is slow and expensive. It is also the honest way to prove a ledger, a policy engine, or a payroll is right before you trust it. If you cannot say what "match" means, you are not ready to run in parallel.

Phased cutover by product, channel, or geography

You cut over a defined slice: one product, one country, one plant, or one channel. You do not move everything. You move a boundary you can reverse.

This is the strangler fig pattern applied to core systems. The new platform grows around the old one. One slice of work moves to the new path, gets proven, and the old system shrinks.

Whatever pattern you pick, three designs have to sit underneath it.

Data movement. Map every field that matters. Say what you will clean, what you will leave, and what you will not move. Trial-load into a non-production environment. Reconcile counts, totals, and samples. Repeat until the reconciling items are understood, not ignored. The hard part is never the new software. It is the existing data.

Testing gates. Do not test at the end. Gate the programme: environment ready, data trial accepted, integration proven, operational runbook rehearsed, rollback rehearsed. A gate that can be waived by optimism is not a gate.

Rollback. Write down how you go back. Restore the old system. Re-point traffic. Re-open the old channels. Name the person who can call it, the evidence they need, and the time they have. If rollback is "we will think about it on the night", you do not have a design.

"only 10% of the value comes from the algorithms, 20% from the technology and data, and 70% from managing process change" ::

Core system replacements prove that ratio. The new platform is the smaller part. The process change, the training, and the operating model are the work.

A roadmap with decision points

Do not start with a vendor demo. Start with a verdict you own.

1. Assess (two to four weeks, fixed price). What the old core actually does. Which parts the business cannot stop. Which data is trustworthy. Which integrations are load-bearing. Which replacement is justified. You own the verdict and the roadmap whether or not we build any of it.

2. Choose the pattern. New book, parallel, or phased. The choice depends on the business risk, not the vendor's preference. If the old book is long-lived, new book writing may take years. If the risk tolerance is low, parallel run may be the only honest option.

3. Bound the first slice. One product, one channel, one geography. Success criteria in writing: what "good" looks like, what "stop" looks like, who signs.

4. Design the data movement. Field-level mapping. Trial-load plan. Reconciliation definition. This is where most programmes fail. Do not skip it.

5. Build the first slice. Fuzzelogic delivers a working version in twelve to sixteen weeks from an agreed roadmap, against twelve to eighteen months in house. That is a working slice, not a full core replacement.

6. Prove it. Trial data loads. Parallel compare where the risk requires it. Operational rehearsal. Security review. Gate review with the right to stop.

7. Cut over the slice. Planned window. Named decision maker. Rollback live until the slice is accepted.

Decision points that must be real, not ceremonial:

Source: BCG, How Leaders Build an AI-First Cost Advantage, Mar 2026

frame 1. Go / no-go after assessment. If the honest answer is that the core should not be replaced yet, put that in writing. 2. Go / no-go after the first trial load. If the data cannot be reconciled, stop. 3. Go / no-go after parallel compare (if you are using it). If the outputs do not match within tolerance, stop. 4. Go / no-go on cutover night. If rollback conditions are met, roll back. Reputation survives a delay. It does not always survive a bad cutover. :::

What changes by industry

The pattern language is shared. The constraints are not.

Banking and insurance. Customer records, payments, and ledgers cannot be "best effort". Data residency, audit trails, and accounting standards are design inputs, not a later compliance check. New-book writing on the new platform, with the old book remaining on the old system, is often the only honest way to keep selling while you convert.

Oil and gas, mining, minerals, quarry. Operational continuity in remote sites matters more than a tidy architecture diagram. Plant and control systems are not office software. Core replacements have to respect maintenance windows the operation will actually honour.

Manufacturing, automotive, shipyards, construction, textile and clothing. Production-line continuity is the constraint. ERP replacements fail when they ignore the shop floor. Quality systems have to keep certifying product during the change.

Military and defence. Accreditation, configuration management, and long support lives dominate. Core replacements must be planned far in advance and tested in environments that mirror operational conditions.

Agriculture. Seasonal windows are real. You do not cut over a harvest system in harvest. Design around the calendar.

How to talk about value without inventing numbers

Do not put a made-up percentage in the board paper. Use a framework the finance director can audit.

Hard cost. Licence, infrastructure, and the people who only exist to keep the old core alive. Use your actual run-rate, not a vendor's "typical saving".

Risk reduction. Failed audits, security exceptions, conduct issues, and the cost of a failed cutover. You will not get a precise number. You can still say whether the current risk is acceptable.

Operational efficiency. Cycle time for a change, time to produce a report, time to onboard a product. Measure the current baseline before you claim an improvement.

Compliance. Faster evidence, clearer lineage, fewer manual controls. If the regulator or auditor cannot see the trail, the new core has not improved compliance.

Time to value. A working slice in twelve to sixteen weeks is a time-to-value number we will stand behind for scoped work. A full core replacement is a programme of slices. Budget it that way.

Long-term cost of ownership. Three-year cost of keeping the old core versus three-year cost of the new one, including maintenance. If the new core has no owner after launch, the cheaper build is the more expensive outcome.

"67% of enterprise AI programs exceeded first-year budget." ::

Core system replacements overshoot for the same reasons: the data work was underestimated, the integrations were not listed, and the process change was treated as someone else's problem. Count those lines in the first estimate.

Common pitfalls, and the design that avoids them

Big-bang cutover because "it will be simpler". It is simpler on a slide. It concentrates all risk into one night. Prefer a slice you can reverse.

Skipping the trial load. Live data is not the sample the vendor used in the demo. Trial-load until reconciliation is boring.

No rollback. Hope is not a plan. Rehearse the return path.

Moving the mess. If you copy bad data into a new core, you have a more expensive mess. Cleanse what you will use. Leave what you will not.

Treating twelve to sixteen weeks as a full core replacement. It is a working slice. Scope honestly.

No owner after launch. Replacement without maintenance is how the next legacy system is born. We maintain what we build.

If the honest answer is that a core system should not be replaced yet, we put that in writing rather than rebuild it anyway.

Start with the design, not the cutover date

The transformation opportunity is to stop paying for a core that cannot change, and to own one that can. The cost of staying is real. The cost of a bad replacement is also real. The difference is a design you can review, a slice you can reverse, and a partner who will tell you when not to proceed.

Start with the assessment. Two to four weeks, fixed price, and you own the verdict and the roadmap whether or not we build any of it. When you are ready to talk software, maintenance, or AI, call Fuzzelogic Solutions and ask for Zak.

Source: Infosys, AI Tokennomics

faq What is a new core system? :: A new platform that becomes the system of record for the work the business actually does: a new ledger in banking, a new policy engine in insurance, a new ERP in manufacturing. What is new-book writing? :: New business is written on the new platform from a defined date. Existing business stays on the old system. Over time, the old book runs off through normal business processes. How long does a core replacement take? :: A working slice can land in twelve to sixteen weeks. A full core replacement is a programme of slices, not one sprint. The old book may remain for years. Can you replace a core system with no downtime? :: No honest design promises zero interruption in every case. The goal is to keep the business running. Any stoppage should be planned, short, and reversible. What if the old book never shrinks? :: Plan for it. Budget for it. If the old business is long-lived, the old system may need to stay alive for years. Do not pretend it will disappear in twelve months. How do we start? :: A fixed-price assessment over two to four weeks. You own the verdict and the roadmap whether or not we build any of it. :::

www.FuzzelogicSolutions.com | info@FuzzelogicSolutions.com | +44 (0)1624 618950

Zakir Hoosen, Director Suite 1B, 11 Circular Road, Douglas, Isle of Man IM1 1AF +44 (0)7624 482071 | +44 (0)1624 618950

Start with the assessment

Two to four weeks, fixed price, and you own the verdict and the roadmap whether or not we build any of it.

Get in touch

When you are ready to talk software, maintenance, or AI, call Fuzzelogic Solutions and ask for Zak.