How can a business modernize legacy systems without disrupting operations?

Modernize in phases rather than in one cutover. Put a routing layer or API in front of the old system, move one business capability at a time, and run old and new in parallel until outputs match. Shift a small share of real traffic first and keep a rollback path until each step is proven. Retire the old component only after the new one has run cleanly through a full business cycle.

Is it better to modernize all systems at once or in phases for a regulated company?

Phases are safer for a regulated company. A single cutover concentrates risk into one weekend, as the UK bank TSB found in 2018, when a predominantly single-event migration led to 225,492 complaints and a £29.75 million fine (FCA, 2022). Phased moves let you evidence testing, reconciliation and rollback for each step, which is also what regulators and auditors ask to see.

What does sequencing modernization without operational disruption mean?

It means ordering the work so the business never depends on an unproven component. You start with a capability that is painful, changes often and has few dependencies. Then you move it behind a routing layer, run it in parallel, and shift traffic gradually. Each capability follows the same steps, and the tightly coupled core usually moves last.

How can I scale our legacy systems without disrupting current operations?

Separate the parts that need to scale from the parts that do not. Wrap the legacy core with an API, then build the high-load capability, such as customer-facing search or reporting, as a new service fed by synced data. The core keeps running unchanged while the new service takes the load. Move more capabilities out only when each one proves stable.

Who can help us modernize legacy systems without disrupting ongoing operations?

Look for a partner who will own both the architecture and the sequence, not just the coding tasks. A Fractional CTO can set the plan, milestones and retirement dates, while a product development team builds and migrates each capability. Ask any partner for a phased plan, a rollback approach for each step, and a reference project where the business kept running.

Levich

Back to Journal

Fractional CTOAug 21, 2026· 9 min read

How to Modernize Legacy Systems Without Disrupting Operations

Ajo John

Co-Founder & CPO, Levich

To modernize legacy systems without disrupting operations, replace them in phases, not in one cutover. Put a routing layer in front of the old system and move one business capability at a time. Run old and new side by side until the numbers match, and keep a way back until each step is proven.

This guide is for CEOs, COOs and CTOs of mid-size companies whose core systems still work but slow every change down. It covers how to decide what to modernize first, which phased approach fits, how to keep risk low during each move, and what a realistic first 90 days look like.

Key takeaways

Most disruption comes from big-bang cutovers, so move one capability at a time behind a routing layer.

Pick the first piece by business pain and low coupling, not by how old the code is.

Run old and new in parallel and reconcile the outputs before you switch any traffic.

A written plan with milestones, scope and a retirement date for the old system is what separates finished programs from stalled ones.

Why do legacy systems become risky to change?

A legacy system is risky to change when it still runs the business but few people can safely predict what a change will break. Age alone is not the problem. Tight coupling, missing tests, retired languages and knowledge held by one or two people are.

The US federal government shows how long this can drag on. In July 2025, the Government Accountability Office (GAO) reviewed the 11 federal legacy systems most in need of modernization. They ranged from about 23 to 60 years old. Eight of the 11 used outdated languages, four had unsupported hardware or software, and seven were operating with known cybersecurity vulnerabilities (GAO, 2025).

Progress was slow even where the need was clear. Of the 10 systems GAO flagged in 2019, agencies had completed three of the 10 modernizations as of February 2025 (GAO, 2025).

What goes wrong with a big-bang replacement?

A big-bang replacement moves every user, process and record to a new system in one event. If anything fails, everything fails at once, and customers feel it the same day.

The best-documented case is the UK bank TSB. Over the weekend of April 20 to 22, 2018, it moved most of its operations, customer services and customer data to a new platform in a predominantly single migration event (FCA, 2022).

Digital banking, telephone banking, branch systems and card payments all ran into problems. TSB received 225,492 complaints, about 4.3% of its customer base, and paid £32,705,762 in redress by April 7, 2019. It did not return to business as usual until December 10, 2018. The Financial Conduct Authority (FCA) later fined it £29.75 million (FCA, 2022).

Martin Fowler puts the general pattern bluntly in his write-up of the strangler fig approach. His teams have seen the full-rewrite plan "go down in flames most of the time" (Fowler, 2024).

How should you assess a legacy system before changing it?

Assess the system by business capability, not by codebase. List what the system does for the business (orders, billing, scheduling, reporting) and score each capability on four questions:

Pain: how much does it slow revenue, cost or compliance today?
Change rate: how often does the business need to change it?
Coupling: how many other capabilities read or write the same data?
Knowledge: how many people can safely change it, and is it documented?

High pain, high change rate and low coupling marks the best first candidate. Leave tightly coupled, rarely changed capabilities until last. They often cost more to move than they return.

Write down what "working" means before you touch anything. Record today's volumes, error rates, batch run times and month-end close times. Without that baseline, nobody can prove the new system is as good as the old one.

Which phased modernization approach fits?

Most phased programs use one of four approaches. Many use more than one, capability by capability.

Approach

What it means, and best when

Main risk

Strangler fig

A routing layer sends some requests to new services and the rest to the old system, shifting traffic over time. Best when the system is large and requests can be intercepted

The routing layer becomes a bottleneck or single point of failure

Rehost or replatform

Move the system to new infrastructure with little or no code change. Best when hardware or hosting is the main problem

You keep the old code and its limits

Wrap and extend

Put an API in front of the old system and build new features outside it. Best when the core is stable but hard to extend

Business logic stays locked in the old system

Replace one module

Swap one capability for packaged software or a new build. Best when the capability is standard, such as billing or HR

Data migration and integration take longer than planned

The strangler fig is the default for systems that must keep running. A facade intercepts requests and routes each one to the legacy application or a new service. Customers keep using the same interface and do not see the migration happening (Microsoft, 2026).

It does not fit everywhere. Microsoft's guidance says it may not suit systems where requests cannot be intercepted, where you cannot change the legacy source code, or where the system is small enough to replace simply (Microsoft, 2026).

Talk to a Fractional CTO about your modernization plan

How do you keep risk low during each move?

Treat every capability move as its own small release with an exit. Five practices do most of the work:

Parallel runs: run old and new on the same inputs and reconcile the outputs, such as invoice totals or stock counts, before switching any users.
Gradual traffic shifts: move one region, customer segment or product line first, then widen.
A way back: keep the old path available until the new one is proven. Microsoft notes that rollback stays possible while the legacy data and sync processes still exist, and that removing legacy objects should be a deliberate final step (Microsoft, 2026).
Data sync, not data freeze: copy data to the new store and keep it in sync with change data capture, so both systems work during the transition.
Cutover windows that match the business: avoid month-end, peak season and audit periods.

Each of these costs a little more time per step. That time is cheaper than a weekend like TSB's.

What should a modernization plan include?

A plan is what turns a modernization into a finished program instead of a permanent project. GAO's review found that agencies had documented plans for nine of the 11 critical systems, but only three of those plans included all three key elements (GAO, 2025). Those elements apply to any company:

1. Milestones to complete the modernization.
2. A description of the work needed to modernize the system.
3. Details of how the legacy system will be retired.

The third is the one most often skipped. If the old system never gets switched off, you end up paying to run two systems.

What does the first 90 days look like?

A realistic first quarter proves the approach on one capability before you scale it:

Weeks 1 to 3: map capabilities, record the baseline, and pick the first candidate.
Weeks 4 to 6: put the routing layer or API in front of the old system, with no behavior change.
Weeks 7 to 10: build the new capability and run it in parallel, reconciling outputs daily.
Weeks 11 to 13: shift a small share of real traffic, watch the baseline metrics, then widen or roll back.

At day 90 you should have one capability live on the new path, a measured comparison against the old one, and a plan for the next three.

A real example: 100 spreadsheets replaced by one platform

Finance in a Box is a US-based financial services firm that ran client accounting across more than a hundred disconnected spreadsheets. Levich built FinOpz, one platform covering close management, an agent layer and purpose-built apps, and the firm cut its operational workload by 85%.

One design choice matters for any modernization: Finsheets, a spreadsheet-style working surface connected to the same live platform data. People keep a familiar way of working, while the data behind it moves to one system.

Keep the business running while the system changes

Modernization fails when it is treated as one event. It works when it is a sequence of small, reversible moves, each measured against a baseline and each with a retirement date for the code it replaces.

Talk to Levich about modernizing a legacy system