Replacing a Legacy System Without Stopping the Business

The safest way to replace a legacy system is rarely to switch it off one weekend and switch a new one on. It is to replace it in slices. One capability moves at a time behind a routing layer, the old and new systems run side by side, and the old one shrinks until nothing is left in it.

You start by finding out what the old system really does — including the reports and nightly jobs nobody listed. Then you decide, per capability, whether to keep, wrap, replace or retire it. You migrate only the data you still need, reconcile old against new before each cut-over, and keep a read-only archive for records the law requires you to retain.

This article walks through that sequence. A “big bang” replacement is the right choice in a few cases, and they are covered too.

The short answer

• Map before you build. Most legacy systems do more than anyone remembers. The forgotten functions are what break a cut-over.
• Decide per capability, not per system: keep, wrap, replace or retire.
• Replace in slices behind a routing layer, so each step is small and reversible.
• Migrate less data than you think, and clean it before it moves.
• Run in parallel and reconcile before each switch.
• Keep a read-only archive for legal retention, and erase the rest when its purpose has ended.

Why big-bang replacements fail

A big-bang replacement changes everything on one date: software, data, processes, screens and the habits of every user. If anything goes wrong, there is usually no clean way back. The old system has stopped receiving data, and the new one is now the only record.

The failures are predictable. Data migration surfaces problems nobody knew existed, such as duplicates, free-text fields used as codes, and records that break the new system’s rules. A report the finance team runs every month turns out to depend on a field the new system does not have. Staff who were trained once, weeks earlier, meet the real thing on the busiest day of the month.

None of this is a technology problem. It is the same set of decisions that sinks large system projects in general, covered in why ERP and CRM projects fail. Slicing the replacement makes each of those decisions smaller.

When big bang is right anyway: when the old system is small, has few integrations, and holds little history. Or when it is about to stop working — an unsupported platform, a dead vendor — and running two systems is not possible. Even then, rehearse the migration at least twice before the real one.

Signs it is time to replace

Legacy is not a matter of age. A ten-year-old system that does its job, is supported and can be changed is an asset. These are the signs that it has become a liability:

• One person understands it, and that person is thinking about leaving.
• The vendor no longer supports it, or security patches have stopped.
• It cannot connect to anything, so staff retype data between it and newer tools.
• It cannot meet a legal obligation. Oman’s e-invoicing mandate, covered in what Fawtara requires from your systems, is the clearest current example. Data protection is another. Since September 2026, Oman’s law requires erasure when the purpose of processing ends, and some old systems cannot delete a customer at all.
• Every change is expensive and frightening, so the business has started working around the system rather than through it.

One of these signs is a reason to plan. Two or more are a reason to start.

Step 1: map what the old system actually does

Write down every function, not just the screens. The dangerous ones are the invisible ones:

• scheduled jobs that run overnight — price updates, reminders, backups, data pushes to other systems;
• reports and exports, especially those someone opens in Excel every month;
• integrations, including files dropped into a folder that another system picks up;
• rules enforced in the database rather than the interface, such as triggers, constraints and calculated fields;
• workarounds staff have built around the system’s gaps.

Interview the people who use it, and watch them work. Ask “what do you do at month-end?” rather than “what does the system do?”. Then check the database and server for scheduled tasks. The list you end up with is longer than anyone expected. Each item missing from it is a failure waiting for cut-over day.

Step 2: keep, wrap, replace or retire

Decide per capability, not per system.

Decision	When it fits	What it involves
Keep	It works, is supported, and is not blocking anything	Leave it; connect to it
Wrap	The logic is sound but the system is closed or awkward	Put an interface in front so new systems can use it — see how system integration actually works
Replace	It cannot meet a requirement, or changing it costs more than rebuilding	Build or buy the replacement for that capability
Retire	Nobody needs it any more	Archive what the law requires, then switch it off

Retiring is the most underused option. A replacement project that builds every old feature faithfully will reproduce old problems at new prices. Legacy systems often carry functions that exist for reasons that no longer apply. Find them before you pay to rebuild them.

The build-or-buy choice for the replacements follows the same logic as any system decision. Build or buy an ERP sets out when building is justified.

Step 3: replace in slices — the strangler pattern

The approach has a name in software engineering: the strangler fig pattern, described by Martin Fowler after a plant that grows around a tree until it replaces it. In practice:

1. Put a routing layer in front of the old system. Every request — from users, other systems, or integrations — goes through it.
2. Move one capability at a time to the new system, and change the routing for that capability only.
3. Keep data in step while both systems are live, with one system clearly the owner of each kind of record.
4. Repeat until the old system receives no traffic, then retire it.

Each slice is small enough to test properly and to reverse if it goes wrong. The business never stops. Users see change in manageable steps rather than all at once.

The cost of this approach is real: for a period you run two systems and the synchronisation between them. That cost is the price of being able to undo a mistake. Slice the work so the overlap is months, not years. A strangler project that stalls halfway leaves you maintaining both systems indefinitely, which is worse than either.

Step 4: migrate less data than you think

The instinct is to bring everything across. Resist it.

Migrate what the new system needs to operate: open orders, active customers, current balances, live contracts, and history the business actually consults.

Archive what the law requires you to keep but nobody needs day to day, in a read-only store you can search. Tax records are the obvious case.

Erase what has no remaining purpose. Under Oman’s amended data protection law, personal data must be erased once the purpose of processing ends, unless a dispute or a legal obligation requires keeping it. A migration is the natural moment to apply that rule, and copying stale personal data into a new system makes the problem bigger. What Royal Decree 68/2026 changed covers the erasure duty.

Then clean what moves. Run the migration as a repeatable script, not a one-off copy, so you can rehearse it, fix the data, and run it again. Reconcile counts and totals after every rehearsal: customers in, customers out; balances before and after.

Two data protection points are often missed during migration:

• Test environments full of real customer data are a risk. Use anonymised or masked copies for testing wherever possible. Privacy by design in custom software covers how.
• Your record of processing activities changes. New systems, new vendors and new hosting locations all need recording, and a new hosting location abroad engages transfer rules.

Step 5: run in parallel, then cut over

Before switching each slice, run old and new side by side on real transactions for a defined period. Compare the outputs: invoices, stock levels, balances, reports. Every difference is either a bug in the new system or an undocumented rule in the old one. Both are worth finding before customers do.

Plan each cut-over as a short, rehearsed procedure:

1. a freeze on changes in the old system for that capability;
2. a final data sync and reconciliation;
3. the routing switch;
4. a checklist of things to verify in the first hour and the first day;
5. a written rollback plan, with a deadline after which you will not roll back.

Choose a quiet time of the business cycle. Month-end, VAT filing week and Ramadan rush are poor choices for a finance or retail cut-over.

Keeping the old records lawfully

When the last slice has moved, the old system becomes an archive. Keep it read-only, with access logged. Oman’s Electronic Transactions Law sets the conditions for electronic records to remain valid: unaltered or tamper-evident, accessible, and with originator, recipient and time identifiable. Electronic signatures and records in Oman covers them.

Then set a date to delete each category, tied to the obligation that justifies keeping it. An archive with no end date slowly becomes the new legacy system.

The people side

Systems are replaced by people changing how they work. Three practices help:

• Name an owner for each slice on the business side, with authority to decide how the process should work.
• Train close to the switch, on the real system with real data, not weeks before on a demo.
• Keep a visible channel for problems in the first weeks after each cut-over, and fix the small irritations fast. Small irritations are what make people build workarounds.

---

Frequently asked questions

How long does it take to replace a legacy system? It depends on how many capabilities, integrations and data sources the old system has, and how clean the data is. Slicing the work does not always shorten the total, but it delivers value from the first slice and keeps each step reversible. Estimate per slice rather than for the whole.

Should we rebuild every feature of the old system? No. Map the features first and decide per capability whether to keep, wrap, replace or retire it. Rebuilding features that no longer serve a purpose reproduces old problems at new prices.

Is it safe to run two systems in parallel? Yes, if one system is clearly the owner of each kind of record and synchronisation is monitored. The risk is a parallel period that never ends. Plan the overlap per slice and keep it short.

What should we do with old data? Migrate what the new system needs, archive what the law requires you to keep in a read-only searchable store, and erase personal data whose purpose has ended. Oman’s data protection law now requires that erasure unless a dispute or legal obligation applies.

Can we test the new system with real customer data? Avoid it where you can. Use anonymised or masked copies for development and testing. Where real data is unavoidable, restrict access and log it, and remove the copy when testing ends.

When is a big-bang replacement the right choice? When the old system is small, has few integrations and little history, or is about to stop working and parallel running is impossible. Rehearse the migration at least twice before the real cut-over.

---

This article states the position under the laws in force on 21 October 2026, the date of publication, and is not legal advice. Retention periods for specific records are set by the laws that require them; confirm yours with a qualified adviser.

Sources: Martin Fowler — Strangler Fig Application · Martin Fowler et al. — Patterns of Legacy Displacement · Royal Decree 68/2026 amending the Personal Data Protection Law · Royal Decree 39/2025 — Electronic Transactions Law (Arabic text)

Living with a system you can’t change or can’t replace safely? ZAWAT builds custom software and handles integration and support, including replacements carried out slice by slice. Book a call.