DEV Community: Latent Digital Solutions

How to Modernise a Core System Without Stopping the Business

Latent Digital Solutions — Wed, 21 Oct 2026 03:07:14 +0000

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

Why AI Pilots Stall Before Production (and How to Get Them Across)

Latent Digital Solutions — Wed, 21 Oct 2026 03:06:31 +0000

The demo went well. The model answered questions, the slide said "pilot success," and someone booked a follow-up about "scaling." Three months later the same pilot is still in a sandbox, and the business has quietly moved on to the next shiny tool.

If you run technology at a mid-sized company in the UAE, you have probably lived a version of this. A vendor or an internal team shows something impressive on a laptop. Real production, with messy data, approvals, and people who did not sit in the demo, is a different job entirely.

AI pilots stall before production for predictable reasons. Here is what usually breaks, and what to do instead.

1. The demo used clean data; production does not

Demos run on tidy spreadsheets or a curated sample. Production has missing fields, bilingual free text, duplicate customers, and last year's naming conventions still sitting in the same table.

What to do: before you call the pilot a win, put it on a real slice of production data. Not the whole warehouse. One messy month of invoices, tickets or claims is enough. If accuracy drops hard, that is the real baseline, not the demo score.

2. Nobody owns what happens when the model is wrong

In the room, everyone laughs when the answer is slightly off. In production, a wrong recommendation can hold up a payment, a customer reply or a compliance check. If there is no clear owner for review and override, the tool stays "interesting" and never gets wired in.

What to do: name one business owner and one technical owner before you expand the pilot. Write down who reviews outputs, when a human must approve, and what happens when the model is unsure. If that sentence is hard to write, you are not ready for production.

3. The pilot never touched the systems people actually use

A chatbot in a browser tab is easy to demo. Getting the same answer into the ERP, CRM or service desk people live in every day is where projects stall. Integrations, permissions and audit logs show up late and eat the budget.

What to do: pick the thinnest path into a real workflow. One button in an existing screen, one queue that staff already open, one export that currently takes a person an hour. If the pilot cannot sit next to real work, it will not survive the next budget round.

4. Success was defined as "the model looks clever"

Looking clever is not a KPI. Reducing handle time, cutting manual review, or catching exceptions earlier is. Without a number the business already cares about, the pilot has no argument for more investment.

What to do: agree one measurable outcome before the pilot starts. For example, minutes saved per case, fewer hand-offs, or fewer reworks after go-live. Measure the same thing on the messy data, not only on the demo set. If you cannot measure it in four to six weeks, shrink the scope until you can.

5. Security and data residency appear in week twelve

In the UAE, where data sits and who can see it is not a footnote, especially in banking, insurance, healthcare and government-adjacent work. A pilot that sent samples to a public model in another region often cannot be repeated with live customer data.

What to do: ask the hosting and residency questions in week one. Confirm which region the model runs in, what leaves your network, what is logged, and what your regulator or internal policy allows. It is cheaper to redesign a small pilot than to rebuild a "successful" one that cannot go live.

6. The team that built the demo is not the team that will run it

Someone clever wired a notebook, an API key and a nice UI. Then they moved to the next project. Production needs monitoring, cost controls, versioning, and a person who answers the phone when outputs drift.

What to do: treat the pilot like a small product from day one. Decide who watches it after launch, how you will know it is degrading, and how you roll back. If that person does not exist yet, the stall is already booked.

7. Scope grows until the pilot cannot finish

Once leadership likes the demo, every department adds a use case. The original narrow win becomes a platform for everything. Momentum dies under workshops.

What to do: protect a single production path. Ship one use case end to end, learn from it, then decide the second. A small thing in production beats a large thing still in slides.

A simple shape for getting a pilot into production

Weeks 1 to 2: put the model on messy real data, settle residency and access, and lock one business metric.
Weeks 3 to 4: wire the thinnest path into an existing workflow, with a named reviewer and a clear override.
Weeks 5 to 6: run it with a small group of real users, measure the metric, fix the boring failures, and decide go / no-go for a wider rollout.

The point of the pilot

A pilot is not a theatre for the model. It is a cheap way to learn whether your data, your systems and your people can carry this into daily work. If those three are not ready, the demo was never the hard part.

If you have an AI pilot stuck between "impressive" and "live," what is the one thing holding it there?

Originally published on LinkedIn by Latent Digital Solutions, a Dubai-based software development company: https://latentdigitalsolutions.com

Legacy System Modernisation: What Goes Wrong in the First 90 Days (and How to Avoid It)

Latent Digital Solutions — Tue, 20 Oct 2026 18:11:56 +0000

Every legacy system modernisation starts with a confident slide. "Phase 1: Discovery, four weeks." Then someone finds a stored procedure called sp_final_v2_DO_NOT_TOUCH, and the plan quietly becomes a suggestion.

If you run technology at a mid-sized company in the UAE, you probably have one of these systems. It's a .NET or Java application built around 2010, sitting on a SQL Server or Oracle database that has absorbed fifteen years of business rules. Two people really understand it, and one of them is on leave.

The first 90 days decide whether modernising a legacy system turns into a steady programme or an expensive rewrite that never ships. Here is what usually goes wrong in that window, and what to do instead.

1. The documentation describes a system that no longer exists

The documents were written when the system was built. The system kept changing; the documents didn't. The real rules now live in code, database triggers, a few spreadsheets and people's heads.

What to do: treat the running system as the specification. Spend the first weeks tracing real transactions from start to finish, such as a month-end close, a customer refund or a VAT invoice. Write down what the system actually does, including the strange parts. The strange parts are usually business rules someone asked for in 2014.

2. Nobody agrees on what "done" looks like

Finance wants faster reports. Operations wants zero downtime. IT wants to get off an unsupported version. Everyone says "modernise" and means something different.

What to do: agree on three outcomes you can measure within the first year. For example, moving releases from quarterly to monthly, retiring an on-premise server before its support contract ends, or cutting the time it takes to onboard a new branch. If a piece of work doesn't move one of those three, it waits.

3. The big rewrite looks cheaper than it is

Rewriting from scratch is tempting because it feels clean. In practice you end up running two systems, the old one keeps changing underneath you, and the new one has to match fifteen years of edge cases before anyone can switch over.

What to do: replace the system in slices. Pick one well-bounded area, such as reporting, a customer portal or a single integration. Put a clear interface in front of the old system, build the new piece behind it, move traffic across, then switch the old part off. Repeat. It is less exciting than a rewrite and far more likely to finish.

4. The data is the real project

Code gets the attention, but data causes the delays. Duplicate customers, free-text fields used as status flags, dates stored in three formats, and Arabic and English names that don't match across tables.

What to do: start profiling the data in week one, not month four. Decide early who makes data quality decisions. That is a business call, not an IT one.

5. The people who know the system get stretched thin

The two experts are suddenly in every workshop, still supporting production, and answering every question from the new team. They either burn out or become the bottleneck.

What to do: protect their time on purpose. Record walkthroughs, pair them with newer engineers, and take routine support off their plate for the length of the project.

6. Compliance and hosting questions show up late

In the UAE, where your data sits and who can reach it matters, especially in banking, insurance and healthcare. These questions have a habit of appearing the week before go-live.

What to do: bring security and compliance into the conversation in week two. Confirm early which cloud region you will use (both Azure and AWS now have regions in the UAE) and what your regulator expects.

7. Nothing visible ships for three months

Discovery drags on, stakeholders lose patience, and budget questions start arriving.

What to do: aim to put one small, real improvement into production inside the first 90 days. A report that runs in seconds instead of an hour, or an API that replaces a manual export. It proves the approach works and buys trust for the harder parts.

A simple shape for the first 90 days

Days 1 to 30: trace real processes, profile the data, agree the three outcomes, and map who knows what.

Days 31 to 60: choose the first slice, put automated tests around how the current system behaves, set up the interface in front of it, and settle hosting and compliance.

Days 61 to 90: build and ship the first slice, measure it against the outcomes, and plan the next two slices based on what you learned.

The point of the first 90 days

The old system has survived fifteen years because it does something important. The first 90 days are about learning exactly what that is before you replace it. Skip that step and you end up rebuilding the same system, just newer, and understood by even fewer people.

If you have been through one of these, what surprised you most in the first three months?

Originally published on LinkedIn by Latent Digital Solutions. We help UAE businesses modernise legacy systems: https://latentdigitalsolutions.com