The systems that are hardest to replace are the ones the business cannot stop using while you replace them. That is the actual problem in application modernization: not choosing a target architecture, but sequencing the move so that revenue, reporting and regulatory obligations keep working on every day of a migration that will take longer than anyone wants it to. TrustAngle advises on that sequencing independently - we are not the implementation vendor whose delivery plan sets the pace, which is why our recommendation can include "not yet" and "not this system".
The systems hardest to replace are the ones the business cannot stop using while you replace them. Almost every failure below is a sequencing failure rather than a technical one.
Decades of undocumented business rules live inside the code of a core system, and a meaningful share of them are the only implementation of a policy nobody wrote down elsewhere. A replacement scoped from the documentation rather than from the running behaviour ships without them, and finds out which ones mattered in production.
Modernizing the technically interesting component first is how programmes spend their political capital before touching anything the business notices. Sequencing should follow business risk and dependency order - what breaks what - rather than diagram elegance.
In a core-system replacement the data is usually the longest pole and the most common cause of a delayed cutover: reconciliation, historical depth, records under a statutory retention obligation, and the reality that the old system's data quality was load-bearing for nobody until it had to move.
A cutover with no rehearsed rollback is a one-way door taken late on a Friday night. The plan has to include the path back, and the path back has to have been exercised rather than documented.
There is a widely used taxonomy for what you can do with a legacy application - retain it, retire it, rehost it, replatform it, rearchitect or refactor it, or replace it with a packaged product. Most real estates need a different answer per application, and the value of an assessment is in assigning the right one to each rather than applying one policy to all.
The cheapest modernization is the one you do not do. Systems with a known end date, and systems whose function has quietly moved elsewhere, should be identified before anyone budgets to modernize them. This is routinely the largest single saving in a programme.
Moving a workload with minimal change buys infrastructure benefits and defers the application problem. It is worth being honest about what that is: a step, not an outcome. It is the right first step when the constraint is the data centre, and the wrong one when the constraint is the application itself.
Changing the internal structure while preserving behaviour. The incremental variant - standing up new functionality alongside the old system and routing traffic across piece by piece until the old system is unused - is the pattern that makes "without stopping the business" achievable, and it is also the one that demands the most discipline about what "done" means for each slice.
Sometimes the right modernization of a bespoke system is to stop maintaining bespoke software at all. That is a selection decision with its own method, and it should be evaluated against requirements rather than assumed because the incumbent system is old.
The assessment is scoped against what is actually deployed today, including the systems that never made it onto the architecture diagram, and it ends in a sequenced plan rather than a findings dump.
What exists, what each system is actually used for, who depends on it, and what happens on the day it is unavailable. Shadow systems and spreadsheets that carry a real process count as applications, and they are usually the ones nobody has recorded.
Platform support status, the availability of people who can still work on the system, the integration surface, and whether the system can be changed at all at acceptable risk. A system nobody dares change is already a business constraint, whatever its uptime says.
Where each dataset originates, what condition it is in, what must migrate as against what must be retained and archived, and which records carry a statutory retention or residency obligation. This is assessed as its own workstream because it usually governs the cutover date.
Which systems must move together, which can move independently, and the order that keeps the business running throughout. This is the output the rest of the programme is planned from, and it is the deliverable most often missing when a programme stalls.
A target architecture, an option assigned per application, and a phased plan with a defined rollback at each phase rather than a single rollback at the end.
Modernization frequently means moving data as well as code, and in the Kingdom that turns an infrastructure decision into a compliance one. Where a dataset is permitted to live follows from how it is classified; personal data carries obligations under the Personal Data Protection Law, enforced by the Saudi Data and Artificial Intelligence Authority; and organisations subject to sector supervision carry their regulator's requirements on top of that. Replication targets, backup destinations and support access from outside the Kingdom are all in scope, and they are constraints on the migration plan rather than checks performed after it. A programme that discovers a residency constraint after choosing a target has to redo the choice.
A core system is on an unsupported platform, or the people who can maintain it are retiring or already gone. Change requests that should take days take quarters. An acquisition or restructuring has left two systems doing one job. A regulatory or reporting obligation cannot be met by the current architecture at acceptable cost.
The system is old but stable, cheap to run, and not blocking anything the business wants to do - age alone is not a reason. The real constraint is a process rather than the software. Or a replacement decision has already been taken and what you need is implementation oversight rather than an assessment. We will say so instead of opening an engagement.
We start with the business outcome you need, not a product shortlist. That means sitting with the people who own the outcome, mapping current constraints, and agreeing what "solved" actually looks like before any vendor conversation starts.
We score realistic options against your own criteria - cost, fit, implementation risk, local support - without a reseller margin sitting behind the answer. Where a vendor in our partner network is not the best fit, we say so.
You receive a written recommendation with the trade-offs made explicit, not a single option presented as the only one. Sign-off is yours; the case for it is ours to make clearly.
Once a direction is chosen, we oversee delivery and integration with your existing systems, so the handover from decision to working system stays our responsibility, not yours to chase.
The relationship does not end at go-live. We stay engaged as an advisor for the decisions that follow - scaling, renewals, the next system that needs to talk to this one.
An application inventory with business criticality. A condition and supportability assessment. A data migration and retention assessment. A dependency and sequencing map. A target architecture with an option assigned per application. And a phased plan with a defined rollback at each phase.
Driven by the number of applications in scope, how much of the behaviour is undocumented, the depth and condition of the data, and how many integrations cross the boundary. We give a timeline specific to your estate after the inventory stage, rather than a headline figure that describes somebody else's estate.
The assessment is a standalone engagement with a defined output - you can take the plan and execute it with whoever you choose, including entirely without us. Oversight through delivery is a separate and optional engagement, deliberately so: an advisor whose fee depends on a long implementation is not an advisor who will recommend a shorter one. Scope and commercial terms are agreed in writing before either starts.
Organisations running a core system their sector regulator increasingly asks questions about. CIOs whose change backlog is constrained by one system rather than by capacity. Groups carrying duplicate systems after a merger. Institutions where the people who understand the core system are a retirement risk. And entities in banking, government and telecommunications whose systems predate the obligations now placed on them.
That is the whole design goal. Incremental approaches that stand new capability alongside the old system and migrate traffic progressively exist precisely so the business keeps running - but they demand more discipline about slice boundaries, not less, and a programme that cannot define a slice cannot use them.
Usually not. Most estates need a different answer per application, and identifying the ones to retain or retire outright is often the largest single saving in the programme.
It is assessed separately from the migration: what must move, what must be retained and archived, and what carries a statutory retention obligation. In core-system replacements this is routinely the longest work package and the one most often underestimated.
The assessment is deliberately separable. You can execute the plan with any implementation partner, and the recommendation is written to be executable by someone other than us - which is also what makes it readable by someone other than us.
Residency is a constraint on the plan from the start - including replication targets, backups and support access from outside the Kingdom - not a check performed after a target has been chosen.
Then that is the recommendation. Sequencing is as much about what to leave alone as about what to move, and a plan that moves everything is usually a plan nobody finishes.
If a core system is holding the business back and the replacement keeps being deferred, the useful first step is an inventory and a sequence, not a target architecture. Talk to us about the estate you are carrying and we will tell you which parts of it are worth moving first, and which are worth leaving alone.