Cloud Migration Checklist for UAE Businesses Moving to Azure

A UAE business moving servers and apps to Azure or Microsoft 365 should work through eight steps in order: map every workload and its dependencies, decide what happens to each one, choose the region deliberately, set up identity and security, plan the data transfer, pilot one low-risk workload, cut over with a tested rollback plan, and give cloud spend an owner. If you want help running it, see our cloud migration services.

What should you inventory before anything moves?

Start with a complete list, because you cannot plan for a server nobody remembered. Microsoft's Azure Migrate helps you decide on, plan and execute a migration to Azure. Its discovery appliance, a virtual appliance deployed on a server in your environment, collects configuration and performance data from your servers, or you can import an existing inventory instead.

For each workload, record:

• The servers, databases, file shares and scheduled jobs it uses.
• Its business owner, who approves downtime and signs off testing.
• How long it can be down and how much recent data it can afford to lose.
• Outside connections, such as banks, payment gateways, government portals and partners that only accept traffic from a fixed IP address.
• The licences it runs under, and whether their terms allow cloud hosting.

Then map dependencies. Azure Migrate's dependency analysis shows the network dependencies between servers so you do not miss a critical one. Microsoft's planning guidance says to group workloads that share databases, APIs, authentication services or network connections, and to keep components together when unsure. Each group becomes a migration wave.

List anything that cannot move yet and why, what it connects to and what data it shares, and keep any split across both environments short.

How do you decide what happens to each workload?

Microsoft's Cloud Adoption Framework says each workload can be retired, retained, rehosted, replatformed, refactored, rearchitected, rebuilt or replaced. Write one decision per workload:

• Retire. Little business value left. Confirm nothing critical depends on it, then switch it off.
• Rehost. Move the server as it is to an Azure virtual machine. Microsoft positions this for stable, Azure-compatible workloads, warns that rehosting does not fix existing performance or reliability problems, and advises it only when the workload will stay as it is for at least two years.
• Replatform. Make small changes to use a managed service and offload maintenance, for example moving SQL Server on a virtual machine to Azure SQL Database.
• Refactor or rearchitect. Change the code or the design where the application needs it, for example to reduce technical debt or to scale parts of it independently.
• Replace. Swap the application for a SaaS product. Moving from an on-premises Exchange server to Exchange Online is a Microsoft 365 example.
• Retain. Keep it where it is when it is stable, compliant and there is no near-term reason to move.

Get the business owner to agree each decision. A workload marked "rehost now, refactor next year" is really a refactor, and Microsoft's guidance is to plan it that way to avoid duplicate effort.

Which Azure region should a UAE business choose?

Microsoft lists two Azure regions in the UAE:

• UAE North, physically located in Dubai, with three availability zones.
• UAE Central, physically located in Abu Dhabi, with no availability zones listed. Microsoft marks it as a restricted region: access is limited to specific customer scenarios, such as disaster recovery within a geographic area, and you request access for your subscription.

The two regions are paired with each other. In practice, that makes UAE North the place to plan production, using its availability zones for resilience, with UAE Central an option for disaster recovery once access is approved. Check every service in the design is offered there; Microsoft notes that some services might not support availability zones even in a region that has them.

For Microsoft 365, check where your tenant's data already sits. The Data Location card in the Microsoft 365 admin center shows it, and Microsoft lists the United Arab Emirates as a Local Region Geography with access to Advanced Data Residency commitments for certain services.

If you believe your data must stay in the UAE, identify the regulation, licence condition or contract that says so and get it confirmed in writing by your adviser or regulator before you choose.

What has to be in place before the first workload moves?

Build the foundation before any workload moves. Microsoft lists an Azure landing zone as a prerequisite for migration planning. The foundation checklist:

• Subscriptions. Separate development, test and production subscriptions, each with its own access, policies and budgets, which Microsoft recommends for isolation, cost tracking and governance.
• Identity. Plan sign-in through Microsoft Entra ID, test single sign-on, multifactor authentication and password reset with test accounts, and replace hard-coded service accounts with managed identities.
• Least privilege. Give administrators only the access they need, and allow only necessary traffic between services.
• Compatibility fixes. Upgrade unsupported operating systems, replace hard-coded IP addresses with DNS names, and integrate host-based antivirus with Microsoft Defender for Cloud, making the fixes in the Azure test environment rather than on the source servers.
• Infrastructure as code. Build production from templates so every environment is built consistently.

How should the data get to Azure?

Choose the transfer path per workload, based on data size, sensitivity and the connection you have. Microsoft's planning guidance compares four:

• ExpressRoute: a private, dedicated connection, faster and more secure than the internet, but it takes time to set up and has data transfer costs.
• VPN: an encrypted tunnel over the internet, more secure than the public internet but typically slower than ExpressRoute.
• Azure Data Box: Microsoft ships you a device, you copy data onto it and ship it back; it avoids your network but is the slowest option.
• Public internet: available everywhere, but the least secure and it uses your bandwidth, so keep it for less sensitive data.

Do the arithmetic early: divide the data volume by the bandwidth you can actually spare. For databases, Microsoft's guidance is to replicate continuously and copy files to Azure before the final cutover, so only late changes move during the cutover window.

How do you run a pilot that proves the plan?

Microsoft recommends beginning with less complex, lower-risk workloads, such as internal tools, development environments or low-usage applications with few integration points. A pilot passes when:

• Users sign in and complete their normal tasks without new errors.
• Every dependency in the map still connects, including outside partners.
• Backups run and a test restore succeeds.
• Monitoring sends alerts to a named person.
• The rollback steps have been rehearsed in a test environment and timed.

What does a safe cutover and rollback plan include?

Agree the failure conditions before the night of the move. Microsoft's guidance is to define a failed deployment with business stakeholders and workload owners, for example failed health checks, poor performance or security issues, and to write the rollback triggers into the plan. Then test the rollback. On the night:

1. Stop changes to the source systems for the migration window, with a documented route for emergency fixes.
2. Hold a readiness review with every support team, covering the plan, the checks and the rollback criteria.
3. Pause writes, complete the final sync, then validate the data. Row counts are a quick check; Microsoft prefers checksums and hash comparisons for deeper validation.
4. Point DNS and other connections at Azure, and have application owners confirm the main functions work.
5. Keep the old environment available as a fallback, with the ability to revert DNS, until the workload is stable.
6. Watch performance, errors and user access closely for the first 24-48 hours, the period Microsoft suggests.

Announce success only after application owners and business stakeholders confirm it, then schedule the old servers for decommissioning.

How do you keep Azure costs under control after the move?

Cloud spend follows usage, so it needs an owner from the first day. The main drivers are virtual machine size and running hours, storage, data transfer, backup retention, licensing, and the weeks when old and new environments run side by side. To keep it in check:

• Set budgets on each subscription. Azure Cost Management can alert on actual or forecast spend, but budgets do not stop consumption and resources are not affected, so someone has to act on the alert.
• Expect a delay. Cost data is typically available within 8-24 hours, and budgets are evaluated every 24 hours, so a budget alert is not a real-time brake.
• Compare actual use with the sizes Azure Migrate estimated, and right-size after a few weeks of real data.
• Remove the old on-premises copies once the fallback window closes and your retention rules allow it.
• Review the bill with workload owners every month, not only with IT.

Should you run the migration yourself or bring in help?

Microsoft advises bringing in Microsoft or a Microsoft partner if your team lacks cloud migration experience. GR IT Services is a Microsoft Cloud Solution Provider (CSP), and our cloud assessment covers workload inventory, dependency mapping, target-platform fit and cost modelling, ending in a written roadmap of prioritised waves. For Azure specifically, see Azure migration in Dubai. Still deciding whether to move? Read cloud vs on-premise for Dubai businesses or AWS vs Azure for UAE businesses. To start with an inventory of your estate, contact us.