Transformation

How to replace a legacy system without stopping the business

The old system is expensive, brittle, and hard to change. Replacing it badly is worse. This playbook is the design you can review before anyone cuts over.

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

Legacy system migration means moving work from an old system to a new one while the organisation keeps trading. It is not a weekend cutover with a prayer. It is a designed change: what moves first, what stays, how you prove the new system is right, and how you go back if it is not.

Boards already know the old system is a problem: rising run cost, fewer people who understand it, and changes that take too long because every one of them might break something else. The opportunity is real. So is the cost of getting the replacement wrong.

That gap is not a mystery. Programmes treat replacement as a technology project. It is a business project that happens to use technology. The design has to be good enough that a CIO, an enterprise architect, and a risk committee can read it and challenge it.

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.

What staying on the old system actually costs

The bill is not only the licence. It is the people who still know the old system, the workarounds that have become unofficial process, the audits that take longer because the evidence is hard to extract, and the new product you did not launch because the change window was too risky.

The risks sit in five places. Name them in the business case or the business case is incomplete.

1. Compliance. Audit trails, data residency, and reporting obligations do not pause because you are changing systems. If the new platform cannot prove who changed what, and when, you have bought a new problem.
2. Downtime. In a bank, channels stop. In a plant, a line stops. In a hospital, records stop. Unplanned stoppage is the failure mode boards remember.
3. Security. Old platforms accumulate exceptions. Accounts that should have been removed. Interfaces that were never locked down. Replacement without a security design copies the holes.
4. Scale. The old system may still run today's volume and fail tomorrow's. Growth is not a reason to rush. It is a reason to design for the load you will actually have.
5. Cost of ownership. Run cost, change cost, and exit cost. If you cannot say what it costs to keep the old system for three more years, you cannot say whether replacement is cheaper.

Do not invent a saving to win the budget. Add up the real run cost, the real change cost, and the real risk of a failed cutover. Then decide.

The design you should be able to review

A serious replacement has a written design. Not a slide with boxes and arrows. A design an architect can challenge. Four patterns cover most high-stakes work. Use the one that fits the risk, not the one that sounds modern.

Strangler fig: grow the new system around the old one

Martin Fowler described the strangler fig application as a way to replace a system by intercepting calls to it, building new behaviour beside it, and shrinking the old system until it can be switched off. You do not turn the old system off on day one. You route one slice of work to the new system, prove it, then take the next slice.

This is the default for a core that cannot have a long outage. It needs a clear boundary: which requests go to the new system, which stay on the old, and how you reverse the route if the new path fails.

Blue-green: two live environments, one receiving traffic

You run two production environments. Blue is live. Green is the new version, fully built and tested. You switch traffic from blue to green. If green fails, you switch back. The business sees a short, planned change of route, not a rebuild in public.

Blue-green needs the two environments to be truly equivalent: data, configuration, integrations, and access. If green is "almost" like blue, the switch is a gamble.

Parallel run: both systems process the same work

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 claims 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: move by product, channel, or book

You cut over a defined slice: one product, one country, one plant, one "book" of business. You do not move everything. You move a boundary you can reverse.

In insurance and banking this often means writing new business on the new platform (the new book) while the old book stays on the old system until policies lapse, claims close, or a later conversion is justified. That is not a workaround. It is a controlled design. Treating "new books" as a slogan without a run-off plan for the old book is how programmes stall for years.

Data movement, testing gates, and rollback

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 data. Re-point traffic. Re-open the old system. 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.

Replacement programmes 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 system actually does. Which parts the business cannot stop. Which data is trustworthy. Which integrations are load-bearing. Which replacement is even justified. You own the verdict and the roadmap whether or not we build any of it.

2. Bound the first slice. One product, one channel, one plant, or one book. Success criteria in writing: what "good" looks like, what "stop" looks like, who signs.

3. Design the pattern. Strangler, blue-green, parallel, or phased. Draw the traffic, the data, the compare, and the rollback. Review it with architecture, operations, security, and the business owner.

4. Build a working 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. Anyone who quotes one number for replacing an entire core is selling, not designing.

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

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

7. Run, then take the next slice. Maintenance starts at handover. The next slice uses the same pattern, adjusted by what the first slice taught you.

Decision points that must be real, not ceremonial:

1. Go / no-go after assessment. If the honest answer is that the system 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.

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 system alive. Use your actual run-rate, not a vendor's "typical saving".

Risk reduction. Unplanned downtime, failed audits, security exceptions, 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 system 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 system versus three-year cost of the new one, including maintenance. If the new system has no owner after launch, the cheaper build is the more expensive outcome.

Replacement programmes 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.

What changes by industry

The pattern language is shared. The constraints are not. We have modernised platforms in banking, insurance, healthcare, retail, manufacturing, and government. Other sectors below are included because the constraints are real, not because we are claiming a case study in each one.

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. Channel downtime is a conduct issue, not only an IT issue. 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. Failed replacements in this environment are expensive because you cannot quietly undo a posted transaction.

Oil and gas, mining, minerals, quarry. Continuity on remote sites matters more than a tidy diagram. Plant and control systems are not office software. A stoppage has safety consequences, not only lost tickets. Replacements have to respect maintenance windows the operation will actually honour.

Manufacturing, automotive, shipyards, construction, textile and clothing. The line cannot stop for an IT convenience. Execution and ERP replacements fail when they ignore the shop floor. Quality systems still have to certify product during the change.

Military and defence. Accreditation, configuration management, and long support lives dominate. Some environments are air-gapped. You move in controlled steps, with rollback that does not depend on a vendor console.

Agriculture. Seasonal windows are real. You do not cut over a harvest system in harvest. Design around the calendar, not the vendor's sprint board.

Logistics and packaging. Scan events and customer cut-off times leave little room for an unplanned stop. If the warehouse system is wrong for an hour, the trucks still arrive.

If your sector is not on that list, the questions are the same. What cannot stop. What must be true on the morning after cutover. Who can halt the programme.

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 platform, you have a more expensive mess. Cleanse what you will use. Leave what you will not. Say which is which.

Vendor-led design the customer cannot read. If only the integrator understands the cutover, you do not own the risk. You are renting it.

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 system should not be replaced yet, we put that in writing rather than rebuild it anyway.

Evaluation checklist

Use this before you approve a partner, a pattern, or a date.

1. Is there a written design an architect who does not work for the vendor can review?
2. Is the first slice bounded, with success and stop criteria?
3. Is the pattern named (strangler, blue-green, parallel, phased) and justified against downtime risk?
4. Is there a field-level data map, a trial-load plan, and a reconciliation definition?
5. Are testing gates real, with named people who can fail them?
6. Is rollback written, rehearsed, and timed?
7. Is the three-year cost of staying versus moving based on your numbers, not a brochure?
8. Is there an owner for the new system after launch, including maintenance?
9. For regulated work: can you show an audit trail, data residency, and who is accountable for a posted error?
10. For operational work: is the cutover window one the plant, farm, warehouse, or channel will actually accept?

If you cannot tick those, you are not ready to cut over. You are ready to assess.

Start with the design, not the cutover date

The transformation opportunity is to stop paying for a system that cannot change, and to own a system 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.

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