Digital Modernization in Saudi Arabia: Which Systems to Keep, Extend, Replace and Retire

Digital Modernization in Saudi Arabia: Which Systems to Keep, Extend, Replace and Retire

Few organisations decide to defer modernization. Many defer it without a decision — one budget cycle after another — until a simple change takes a quarter and nobody left can explain how a core system works.

The way out is not one decision about "modernization". It is a separate verdict for each system. The matrix below gives you four verdicts, the conditions under which each may apply, and an indicator that helps make the cost of waiting visible before it grows.

A legacy system triage

AY prepared this triage for this guide, and it is set out here for you to use yourself. These programmes can stall when a single verdict is applied — "replace everything" or "keep everything and integrate" — to an estate that needs four different ones. Triage each system on its own:

The four verdicts are common options rather than an exhaustive taxonomy. If a system needs a fifth — consolidation into another system, for instance — add it and record why.

Two rules help make the triage usable. First, no system should receive a verdict without a named owner who agrees to it; a verdict nobody owns remains a recommendation rather than a decision and may not be executed. Second, Extend may be appropriate in more cases than expected, but it is also vulnerable to quietly becoming permanent — which is why it should carry a written review date in the triage document.

Frequency alone does not choose the first system. Start by identifying what is not discretionary: an applicable regulatory deadline, an active security exposure, a continuity risk, a critical system no longer supported by its vendor, or a binding contractual obligation. Urgency and interim mitigation for these are set with the risk owner, not by a general rule.

Then look at dependencies and what can feasibly be sequenced — a prerequisite may need an interface or an interim control rather than immediate full replacement. Only then compare the discretionary improvements on business criticality and customer impact, frequency and severity or value per occurrence, credible whole-life cost and benefit, feasibility and data readiness, and dependencies, team capacity and reversibility.

A frequent minor inconvenience does not automatically outrank a rare severe safety or compliance exposure. Explain the trade-off rather than reducing it to a score.

The Deferral Cost Indicator

A Replace verdict should prompt the same question: what happens if we wait another year? The answer may be "nothing immediate" — potentially true, but incomplete — because costs can accumulate in six places that may not appear directly on an income statement:

What you do with this: fill the third column with your own figures for one system — the one you have deferred longest. You will not get a precise number, and you do not need one. You need a figure that can be compared with the cost of acting, a comparison that deferral decisions may otherwise miss.

The signs that settle a verdict

Many systems can be placed in one of the four categories. The harder cases sit between Extend and Replace, and four signs can help distinguish them:

• A simple change takes more than a few weeks. That may indicate a structural constraint rather than a temporary resourcing issue, and adding developers alone may not resolve it.
• The same figure differs between two reports. The system may no longer be operating as a reliable single source, and an interface layer alone may not resolve the underlying inconsistency.
• No one can explain a core rule without reading the code. Knowledge may have left the organisation; extending the system without rebuilding that understanding can increase uncertainty.
• An integration request is answered with "we export a file at night". The system may not support the timeliness or integration the current process requires.

What you do with this: two or more of these signs should trigger a structured review for Replace. One sign may justify Extend with a review date. Treat this as an initial screen, not a final verdict.

When a requirement decides the verdict for you

Three requirement-related checks may materially influence a Replace verdict, depending on which requirements apply and whether the system can be reconfigured. Check them before spending time on the other criteria:

It cannot produce an adequate audit trail. If records can be altered inside the application without a tamper-evident log, the organisation may find it harder to evidence compliance with applicable controls, regardless of the written policy around the system.

It cannot restrict access below the screen. If everyone who can view the screen can see all of its data, access controls may be too broad for the applicable requirements, and an interface layer alone may not resolve weaknesses in the underlying data model.

It cannot isolate one person's records. If you cannot find the personal data held about an individual and act on an applicable request within the required period, the system may make compliance harder to evidence. That is a triage concern, not merely a technical note.

Where a failed check means the system has to be rebuilt rather than reconfigured, custom software development is the scope that gets priced. What you do with this: run these three checks first, on your two most data-heavy systems. They are quick initial checks, and a failure on any one of them should materially influence the verdict before you analyse the remaining factors.

Hosting follows the same logic in reverse, and the migration layer itself is covered in cloud and IT infrastructure: classify your data before you choose the migration destination, not after choosing a provider. Classification helps determine any applicable destination constraints, and reversing the order may lead to avoidable rework or a second migration. The full authority map sits in its own guide.

Sequencing after the triage

A triage produces a list of verdicts. Turning it into a plan takes three ordering rules and one batch rule:

1. Dependency first. A system that others read from may need to move before the systems that read from it; otherwise, you may migrate the same data twice.
2. Duplication second. Executing a Retire verdict early can reduce work in later phases.
3. Knowledge third. Where the person who understands a system is leaving or already gone, consider moving it earlier than its business priority alone would suggest, because the knowledge window may be closing.

A useful batch rule is to take one process end to end where feasible, rather than partially migrating several systems at once. A partially migrated system holds data in two places, which adds reconciliation work and widens the window in which the two can diverge.

That does not make parallel running something to avoid at all costs — it is often the safest way to cut over, because it preserves a fallback. What matters is that it is planned, time-bounded and reconciled, with agreed criteria for going live and for rolling back, rather than continuing by default because no one set an end to it.

What you do with this: order your triage list by these three rules and mark the first batch. If the first batch contains more than one process, review whether its scope is too large.

What stops a triage from being used

It was produced by a provider and never adopted internally. An assessment your team did not participate in reads as an opinion. What you do: have your internal owners review and approve each verdict before the document is finalised.

The Extend verdicts have no review dates. Without a date, an interim interface layer may become a permanent part of the architecture. What you do: put the date in the document, and put the review in a calendar owned by a person.

The Retire work went unfunded. Retirement is the verdict with no visible new capability, so it is exposed to being cut first — while retiring a system that others still depend on can also reduce the work in later phases. What you do: fund retirement inside the phase that benefits from it, not as its own business case.

The adjacent decisions, and where they are made

• What am I buying, and what sets its price? The digital transformation services guide.
• Who decides what once the change lands? The digital operating model guide.
• How do I evaluate and compare transformation companies? The guide to choosing a transformation company.
• Do I build this capability in-house or buy it? The guide to choosing a transformation provider.
• How do I get the replacement approved and funded? The transformation business case guide.

How AY works

In modernization work, the order we recommend and work to is: inventory the systems and what reads from each, map the dependencies because that is what sets the sequence, assign a verdict per system with a named owner, and treat retirement as work with its own requirements rather than an administrative step.

The scope and outputs of any assessment are agreed per engagement. Examples are in our work, and the scope is set out in enterprise digital transformation.

This article is not a substitute for regulatory review: which requirements apply to a specific organisation depends on its activity and its data.

Next step

Triage five systems this week. Choose them by the constraints set out above — anything under an applicable deadline, carrying a security or continuity exposure, or running unsupported — and only then by business value. Give each one a verdict, a named owner, and a review date where the verdict is Extend. This initial triage is often suitable for one focused session and may not require anyone outside your organisation.

If you cannot assign verdicts because the dependencies are undocumented, that is the point at which involving an outside party becomes useful. Talk to us about whether an assessment fits your case and what it would cover — the scope and outputs of any assessment are agreed before it starts rather than assumed in advance.