- Strategy
- Leave it
- What it means
- The application stays where it is, and comes off the programme
- When it is the right call
- Stable, low-change, meets its obligations, and nobody is waiting on it. This is a legitimate and under-used outcome: an application nobody needs to change gains nothing from moving and carries all of the migration risk.
The cloud practice
Cloud migration in Saudi Arabia
A cloud migration is not one decision. It is one decision per application, taken with different information each time, and the programmes that go badly are the ones that took it once and applied it to everything.
In short
Enterprise architecture, applied one workload at a time
Interkey works on enterprise architecture, cloud strategy and migration, and application modernisation for organisations in Saudi Arabia. In practice that means taking an estate somebody has been running for years and deciding, application by application, what should move, what should be rebuilt, what should be retired, and what is fine exactly where it is.
The output of the first phase is not a migration plan. It is an inventory with a decision and a reason attached to every entry, including the entries whose decision is “no change”. That document is what makes the rest of the programme arguable in a way a target-state diagram never is.
Read more
Two neighbouring questions belong to other pages and are handed over rather than answered twice. Moving data between database platforms is database migration, a different discipline with a different risk profile. Running containers once you are there is the container platform. This page is about deciding where applications should live and getting them there.
Per workload
The five answers, and when each is correct
Every application in the inventory ends up in one of these rows. The proportions are the useful part: a programme where almost everything is a rewrite has not been assessed, and neither has one where everything is a lift-and-shift.
- Strategy
- Retire
- What it means
- It is switched off, with its data archived to whatever the retention obligation actually requires
- When it is the right call
- More common than expected. Estates accumulate systems with a handful of users and a successor that already exists. Every retirement removes work from every later phase, so this row is worth finding early.
- Strategy
- Rehost
- What it means
- Same application, new infrastructure. Minimal change
- When it is the right call
- A hard deadline — a data-centre exit, an expiring contract — or a workload that is genuinely fine and simply has nowhere to live. Fast and low-risk, and it inherits every existing inefficiency rather than fixing any of them. That trade is fine as long as it is made deliberately.
- Strategy
- Replatform
- What it means
- Same application, adapted to managed services underneath it
- When it is the right call
- The default for most workloads worth moving. Managed databases, managed queues, container hosting: real operational gain, bounded change, no rewrite. Most of a well-run programme lives in this row.
- Strategy
- Rewrite
- What it means
- The application is rebuilt
- When it is the right call
- Only where the current implementation is itself the constraint on the business, and only with the appetite for a project rather than a migration. A rewrite chosen because the code is unfashionable is a rewrite that will be abandoned at sixty per cent.
The constraint
Residency is an input, not a phase
Classify first, or re-plan later
In this market the question of where a workload may run is answered by its data classification, and it is answered before the strategy table above can be filled in. A programme that classifies late does not discover a small problem; it discovers that several completed decisions were taken against the wrong constraint.
The practical shape of it: some classes can sit in a hyperscaler region outside the Kingdom, some require in-Kingdom infrastructure, and some cannot leave systems the organisation operates itself. Those three answers point at three different target architectures, and they routinely apply to different applications inside the same programme — which is why an estate-wide “we are moving to the cloud” is a budget statement rather than an architecture.
Read more
Announced regions deserve particular care. Hyperscaler regions inside Saudi Arabia have been announced across the industry, and announced is not live. A migration plan that depends on a region opening on schedule has taken on a delivery risk it does not control, and the right thing to do is name it in the plan rather than assume it away. The same reasoning, applied to telemetry rather than to applications, is worked through in the observability residency guide.
Sequence
How a programme is actually sequenced
Five phases. The first two produce documents rather than movement, and skipping them is the single most reliable predictor of a programme that stalls in year two.
-
Inventory and classify
Every application, its dependencies, its data classification and its owner. Estates are almost always larger than the architecture diagram says, and the difference is where the surprises live.
-
Decide per workload
The strategy table applied entry by entry, with the reason recorded. This document is the deliverable of the assessment, and it is what later arguments are settled against.
-
Land the foundations
Networking, identity, logging and the landing-zone structure — built once, before the first workload rather than around the tenth. Retrofitting an account structure to a populated estate is its own project.
-
Move in dependency order
Starting with something real but recoverable. A first migration chosen for how little it matters teaches you nothing; one chosen for how visible it is teaches you everything at the worst possible moment.
-
Operate and decommission
Somebody owns the new environment, and the old one is actually switched off. A programme that leaves both running has doubled its cost and delivered a migration on paper only.
Costs
Four costs that are consistently missed
None of these is hidden. They are simply outside the line item the business case was built from, and each of them has ended a programme.
Running both estates at once
Migration is not instantaneous, and during it you are paying for the old environment and the new one. The overlap is a real budget line, and the way to shrink it is decommissioning discipline rather than optimism about the schedule.
Moving data out again
Getting data in is cheap and getting it out is not. This matters most for the workloads people assume are reversible: check the egress cost of the exit before the entry, because it is the number that decides whether a decision is actually reversible.
The operating model
A team that ran servers now runs services, and that is a different job with different skills. The training and hiring are part of the programme cost whether or not anyone put them in the case.
The rehosted inefficiency
An application sized for a machine you already owned becomes an application billed by the hour. Lift-and-shift without right-sizing frequently costs more after the move than before it, and the fix is a resizing pass rather than a different provider.
Failure modes
How these programmes actually fail
Rarely at the technical step. The migrations themselves are well-understood engineering, and the industry has been doing them for a decade. The failures are structural, and there are three of them.
The programme never finishes. The straightforward eighty per cent moves, the difficult remainder does not, and the organisation ends up permanently operating two estates with a network link between them — every cost of the migration, none of the consolidation benefit. The defence is to schedule the hard workloads early enough that abandoning them is still a decision someone has to take rather than a thing that quietly happens.
Read more
The business case was a hosting comparison. Cases built on infrastructure cost alone tend not to survive contact with the bill, because the gains that do materialise are usually about deployment speed, elasticity and operational overhead. Those are real and they are worth buying — but a programme sold on a number it will not hit loses its sponsor at the moment it needs one most.
Nobody owned the destination. Migration teams are temporary and estates are permanent. Where no one owned the new environment’s standards, cost and access, the estate drifts into exactly the state the programme was meant to escape, one exception at a time. This is an observability and operations problem more than a migration one, and it is best solved before the first workload lands.
When this is the wrong fit: one application, no integrations, no residency constraint and no shared data. That is a deployment rather than a programme, and the team that already operates the application will do it faster than anyone brought in to help. What makes this work worth buying is the estate: the dependencies nobody has drawn, and the order they have to move in.
Relatedobservability and operations
Readiness
What has to exist before the first workload moves
None of this is migration work, and all of it decides whether the migration work succeeds. A programme that starts without these is not moving faster; it is deferring the same decisions to a point where they are more expensive:
- A data classification per application, agreed with whoever is accountable for it — not an estate-wide assumption
- A named owner for the destination environment: its standards, its cost and who may change it
- A landing-zone structure — accounts, networking, identity, logging — built before the first workload rather than around the tenth
- A decommissioning commitment per workload, with a date, so the overlap period is bounded
- An agreed definition of done for a migrated application: not “it runs” but “it is monitored, supported and the old one is off”
- The egress cost of leaving again, checked for anything whose reversibility is part of the business case
Questions
Questions buyers actually ask
Common question
Can everything go to the cloud?
Technically most things can, and that is not the question worth asking. The one that matters is which workloads gain something by moving. Data classification rules some out entirely, a licence model makes others uneconomic, and a stable system nobody is changing gains nothing at all. A useful assessment ends with a list of applications staying put, and an assessment that does not has probably not looked hard. Where the answer is to containerise rather than lift and shift, the container platform questions cover what that commits the team to afterwards.
Relatedcontainer platform questions
Common question
Should we pick one provider or several?
One, for most organisations, unless a specific requirement forces otherwise. Multi-cloud sounds like leverage and is bought as insurance, but it doubles the operational surface, the skills requirement and the identity model, and the portability it promises is rarely exercised. Where a second provider is genuinely required — a residency constraint, a mandated arrangement — it is a decision with a named reason rather than a default posture.
Common question
How long does a migration take?
Longer than the plan, for a reason worth knowing in advance: the schedule is usually set by other people’s change windows, dependency chains and approvals rather than by engineering effort. What can be given early is a realistic first phase, and the observation that the last ten per cent of an estate routinely takes as long as the first sixty.
Common question
Do we have to modernise the application to move it?
No, and conflating the two is a common way to make both harder. Rehosting moves an application unchanged; modernisation is separate work with its own justification. Doing them together is sometimes efficient and sometimes produces a programme where neither can be finished or judged independently. Deciding deliberately is the point.
Common question
What about the databases?
They are the part that deserves its own plan, and they have one: see database migration for the mechanics and data platform modernisation for the platform decision. Moving an application to new infrastructure and changing its database engine at the same time is two migrations sold as one, and it is worth being explicit about which of them you are actually doing.
From the insights library
The neighbouring decisions
Practice
Database migration
Moving data between platforms, which is a different discipline from moving applications between hosting models.
Technical guideData residency in Saudi Arabia
The classification question this page treats as an input, worked through in full for telemetry.
PlatformEnterprise container platform
Where most replatformed workloads land, and what running one actually involves afterwards.
PracticeOperating the estate after the move
A named operator for year three, on a scope written down before day one.
Explore related solutions
Next step
Start with the inventory, not the target
Describe the estate and what is forcing the timing — a contract, a data-centre exit, a system nobody can change. The first deliverable is a decision per workload, including the ones that stay.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia