Replace the system everyone fears, one piece at a time

There are four honest options. Rehosting moves the application to new infrastructure with minimal change, which is fast and cheap but keeps the old code. Replatforming adjusts it to run on managed services such as a managed database. Refactoring restructures the code and splits it into services where that helps. Rebuilding writes a new system and migrates the data.

We choose by looking at what hurts. If the pain is hosting cost or unsupported servers, rehosting may be enough. If the pain is that nothing can be changed, the code needs to be understood and tested before any move. If the business rules are mostly obsolete, a rebuild beats carrying them forward.

The assessment phase ends with a written comparison of cost ranges, timelines and risk for each path. We often recommend a mix: rehost first to stabilize, then replace modules in order of business value. That order matters, because it puts the safe wins ahead of the risky ones.

We avoid the big-bang weekend. We use the strangler approach: a routing layer sits in front of the old system, and individual features are moved to the new system one at a time. Users see one application. Behind it, traffic shifts gradually, and each step can be switched back if something is wrong.

Data is the real risk. We build migration scripts that run repeatedly, then rehearse them on copies of production data until the reconciliation report shows matching totals, counts and key relationships. Edge cases surface in rehearsal, not on go-live day. For a period, old and new run in parallel and results are compared line by line.

Before any code moves, we write automated tests that capture what the old system does today, including its quirks. Those tests become the contract the new code must meet. A typical staged programme runs three to nine months, depending on the number of modules and the quality of the existing data.

Modernization is the moment to settle where the system lives. Many legacy applications hold personal or financial data, so we check the Personal Data Protection Law from SDAIA: where data is stored, who can reach it, how long it is kept and how a data subject's request is handled. If the application serves a regulated entity, we align the design with the NCA Essential Cybersecurity Controls and, for cloud use, the CST cloud computing framework.

In-Kingdom hosting is often a requirement or a customer expectation. We design for it from the start, using local cloud regions or private hosting, so you do not face a second migration later.

If the system issues invoices, we also check it against ZATCA e-invoicing requirements. An old billing module that cannot meet them is usually the first candidate for replacement, and we plan the order of work around that deadline.