Microsoft 365 Migration
Checklist for UAE Businesses

Photo by Ed Hardie on Unsplash

Phase 1: Discovery and Licence Audit

The discovery phase is where most migrations are won or lost. Spend less than a week on it and you will be unpicking problems during cutover, when time and patience are in short supply. A solid discovery for a 50-user Dubai business should take 5–7 working days and produce a documented inventory before a single mailbox moves.

Start with the full user list from Active Directory or your current mail system. For each account, record:

• Mailbox size - anything over 50GB needs special handling; Exchange Online's native import tool struggles with very large mailboxes and may require the Azure Import Service
• Licence requirement - not every user needs Microsoft 365 Business Premium; admins, reception desks, and meeting rooms often need different licence tiers
• Device type - Windows, Mac, iOS, and Android all have different Outlook configuration steps; catalogue them now

Shared Mailboxes and Distribution Lists

These are consistently under-documented in UAE SMEs. Shared mailboxes like info@, accounts@, and sales@ are often accessed by multiple staff without appearing in the main user list. Distribution lists may have accumulated hundreds of members over years and contain departed staff who still receive external email. Export your full shared mailbox and distribution list inventory from Exchange before touching anything.

Public folders are a separate problem. Many organisations running Exchange 2016 still use public folders for shared calendars or contacts that predate SharePoint. Decide before migration whether these migrate to Exchange Online public folders, SharePoint document libraries, or Microsoft 365 Groups - all three are valid options but each has different migration complexity. The Microsoft 365 migration services we offer include a full public folder assessment as part of the discovery engagement.

Legacy Application Audit

This is the most frequently skipped step and the most dangerous. Applications that send email using SMTP AUTH with username and password - printers, scanners, CRM systems, accounting software, custom-built internal tools - will break when you enforce Modern Authentication and disable Basic Auth, which Microsoft is progressively enforcing across all tenants.

Before cutover, enumerate every application that sends or receives email. For each one, determine whether it supports OAuth 2.0 (Modern Auth) or still requires Basic Auth. Apps that cannot be upgraded need alternative send paths configured - typically a dedicated SMTP relay or a shared mailbox with app passwords temporarily enabled.

Phase 2: Microsoft 365 Environment Preparation

Phase 3: Pilot Migration - Always Start with 10 Users

Never migrate all users at once. The pilot run is where you catch environment-specific problems that no checklist can anticipate in advance. Select 10 users who represent a realistic cross-section of the business: at least one heavy Outlook user with a large mailbox, one mobile-only user, one with a shared mailbox dependency, and ideally one technically confident user who will notice and report subtle issues.

Run the pilot batch over 48 hours. Both mail systems should remain active - the pilot users receive mail on both sides while the migration completes. After the batch finishes, verify:

• All email, calendar appointments, contacts, and folder structure transferred correctly
• Shared mailbox access works from Outlook on the desktop and Outlook mobile
• Autodiscover resolves to the correct Microsoft 365 endpoint (not the old Exchange server)
• Out-of-office rules transferred or were manually recreated
• Any applications these users interact with still function correctly

Autodiscover misconfiguration is worth calling out specifically - it is one of the most common causes of Outlook failing to configure correctly after migration. When a user opens Outlook post-migration, Autodiscover finds their mailbox location automatically. If your Autodiscover DNS record still points to the old Exchange server, Outlook will configure correctly for Exchange on-premise but fail once MX records switch to Microsoft 365. Verify and update your Autodiscover CNAME before finalising the cutover date.

Batch Planning for the Full Migration

After a successful pilot, plan the remaining mailboxes in batches of 20–30 users. Group by department or floor where possible - this makes user support easier because an IT engineer assisting users on the same team can handle multiple questions in one visit rather than traversing the building. Allow 24 hours between batches to ensure the previous batch is stable before adding more users to the migration queue.

Phase 4: DNS Cutover - Timing Is Everything

The DNS cutover is the moment mail routing switches from your old server to Microsoft 365. It is a brief but precise operation, and the timing significantly affects how much disruption users experience.

For UAE businesses, Thursday night between 11pm and 2am is the consistently best window. Friday is the first day of the weekend, email volume is at its weekly low, and any issues discovered during or after the cutover have a full day to resolve before the business-critical Sunday morning rush. Avoid Sunday evenings and Monday mornings entirely - those are peak email periods in the UAE working week and the worst time to be troubleshooting mail routing.

The cutover sequence is:

1. Confirm all migration batches have completed and no mailboxes are in error state
2. Update the MX record to point to Microsoft 365 (yourtenantname.mail.protection.outlook.com)
3. Update the Autodiscover CNAME to autodiscover.outlook.com
4. Add SPF, DKIM, and DMARC records for Microsoft 365
5. Monitor the Microsoft 365 message trace tool for 30 minutes to confirm mail is flowing
6. Keep the old Exchange server online and receiving mail for 24–48 hours as a safety net

Tight integration between cutover and backup and disaster recovery configurations is essential at this stage - make sure your backup jobs are updated to target the new Exchange Online environment, not the on-premise server, before decommissioning the old hardware.

Phase 5: MFA and Security Configuration

Multi-factor authentication for Microsoft 365 should be configured before cutover but enforced in report-only mode initially. Full enforcement comes 5–7 business days post-migration, after users have confirmed their MFA method works on their primary device. One exception: global admin accounts must have MFA enforced from the moment they are created. No admin account should ever exist without MFA in a production Microsoft 365 tenant.

Intune Device Enrolment

If your Microsoft 365 plan includes Intune (Business Premium or above), device enrolment should begin during the pilot phase. Windows devices can be enrolled via the Company Portal app or through Autopilot for new hardware. Mobile devices need the Intune Company Portal app installed and a compliance policy configured before being allowed to sync corporate email.

For UAE organisations with a BYOD (Bring Your Own Device) policy - common in Dubai's SME sector - Mobile Application Management (MAM) without device enrolment is often a better fit than full MDM. It applies corporate policies to the Outlook app specifically, without requiring employees to enrol their personal device into company management. This avoids the friction of staff refusing to install MDM profiles on personal phones.

Conditional Access Policies

Once MFA is enforced, configure at least two Conditional Access policies as a baseline: one requiring compliant or hybrid Azure AD-joined devices for access to company data, and one blocking sign-in from high-risk countries. For most Dubai businesses, the second policy needs careful thought - staff travel frequently across the Gulf region, and blocking access from Saudi Arabia, Kuwait, or Bahrain will generate support calls immediately. Review your staff travel patterns before setting geographic restrictions. The managed IT services team can help map appropriate CA policies to your specific workforce and risk profile.

Common Failure Points in UAE Migrations

Having migrated dozens of Dubai organisations from Exchange on-premise and Google Workspace to Microsoft 365, these are the problems that appear most frequently:

• Legacy authentication apps not found during discovery. A printer on floor 3 that scans to email using Basic SMTP - nobody knew it existed until the helpdesk started receiving "scan to email broken" tickets post-migration.
• Large mailboxes stalling batches. A mailbox over 50GB will slow or stall a migration batch that also contains smaller mailboxes. Run large mailboxes as solo batches during off-hours.
• Autodiscover not updated pre-cutover. Results in Outlook trying to connect to the old Exchange server, appearing to work initially (if the old server is still live) but breaking when the old server is decommissioned.
• SPF record conflicts. If you had a pre-existing SPF record for your old mail server and simply add Microsoft 365's SPF entry, you may create a record with more than 10 DNS lookups - causing SPF to fail and increasing the risk of your outbound mail being marked as spam. Consolidate SPF records carefully.
• Staff on Exchange 2016 using Cached Exchange Mode with very old OST files. Outlook sometimes refuses to rebuild the local cache after a migration if the OST is corrupt or very large. Deleting the OST and allowing Outlook to rebuild from scratch is the fix - but it takes time for heavy users, so plan support capacity accordingly.

Post-Migration: The First Two Weeks

The cutover is not the finish line - it is the start of a two-week stabilisation window. Allocate helpdesk resource specifically for migration issues during this period. Common post-migration support requests include Outlook not prompting for new credentials, Teams not launching from the desktop shortcut (because the sign-in address changed), and OneDrive sync failing on devices that had a previous OneDrive for Business installation.

Run a post-migration review at the end of week two covering: any unresolved tickets, mailboxes still showing migration errors, applications still using old authentication methods, and licensing accuracy. This review also determines whether the old Exchange server can be decommissioned safely. Do not decommission early - unexpected issues with third-party applications sometimes surface after 10–12 days when scheduled tasks or batch processes run for the first time post-cutover.

A structured approach to cloud adoption in the UAE extends beyond migration day - ongoing administration, licence management, security policy updates, and user training are ongoing. Most Dubai SMEs get significantly more value from Microsoft 365 when those post-migration capabilities are actively managed rather than left to default settings.