Cloud

Cloud Migration to AWS in the UAE: Cost, Steps, and What to Know

SKIMBOX Team

Cloud migration in the UAE is usage-based, so there is no fixed price, but a readiness assessment and plan starts from around AED 15,000. Here are the migration strategies, the steps, the real cost drivers, and the UAE data-residency rules that actually matter.

Cloud Migration to AWS in the UAE: Cost, Steps, and What to Know

Cloud migration in the UAE gets pitched as a single decision with a single price, and it is neither. It is a programme of choices, application by application, about what to move, how much to change it, and what to switch off entirely. And the cost is not one number, because the ongoing cloud bill depends on what you actually use. Treating it as a one-off purchase is how migrations go over budget and under-deliver.

Because the cloud bill is usage-based, there is no fixed price to quote, but the migration project itself can be scoped: a cloud readiness assessment and migration plan starts from around AED 15,000, and execution scales from there. This guide covers the migration strategies, the real steps, where the cost actually goes, and the UAE data-residency rules that genuinely matter, as opposed to the ones people assume.

We provide cloud migration services in Dubai for businesses across the UAE, delivered by our Dubai and Bengaluru teams [6], so this is the practical version of the conversation we have before anything moves.

What does cloud migration cost in the UAE?

Cloud migration cost in the UAE splits into two parts: a migration project you can scope and price, and an ongoing cloud bill that is usage-based. Separating them is the whole point.

The ongoing cloud bill is usage-based. You pay for compute, storage, data transfer, and managed services as you consume them, so it scales with your workloads rather than being a fixed figure. AWS reports an average of around 31 percent infrastructure savings for legacy applications migrated through its Migration Acceleration Program (MAP), but that is an average across optimised migrations, not a guarantee, and an un-optimised lift can cost the same or more than what you had [3].

The migration project is what can be scoped and priced. A cloud readiness assessment and migration plan starts from around AED 15,000, and the execution cost scales with how many applications move and how much they are re-engineered. Notably, even AWS does not publish a flat migration price, because it depends entirely on your portfolio, and it offers funding to offset assessment and foundation costs precisely because those phases are real work [3]. Final pricing depends on scope and is confirmed after an assessment.

The honest headline is that the cloud can be cheaper, but only with right-sizing and reservations. The move alone does not save money.

What are the 7 Rs of cloud migration?

The 7 Rs are AWS's seven migration strategies: Rehost, Replatform, Repurchase, Refactor, Retire, Retain, and Relocate. Not everything should be moved the same way, and some things should not be moved at all. AWS's migration strategies, the 7 Rs, are the menu you apply system by system [1]:

  • Rehost (lift and shift): move it as is, minimal changes. Fastest and lowest risk.
  • Replatform: move it, but swap a few pieces for managed cloud equivalents to cut admin work.
  • Repurchase: stop running it yourself and subscribe to a SaaS version instead.
  • Refactor: re-architect it to use cloud-native features for real gains. Most effort, applied selectively.
  • Retire: switch it off. An assessment routinely finds systems nobody needs any more.
  • Retain: leave it where it is for now, for compliance or because it is due to be replaced anyway.
  • Relocate: move infrastructure at the hypervisor level, without re-buying hardware or rewriting apps.

The mistake is picking one strategy for everything. Real portfolios use a mix: rehost the bulk for speed, replatform or repurchase where an easy managed or SaaS swap exists, refactor only the few systems where cloud-native gives a genuine edge, and retire or retain the rest. Deciding this per application is exactly what the assessment phase is for.

What are the steps of a cloud migration?

AWS frames a large migration in three phases, with a fourth, ongoing one after go-live [4]:

  1. Assess. A readiness assessment of your current systems, a business case, and a total cost of ownership analysis. This is where the plan and the wave grouping are decided.
  2. Mobilize. Build the foundation: a secure landing zone with baseline networking, identity, security guardrails, and account structure, then migrate a small first wave to prove the approach.
  3. Migrate and modernize. Move the rest at scale, in waves, using repeatable and automated processes rather than a single cutover.
  4. Operate and optimize. Once live, continuously right-size and cost-tune the workloads. This is where the savings are actually realised.

Two of these are the steps rushed migrations skip: the assessment at the start and the landing zone in mobilize. They are also the two that determine the whole project's cost, risk, and security, which is why cutting them to save time reliably costs more later.

What does the cloud actually cost to run?

The ongoing bill has four main drivers, and knowing them is how you avoid a surprise:

  • Compute: the servers, containers, or serverless functions you run.
  • Storage: including backups and snapshots.
  • Data transfer: especially egress, moving data out of the cloud or between regions.
  • Managed services: databases, AI tools, and monitoring, which cost more per unit but remove operational work.

Compute and storage are expected. Data egress is the one that surprises people, because it is easy to design an architecture that quietly moves a lot of data and produces a bill nobody predicted. Cloud providers charge for data leaving the cloud, and rates vary by region, so it is worth designing with data movement in mind and checking current transfer rates before committing to an architecture.

On the buying side, you can pay on-demand for maximum flexibility, or commit to Reserved Instances or Savings Plans for steady workloads in exchange for a substantial discount [5]. The discipline of tagging, budget alerts, shutting down idle non-production environments, right-sizing, and committing where it makes sense is called FinOps, and it should start before migration, because cost patterns are hard to reverse once workloads are at scale.

Do you have to keep your data in the UAE?

For most private businesses, no. There is no blanket legal requirement to keep all data inside the UAE, but sector rules and region choice still matter, so here is what actually applies.

The federal law governs transfers rather than banning them. The Personal Data Protection Law (PDPL), Federal Decree-Law No. 45 of 2021, regulates how personal data is handled and transferred rather than banning cross-border transfer, permitting it where there is adequate protection or appropriate safeguards [2]. Importantly, it also does not itself cover the DIFC and ADGM financial free zones, which have their own regimes, nor government, health, or banking and credit data, which sit under separate legislation [2].

The real exceptions are sector rules and government data. Financial institutions fall under Central Bank rules that treat cloud hosting of core activity as outsourcing, which typically requires prior non-objection from the Central Bank before proceeding. Health data sits under its own legislation. Classified government data has residency requirements, though that applies to government rather than a typical private business. Our PDPL compliance guide covers the data-protection side in more detail.

Where you run the workload is your choice, and it is a real one. AWS and Microsoft Azure both operate regions physically inside the UAE, AWS with its me-central-1 region and Azure with UAE North in Dubai and UAE Central in Abu Dhabi [7]. Google Cloud does not currently have a region inside the UAE; its nearest are in Qatar and Saudi Arabia. So for a workload that must run on infrastructure physically in the country, AWS and Azure are the two options today. AWS lets you choose the region your data sits in and does not move it out without instruction [2], which is a clean way to keep data local, but the compliance responsibility remains yours, not the provider's. Our best web hosting in the UAE guide covers the hosting-level version of this decision.

When is a business ready for cloud migration?

The clearest sign is a forcing event: hardware due for replacement, a data centre lease or hosting contract ending, or a workload your current servers cannot scale to. When one of those is on the calendar, a migration decision is coming whether you plan it or not, and planning it is cheaper.

Beyond a deadline, the readiness signs are practical:

  • A hardware refresh is due. Migrating instead of re-buying turns a large one-off spend into a usage-based cost.
  • Demand swings. Traffic that spikes by season or campaign suits cloud scaling far better than fixed servers sized for the peak.
  • Your team spends its week keeping servers alive instead of building anything that moves the business.
  • Weak disaster recovery. If one server room failure would stop the business, cloud regions and managed backups fix that faster than building a second site.

The honest flip side is that staying on-premise can be the right call. A stable, predictable workload running on paid-off hardware, software whose licensing blocks cloud hosting, or a system due for retirement within the year is often better left alone. That is exactly what the Retain and Retire strategies are for, and a good readiness assessment will say so rather than recommend migration for its own sake.

What are the most common cloud migration mistakes?

The most common cloud migration mistakes are planning failures: no assessment, no landing zone, no cost governance, and a big-bang cutover. Most overruns come from the same short list:

  • Lifting everything unchanged and never optimising, so you pay cloud prices for an on-premise design.
  • No cost governance until the bills arrive. FinOps set up after the fact is far harder.
  • Ignoring data-transfer costs in the architecture.
  • Under-estimating skills and change management. AWS treats people and skills as a first-class workstream, not an afterthought [4].
  • Migrating at scale with no landing zone, so security and cost problems are baked in.
  • A big-bang cutover instead of waves, which concentrates all the risk into one moment.
  • Dual-running with no sunset date, paying for both the old and new environments indefinitely.

Every one of these is a planning failure, not a technology failure, which is why the assessment and foundation phases earn their cost.

Real client stories

These are real situations from cloud work we have handled.

The lift that doubled the bill. A business moved its entire on-premise setup to the cloud unchanged, expecting to save money, and watched its bill come in higher than the hardware it replaced. Nothing had been right-sized, and over-provisioned servers ran around the clock. We right-sized the workloads, moved steady ones onto reservations, and shut down idle non-production environments, and the bill fell well below the original estimate. The lift had been the easy part. The optimisation was the point.

The egress surprise. A client's architecture copied large volumes of data between regions constantly, and the data-transfer charges quietly became one of their biggest line items. Nobody had modelled it at design time. We reworked where the data lived and how it moved, and the transfer cost dropped sharply. It was never a compute problem, which is exactly why it went unnoticed.

The migration with no foundation. A team had begun moving applications into a cloud account with no landing zone, no consistent identity setup, and no guardrails. It worked until it did not, and untangling the security and account structure afterwards took longer than building it properly would have. We paused, built the foundation, and migrated the rest in waves on top of it. The order of operations is not optional.

How SKIMBOX approaches cloud migration

Our cloud migration services run from Dubai, and we start with an assessment, not a server move, because the decisions that set a migration's cost and risk are made before anything is lifted. We work through your systems with the 7 Rs, retire what is dead, build a proper landing zone before migrating at scale, move in waves rather than a big bang, and set up cost governance from the start so the bill does not surprise you. We are honest about UAE data residency: no blanket rule for most businesses, real rules for regulated sectors, and a deliberate region choice either way.

A cloud readiness assessment and migration plan starts from around AED 15,000, with the ongoing cloud cost scaling to your actual usage.

See our cloud solutions services and cloud and AI services, or contact us to talk through your migration.

For related reading, see our guides on best web hosting in the UAE, PDPL compliance in the UAE, cybersecurity for small businesses in the UAE, and what an AI app costs to build in Dubai.

References

[1] AWS - What is a cloud migration strategy, the 7 Rs. aws.amazon.com/what-is/cloud-migration-strategy/

[2] AWS - United Arab Emirates data privacy and PDPL, region and data-residency controls. aws.amazon.com/compliance/uae_data_privacy/

[3] AWS - Migration Acceleration Program, infrastructure savings and funding. aws.amazon.com/migration-acceleration-program/

[4] AWS Prescriptive Guidance - Migration phases: assess, mobilize, migrate and modernize. docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/overview.html

[5] AWS - On-demand, Reserved Instances, and Savings Plans pricing. aws.amazon.com/savingsplans/compute-pricing/

[6] SKIMBOX - Internal experience delivering cloud migrations for UAE businesses, 2026. skimbox.co

[7] Microsoft Azure - Azure regions list, including UAE North and UAE Central. learn.microsoft.com/en-us/azure/reliability/regions-list

Frequently asked questions

  • How much does cloud migration cost in the UAE?

    There is no single price, because the ongoing cloud bill is usage-based: you pay for the compute, storage, and data transfer you actually use. What can be scoped is the migration project itself. A cloud readiness assessment and migration plan starts from around AED 15,000, and the execution cost scales with how many applications move and how much they are re-engineered. Even AWS does not publish a flat migration price, because it depends entirely on your systems. Final pricing depends on scope.

  • Is the cloud cheaper than on-premise?

    Sometimes, but not automatically. The cloud shifts spending from buying and maintaining hardware upfront to paying for usage over time, and AWS reports an average of around 31 percent infrastructure savings for legacy applications migrated through its program, though that is an average, not a guarantee. The catch is that lifting your existing setup to the cloud unchanged and never optimising it can cost the same or more. The savings come from right-sizing and using reservations, not from the move alone.

  • What are the 7 Rs of cloud migration?

    The 7 Rs are AWS's migration strategies: Rehost, meaning lift and shift as is; Replatform, moving with a few managed-service swaps; Repurchase, switching to a SaaS version; Refactor, re-architecting to use cloud-native features; Retire, switching off systems you no longer need; Retain, leaving some systems where they are for now; and Relocate, moving infrastructure at the hypervisor level. Most real migrations use a mix, rehosting the bulk for speed and refactoring only where it genuinely pays.

  • What is lift and shift?

    Lift and shift, also called rehosting, means moving an application to the cloud as it is, with minimal changes, so it runs on cloud infrastructure instead of your own servers. It is the fastest and lowest-risk way to exit a data centre, which makes it useful under a deadline like a hardware refresh or an expiring lease. The trade-off is that you do not get the full cloud-native benefit until you optimise afterwards, so lift and shift is often a first step, not the finish line.

  • Lift and shift or refactor: which should I choose?

    Lift and shift is faster, cheaper upfront, and lower risk, but leaves cloud-native benefits on the table. Refactoring re-architects the application to use cloud-native services for better cost, performance, and scalability, at higher upfront effort and risk. The practical answer for most portfolios is both: lift and shift the bulk to move quickly, then refactor selectively the few systems where cloud-native gives a real advantage. Refactoring everything upfront is usually slower and riskier than it is worth.

  • How long does cloud migration take?

    It depends on the size of your estate. AWS structures the foundational phase of a large migration as a series of two-week sprints over a few months to build the environment and move a first small group of applications. A full migration of a large portfolio commonly runs many months and can exceed a year, because applications are moved in waves rather than all at once. A single small application can move in weeks. The timeline scales with how many systems you have and how much they change.

  • What are the steps of a cloud migration?

    AWS frames a large migration in three phases. Assess: a readiness assessment, a business case, and a total cost of ownership (TCO) analysis. Mobilize: building the foundation, meaning a secure landing zone, and migrating a small first wave to prove the approach. Migrate and modernize: moving the rest at scale in waves, using repeatable, automated processes. After that comes operate and optimize: continuously right-sizing and cost-tuning the live workloads. The assessment and the landing zone are the steps rushed migrations skip and regret.

  • Is AWS available in the UAE?

    Yes. AWS operates a Middle East region physically in the UAE, known by its code me-central-1, so you can run workloads and store data inside the country. AWS also has a separate Middle East region in Bahrain, which is close by but not in the UAE, so it does not satisfy a UAE-only data-residency requirement on its own. If keeping data inside the UAE matters, the UAE region is the one to use, and you choose it deliberately when setting up.

  • Do I have to host my data in the UAE?

    For most private businesses, there is no blanket legal requirement to keep all data inside the UAE. The Personal Data Protection Law governs how personal data can be transferred across borders rather than banning it, allowing transfers where there is adequate protection or appropriate safeguards. The real exceptions are sector rules and government data: regulated sectors such as finance and health have their own requirements, and classified government data has residency rules. The honest answer is no blanket rule, but check your sector.

  • Which cloud providers have a data centre in the UAE?

    AWS and Microsoft Azure both have regions physically inside the UAE. AWS has its Middle East UAE region, me-central-1, and Azure has UAE North in Dubai and UAE Central in Abu Dhabi. Google Cloud does not currently have a region inside the UAE; its nearest Middle East regions are in Qatar and Saudi Arabia. So for a workload that must run on infrastructure physically in the UAE, AWS and Azure are the two providers that can do it today.

  • AWS or Azure in the UAE, which is better?

    Both have genuine regions inside the UAE, so both can meet an in-country data-residency requirement, and the better choice depends on your existing systems, your team's skills, and your specific workloads rather than a general winner. A business already invested in Microsoft tools may lean to Azure, while one wanting the broadest managed-service range may lean to AWS. The right approach is to assess your actual portfolio against each rather than pick on reputation. Google Cloud has no in-UAE region, which matters if residency is a hard requirement.

  • Does UAE PDPL require me to keep data in the country?

    No, it does not require local storage. UAE Federal Decree-Law No. 45 of 2021 regulates how personal data is handled and transferred, permitting cross-border transfer where the destination offers adequate protection or appropriate safeguards apply. It also does not itself cover data in the DIFC and ADGM financial free zones, which have their own regimes, nor government, health, or banking and credit data, which sit under separate legislation. Using a cloud provider's UAE region is one clean way to keep data local, but compliance remains your responsibility, not the provider's.

  • What are the main cloud cost drivers?

    Four things: compute, meaning the servers, containers, or serverless functions you run; storage, including backups and snapshots; data transfer, especially moving data out of the cloud or between regions; and managed services such as databases and AI tools, which cost more per unit but remove operational work. Compute and storage are the obvious ones. Data transfer out is the one that surprises people, because it is easy to design an architecture that quietly moves a lot of data and generates a bill nobody predicted.

  • What is data egress and why does it cost money?

    Egress is data moving out of the cloud, to the internet or to another region, and cloud providers charge for it. It matters because it is the cost most often missed at planning time. An application that streams a lot of data to users, or copies data frequently between regions, can run up meaningful transfer charges even when compute and storage look cheap. The fix is to design with data movement in mind and to check the provider's current transfer rates for your region before committing to an architecture.

  • How do I control cloud costs?

    Set up cost governance before you migrate, not after, because cost patterns are hard to reverse once workloads are at scale. The practical levers are tagging resources so you can see what costs what, budget alerts, shutting down non-production environments when idle, right-sizing over-provisioned resources, and committing to reserved capacity or savings plans for steady workloads in exchange for a discount. This ongoing discipline is called FinOps, and it is usually where the real savings from the cloud come from.

  • What is a landing zone?

    A landing zone is the secure, well-structured foundation you build in the cloud before migrating applications at scale: the baseline networking, identity and access control, security guardrails, and account structure. It matters because migrating systems into a cloud environment with no proper foundation creates security and cost problems that are painful to fix later. Building the landing zone first is a core part of AWS's own recommended approach, and skipping it is one of the most common and costly migration mistakes.

  • What is a migration wave?

    A wave is a group of applications migrated together, chosen by their dependencies, risk, and business priority. Migrating in waves rather than all at once, a so-called big bang, spreads the risk, lets you learn and improve between groups, and makes it possible to roll back one wave without affecting everything. AWS's own approach is explicitly wave-based for exactly these reasons. A big-bang migration concentrates all the risk into a single moment, which is why experienced teams avoid it.

  • What are the most common cloud migration mistakes?

    The frequent ones are: lifting everything to the cloud unchanged and then paying cloud prices for an un-optimised setup; setting up no cost governance until the bills arrive; ignoring data-transfer costs; under-estimating the skills and change management needed; migrating at scale with no landing zone or security baseline; and doing a big-bang cutover instead of waves. Most of these come from treating migration as a pure lift rather than a planned programme with an assessment, a foundation, and a cost discipline built in from the start.

  • Do I need to refactor my applications to move to the cloud?

    No, not to move them. You can rehost most applications with little or no change and run them in the cloud as they are. Refactoring, meaning re-architecting to use cloud-native services, is optional and best applied selectively to the systems where it delivers a real gain in cost, performance, or scalability. Trying to refactor everything before you move is a common way to make a migration slower, riskier, and more expensive than it needed to be. Move first, then modernise what benefits.

  • What is the difference between migrating and building cloud-native?

    Migrating means moving systems that already run somewhere, on your own servers or another host, onto cloud infrastructure. Building cloud-native means designing a new application from the start to use managed and serverless cloud services, with no legacy system to move. A migration deals with what you already have, including deciding what to retire and what to keep, while a cloud-native build starts fresh. Many businesses do both over time: migrate the existing estate, and build new products cloud-native.

  • Can I migrate to the cloud myself, or do I need help?

    A small, simple workload can be moved by a capable in-house team. A larger estate benefits from experience, because the expensive mistakes, a missing landing zone, no cost governance, an un-optimised lift, are exactly the ones a first-time team makes. AWS even offers funding through its migration programme to offset the cost of assessment and foundation work, which tells you those phases matter. The honest test is whether your team has done it before. If not, an assessment with a partner is cheap insurance.

  • What is a cloud readiness assessment?

    A cloud readiness assessment reviews your current systems and works out what should move, how, in what order, and what it will cost, before any migration happens. It produces a business case, a total cost of ownership comparison, and a plan grouped into waves. It matters because it is what stops a migration becoming an expensive improvisation. It is also the cheapest phase to get right, and where the decisions that determine the whole project's cost and risk are actually made.

  • Is my data secure in the cloud?

    The major cloud providers offer strong security, often stronger than a small business could build itself, but security is a shared responsibility. The provider secures the underlying infrastructure, and you are responsible for configuring your own systems, access, and data correctly on top of it. Most cloud security incidents come from misconfiguration on the customer side, not a breach of the provider. So the cloud can be very secure, but only if your side is set up properly, which is part of what a good migration handles.

  • Do banks and financial firms have extra cloud rules in the UAE?

    Yes. Financial institutions in the UAE fall under Central Bank rules that treat cloud hosting of core activity as outsourcing, which typically requires prior non-objection from the Central Bank before proceeding, along with data-ownership and protection requirements. Firms in the DIFC and ADGM financial free zones also have their own data protection regimes separate from the federal law. If you are in a regulated financial activity, the cloud is available to you, but the approval and compliance steps are part of the plan, not an afterthought.

  • What happens to my old systems after migration?

    They should be formally decommissioned once the migrated systems are proven, not left running. A common and avoidable cost is dual-running: paying for both the old environment and the new cloud one indefinitely because nobody set a date to switch the old one off. A proper migration plan includes a sunset date for the legacy environment. Some systems are also deliberately retired during migration rather than moved, because an assessment finds they are no longer needed at all.

  • Will migrating to the cloud improve performance?

    It can, especially for workloads that benefit from scaling up and down with demand, running closer to users, or using managed services that are faster than a self-run equivalent. But performance gains come from designing for the cloud, not from the move alone. An application lifted unchanged may perform much the same until it is optimised. Serving UAE users from a UAE region also reduces latency compared with a distant data centre, which is a concrete performance reason to use an in-country region.

SKIMBOX Team

Tech Consultancy

Get fresh writing in your inbox

One email a fortnight. No filler.

By subscribing, you agree to our privacy policy.

Want us to build something?

We work with teams across MENA, UK, USA, and India to build products, run programs, and grow.

Get in touch

Continue reading