The cloud practice
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
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.
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
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 | What it means | When it is the right call |
|---|---|---|
| Leave it | The application stays where it is, and comes off the programme | 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. |
| Retire | It is switched off, with its data archived to whatever the retention obligation actually requires | 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. |
| Rehost | Same application, new infrastructure. Minimal change | 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. |
| Replatform | Same application, adapted to managed services underneath it | 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. |
| Rewrite | The application is rebuilt | 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
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.
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 honest 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
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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
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.
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.
Readiness
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:
Questions
Common question
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.
Common question
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
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 honest observation that the last ten per cent of an estate routinely takes as long as the first sixty.
Common question
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
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
Moving data between platforms, which is a different discipline from moving applications between hosting models.
Technical guideThe classification question this page treats as an input, worked through in full for telemetry.
PlatformWhere most replatformed workloads land, and what running one actually involves afterwards.
PracticeA named operator for year three, on a scope written down before day one.
Explore related solutions
Next step
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 info@interkey.com.saTawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia