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
Top comments (0)