The board wants the core system replaced. Operations wants nothing to change on Monday morning. Both are right, and that is why most modernisation programmes either stall or quietly become a two-year rewrite with a weekend cutover nobody wants to own.
If you run technology at a mid-sized company in the UAE, you know the pattern. The core handles invoices, inventory, claims or branch operations. It is old, brittle and still the thing that makes money. You cannot take it offline for six months, and you also cannot keep patching it forever.
Here is a practical way to modernise a core system while the business keeps running.
1. Draw a hard line around what "core" means
People call everything core when a project starts. The billing engine, the reporting warehouse, the intranet login screen, and that Excel macro Finance swears by all get pulled into the same programme.
What to do: list the flows that, if they stop for a day, stop revenue or regulatory reporting. Those are core. Everything else is adjacent and can wait. Write the list in one page and get the business owner to sign it. If the list has more than five flows, it is not finished yet.
2. Put a stable interface in front of the old system first
Jumping straight into a rewrite means every new piece has to talk to the old one in its native, messy language. That is how you end up rewriting the same glue code three times.
What to do: wrap the old system behind a clear boundary. APIs, events or a thin service layer that speaks modern contracts while the legacy code stays behind it. New work talks to the wrapper. The old system can keep changing underneath without poisoning every new build.
3. Move one slice of traffic, not the whole company
Big-bang cutovers look decisive in a slide. In practice they pack every unknown into a single weekend, then discover the unknowns at 2am.
What to do: pick one bounded slice, such as new customers only, one product line, one branch or one report path. Route that traffic to the new path. Keep the rest on the old system. Measure both. Expand when the numbers hold. Shrink if they do not. Boring, and much safer than a heroic switch.
4. Keep dual-running short and deliberate
Running old and new side by side is expensive. Running them forever is how programmes lose the plot.
What to do: set a dual-run window in weeks, not quarters, for each slice. Agree what "good enough" looks like before you start: error rates, cycle time, and one business metric the owner already watches. When the new path hits those numbers for the agreed period, switch the old path off for that slice. Do not leave both open "just in case" with no exit date.
5. Freeze non-critical changes on the legacy side
While you modernise, the old system still attracts tickets. Every urgent tweak makes the target move and teaches the organisation that the old path is still the real one.
What to do: create a change budget for the legacy system. Critical fixes and regulatory must-dos go through. Nice-to-haves go on a backlog for the new path. Put a named person on that gate so "quick request" does not become a second programme.
6. Rehearse failure the same way you rehearse go-live
Teams practice the happy path. They rarely practice rolling back when the new path misbehaves under real load.
What to do: before each slice goes live, run a rollback drill with the same people who will be on call. Write down who decides, who flips traffic back, and how long you wait before calling it. If that drill feels awkward, the go-live plan is not ready.
7. Tell the business what will feel different, and what will not
Silence creates rumours. Staff assume the new system will break the workflow they know, so they invent workarounds before you even ship.
What to do: for each slice, send a short note that names what stays the same, what changes on day one, and who to call if something looks wrong. Keep it in plain language. One page beats a 40-slide deck nobody reads.
A simple sequence that keeps the lights on
- Week 1 to 2: define the five core flows, wrap the old system behind a stable interface, and pick the first slice.
- Week 3 to 6: build the new path for that slice, dual-run with a fixed exit date, and rehearse rollback.
- Week 7 to 8: switch the slice fully, turn the old path off for it, and choose the next slice from what you learned.
Repeat until the core is gone, one bounded piece at a time.
The point of not stopping the business
Modernisation is not a weekend project with a ribbon-cutting. It is a series of small, reversible moves that shrink the old system until there is nothing left to fear. The companies that finish are the ones that kept shipping on the old path while they earned the right to leave it.
If you have moved a core system in pieces, which slice was hardest to cut over first?
Originally published on LinkedIn by Latent Digital Solutions, a Dubai-based software development company: https://latentdigitalsolutions.com
Top comments (0)