Cloud Migration in the Gulf: Choosing and Moving Safely

Why the question is being asked now

Most of the cloud migration conversations we have in Dubai and Riyadh do not start with a strategy document. They start with a forcing event: a data centre contract coming up for renewal, a server that failed and took two days to restore, an auditor asking uncomfortable questions about access, or a new product the current infrastructure plainly cannot carry. That is a healthy way to start — there is a real problem to solve rather than an initiative to justify.

It also means the decision arrives under time pressure, and time pressure produces the two classic failures. The first is moving everything as-is because it is quick, then discovering the running costs exceed what the hardware ever cost. The second is deciding that since you are moving anyway, everything should be rewritten as microservices — a project that consumes a year and delivers the features the business already had.

The useful middle ground is unglamorous. Build a sound foundation, move most things with minimal change, rewrite the small number of components where the rewrite pays for itself, and instrument the cost from day one.

Regions and data residency in the UAE and Saudi Arabia

This is the first question to settle, because it can eliminate providers before any technical comparison matters. All three hyperscalers have invested in the Gulf. AWS operates Middle East regions including Bahrain and the UAE. Microsoft Azure operates UAE North and UAE Central. Google Cloud operates regions in the wider Middle East including Dammam in Saudi Arabia and Doha in Qatar. All three continue to announce new regions and expand existing ones.

We deliberately will not tell you which regions are live for which service today, and you should be sceptical of any consultancy that recites a list from memory. Footprints change, and service availability varies within a region: a region existing is not the same as the specific managed database, GPU family or analytics service you need being available in it. Confirm against each provider's current published region and service tables at the point of decision, for the exact services in your architecture.

In the UAE, the federal personal data protection framework sits alongside separate regimes in the financial free zones such as DIFC and ADGM, and sector regulators add their own expectations. In Saudi Arabia, national data governance rules, the regulatory framework for cloud computing, and sector-specific requirements — financial services being the obvious example — all shape where data may sit and under what conditions it may move. These frameworks are updated periodically. We treat them the same way we treat ZATCA e-invoicing requirements: confirmed against current published guidance for each engagement, never assumed from last year's project.

AWS vs Azure vs Google Cloud: an honest comparison

Here is the uncomfortable truth: for the overwhelming majority of business applications, all three platforms will do the job, and the difference in outcome between them is smaller than the difference between a well-run migration and a badly-run one. The comparison below is about fit and friction, not about which is "best".

Two practical notes. If your organisation runs .NET, SQL Server and Microsoft 365 — which describes a large share of the enterprises we work with across the UAE and Saudi Arabia — Azure is the path of least resistance, and choosing otherwise should be a considered decision rather than a preference. If you have no strong incumbent, choose the platform your team can operate under stress, not the one that scored best in a feature matrix. Our own AWS work and Azure work both exist because clients arrived with different starting points, not because we ranked one above the other.

Rehost, replatform, refactor: choosing per workload

The strategy decision should be made application by application, not for the estate as a whole. Three options cover nearly everything worth doing.

Rehost — lift and shift the virtual machine roughly as it is. Fast, low-risk, and it buys you an exit from the data centre, but it carries the old sizing, patching burden and architecture with it. The right answer for stable, low-change systems that simply need somewhere to live.

Replatform — keep the application but swap the infrastructure underneath for managed equivalents: a self-managed database becomes a managed database, a file share becomes object storage, a VM-hosted queue becomes a managed queue. This is where most of the durable operational saving lives, and it is usually days of work per application rather than months. If you only do one thing beyond rehosting, do this.

Refactor — meaningfully rewrite. Justified when the application is a genuine constraint: it cannot scale for a known demand curve, it cannot be changed safely, or it blocks a product you intend to sell. Refactoring is expensive and belongs to the few systems where the return is specific and nameable.

The strategies mix. A typical estate we assess is mostly rehosted, replatformed in a meaningful minority, refactored in a handful, and — this one is often forgotten — retired outright. Every migration we have run has surfaced servers doing nothing anyone can account for. Finding them is one of the quieter benefits of the exercise.

Landing zones and the security baseline

The landing zone is the foundation everything lands on: account or subscription structure, network layout and segmentation, identity model, centralised logging, encryption defaults, backup policy, guardrails and a tagging standard. It is boring, it delays the first visible win by a few weeks, and skipping it is the most expensive shortcut available in a cloud programme — retrofitting account separation and tagging onto a live estate means touching everything twice.

A baseline we would consider the minimum defensible position, regardless of provider:

• Separate accounts or subscriptions for production, non-production and shared services — a blast radius boundary you cannot achieve with tags alone.
• Single sign-on from your corporate identity provider, with no long-lived static keys and administrative access granted just-in-time.
• Multi-factor authentication enforced everywhere, without exception for senior staff.
• Encryption at rest and in transit by default, with a documented key management approach and a stated position on who can access keys.
• Centralised, tamper-resistant logging in an account the workload teams cannot write to.
• Backups tested by restoring them on a schedule — an untested backup is a belief, not a control.
• Infrastructure defined in code, so the environment can be reviewed, diffed and rebuilt rather than remembered.
• A tagging standard applied from the first resource: owner, environment, cost centre, data classification.

That last point is not administrative tidiness. Tagging is what makes the cost conversation in the next section possible at all. Untagged estates cannot be optimised, because nobody can say who owns the spend.

Cost control and the classic overspend traps

Cloud bills rarely surprise people because of one large mistake. They surprise people because of a dozen small defaults that nobody revisited. The traps we see most often:

• Sizing copied from the data centre. On-premises servers were sized for a five-year peak. Cloud instances should be sized for current load and changed when that changes. This alone often accounts for much of the early overspend.
• Non-production running around the clock. Development and test environments used during office hours but billed for all 168 of them. Scheduled shutdown is close to free money.
• Egress charges nobody modelled. Data leaving the provider, or crossing regions, is charged. Chatty cross-region architectures and analytics pipelines that repeatedly pull data out are the usual culprits.
• Storage that only grows. Snapshots, old backups and orphaned disks left behind by deleted machines. Lifecycle policies from day one, not after the first bad invoice.
• Commitments made too early, or never. Savings plans and reserved instances are real discounts on a stable baseline, but committing before your steady state is known locks in the wrong shape.
• No cost owner. When cost belongs to everyone it belongs to no-one. A named owner per tagged workload, reviewed monthly, does more than any tool.

Set a budget alert before the first workload lands, and treat cost as an engineering metric reviewed alongside latency and error rate. Building the habit early is far cheaper than a remediation project later — the same discipline we apply when we build SaaS platforms, where infrastructure cost per tenant is a margin question rather than an IT question.

What you actually gain

Stripped of the marketing, the benefits worth planning for are these:

• Recovery you can prove. Restoring across availability zones on the day something fails, instead of hoping the tape and the courier both cooperate.
• Capacity on demand. Ramadan peaks, a campaign, a new market — handled by changing a number rather than raising a purchase order.
• Less undifferentiated work. Managed services remove patching, replication and failover chores from a small team that had better things to do.
• Costs that follow usage. Capital expenditure becomes operating expenditure that can be attributed to the products earning the revenue.
• Access to capability you would not build. Managed analytics and machine learning services make projects viable that a self-hosted estate would never justify — see our data analytics and machine learning work.
• Faster delivery. Environments in minutes rather than weeks changes how often teams are willing to ship.

Every one of those is conditional on the work described above. None of them arrive because a VM changed address.

How Inovsion helps

We are a software engineering company that runs what it builds. We are not reselling capacity and we are not incentivised to make your bill larger.

A typical engagement starts with a short assessment — usually two to four weeks — where we inventory the estate, map the dependencies that are not written down anywhere, classify the data against the residency position that actually applies to you, and produce a per-application recommendation of rehost, replatform, refactor or retire with a cost model attached to each. You get that as a document you own, and you can execute it with us or with anyone else.

From there we build the landing zone in infrastructure-as-code on AWS or Azure, migrate in waves starting with something low-risk enough to learn on, and hand over an environment your team can operate — runbooks, dashboards, budget alerts and the code that produced it all.

What we bring beyond the platform mechanics is the application side. Migrating a system is easier when the people doing it can also read and change the application: our teams build custom applications, ERP platforms and AI systems across the UAE, Saudi Arabia and India. That background matters in the awkward cases — the legacy component nobody wants to touch, the licensing constraint, the integration that only works because of an undocumented assumption about the network.

We have also delivered work where the regulatory dimension was the hard part rather than the infrastructure. Our ERP-integrated ZATCA e-invoicing solution covers EGS onboarding, integration and automated compliance validation across a broad range of ERPs, and our portfolio includes IoT-connected platforms such as ClueMaster and consumer products such as FameKeeda and Rising Walls — systems where deployment architecture and cost per transaction were design constraints rather than afterthoughts. There is more on our work page.