Cloud migration checklist for UAE businesses.

Why a checklist matters

Moving systems to the cloud is rarely difficult in a technical sense. It goes wrong when the preparation is thin: an application nobody remembered, data in the wrong place, costs nobody owns, or a cutover with no way back. This checklist is written for UAE businesses of all sizes and works whether you are moving email and files to Microsoft 365, servers to a public cloud or a hosted private cloud, or a line-of-business application to a vendor's service. Work through it in order and write down the answer to each point.

1. Assess and inventory

Start with what you have, not with what you want. A reliable inventory is the single most useful input to the whole project.

• List servers, applications, databases, file shares, mailboxes and scheduled jobs, with an owner for each.
• Record how each one is used, who depends on it and what else it connects to, including integrations with accounting, ERP, payment and telephony systems.
• Note licences, support contracts and renewal dates, since some licences do not transfer to a cloud environment on the same terms.
• Identify shared and service accounts, because these are the ones that break quietly after a move.
• Flag data that should be archived or deleted rather than migrated. Moving clutter only makes the new environment larger and harder to secure.

If you do not have a trustworthy list, a free IT health check is a sensible place to build one.

2. Decide which workloads fit

For each workload, choose one of five outcomes: keep as it is, move as it is, change it during the move, replace it with a cloud service, or retire it. A short set of questions helps.

• Is the vendor still supporting this application, and does it support a cloud deployment?
• Does it need very low latency to equipment or users on one site?
• Is it tied to a specific operating system or hardware that cannot be reproduced?
• Would a software-as-a-service replacement do the same job with less upkeep?
• Does the data it holds carry restrictions on where it may be stored?

Then choose the target: a public cloud, a hosted private cloud in the UAE, or a mix. Our page on Sangfor private cloud infrastructure describes one option for workloads that suit a UAE-hosted environment.

3. Data residency and compliance considerations

Where data is stored, who can access it and which rules apply are questions to answer before you pick a region or provider, not after. Requirements differ between sectors, customers and regulators, and they change over time. State the position generally: some organisations have contractual or regulatory reasons to keep certain data in the country or region, and others do not. Check what applies to you with the relevant authority or take legal advice, and write the answer down.

Remember that residency covers more than the primary copy. Backups, replicas, logs and support access all matter. Our managed cloud data residency checklist sets out the questions to put to a provider.

4. Set a security baseline first

Do not move into an environment that is less protected than the one you are leaving. Agree the baseline before the first workload arrives.

• Multi-factor authentication for all administrators and, ideally, every user.
• Separate administrator accounts, with the fewest privileges needed for each role.
• Logging switched on and kept somewhere an attacker with admin rights cannot erase.
• Network rules that allow only what each workload needs, with a firewall or equivalent control in front.
• Encryption for data in transit and at rest, with a clear owner for the keys.
• A backup that sits outside the account it protects. Cloud hosting is not the same as having a backup.

For Microsoft 365 specifically, see our Microsoft 365 security baseline.

5. Govern costs from day one

Cloud costs are variable by design, which is useful and also the reason they drift. Put the controls in place before the migration, not after the first surprising invoice.

• Give every subscription, resource group or project a named owner.
• Tag resources by purpose and department so spend can be explained.
• Size resources from measured usage, not from the old server's specification, and revisit the sizing after a few weeks of real use.
• Set budget alerts so that unexpected growth is noticed early.
• Switch off development and test resources when they are not in use, and delete what nobody claims.
• Compare licences you already own against what the cloud service would charge, since the two sometimes overlap.

Describe the expected running cost qualitatively at first, then replace it with figures from the pilot rather than guessing.

6. Plan the cutover and the rollback

The migration itself should be uneventful. That comes from rehearsal and a plan that is written before the day.

1. Pilot. Move a small, low-risk workload or a sample of data first, and check it with the people who use it.
2. Written plan. Record the order of work, the cutover window, who does what and who approves each step.
3. Freeze. Agree when changes to the source system stop, so that nothing is lost between the final copy and the switch.
4. Rollback point. Decide in advance what result means you go back, who makes that call, and how the original system is kept intact until sign-off.
5. Verification. Test logins, data completeness, integrations and printing or scanning before announcing that the move is done.

Out-of-hours cutovers reduce disruption. If you want support with the move itself, our data migration services cover email, files, legacy data and servers.

7. Train people and communicate

Many migration problems are reported as technical faults but are really unfamiliarity. Tell staff what is changing, when, and what they need to do, such as signing in again or re-enrolling a device. Give short guides for the tasks they perform every day, name who to contact in the first week, and keep a visible list of known issues. Support staff should be briefed before everyone else.

8. Review after the move

The project is not finished at cutover. Schedule a review after a few weeks and check:

• Whether performance and availability match what was expected.
• Whether running costs are in line with the pilot, and who owns any difference.
• That backups are running and that a restore has been tested. Our backup restore test checklist can be used for this.
• That old systems are decommissioned securely, with data wiped and licences released, rather than left running unmanaged.
• That documentation, diagrams and account ownership are up to date and held in your company's name.

Where Missan Global fits

Missan Global has supported UAE organisations since 2004 from its Al Majaz, Sharjah head office, with teams in 3 countries: the UAE, India and Uzbekistan. We plan and carry out migrations to Microsoft 365, Azure and UAE-hosted private cloud, and we will tell you plainly when a workload should stay where it is.