Microsoft 365 / Email Migration Checklist for Saudi Businesses

Moving a business to Microsoft 365 involves far more than transferring email. A successful migration may require planning users, identities, mailboxes, files, permissions, DNS, security settings, licensing, employee devices and business applications while keeping disruption to a minimum.

This Microsoft 365 migration checklist is designed for Saudi businesses moving from environments such as cPanel email, hosted IMAP, Google Workspace, on-premises Exchange or another Microsoft 365 tenant.

The right migration path depends on where your data currently resides and which Microsoft 365 workloads you intend to use. Microsoft provides different migration capabilities for IMAP, Exchange, Google Workspace and cross-tenant scenarios, so the project should begin with an assessment rather than immediately copying data.

What Is a Microsoft 365 Email Migration?

A Microsoft 365 migration is the process of moving business users, communications, files or collaboration workloads into Microsoft 365.

Depending on the organization, a migration may include:

• Exchange Online email and mailboxes
• Contacts and calendars
• User identities
• OneDrive files
• SharePoint sites and documents
• Teams-related content where supported
• Groups and permissions
• Custom domains and DNS
• Security policies
• User devices and applications

Not every organization needs to migrate all of these workloads.

A company currently using cPanel may initially require email migration only. A business moving from Google Workspace may also need calendars, contacts and Drive content. A merger or restructuring may involve Exchange Online, OneDrive, SharePoint and other data moving between Microsoft 365 tenants.

A simple way to view the project is:

Current Business Environment
↓
Assessment & Planning
↓
Identity & Security Preparation
↓
Pilot Migration
↓
Data Migration
↓
DNS / Mail Cutover
↓
Validation & User Support
↓
Controlled Decommissioning

Microsoft 365 / Email Migration Checklist at a Glance

The sequence matters. Changing DNS before users and mailboxes are ready can interrupt communication. Migrating files without understanding permissions can create access problems.

Phase 1 — Assess Your Current Environment

Identify the Existing Email Platform

Start by confirming where business email currently resides.

Typical source environments include:

• cPanel email
• Hosted IMAP email
• Google Workspace
• Microsoft Exchange Server
• Another Microsoft 365 tenant
• Other hosted business-email platforms

Migration methods differ by source.

Microsoft’s native IMAP migration, for example, migrates mail-folder content but does not migrate contacts, calendars or tasks. Those items require separate handling. Microsoft Learn

If your organization is moving specifically from cPanel, link readers here to your cPanel to Microsoft 365 Migration Guide for the detailed source-specific process.

Inventory Users, Mailboxes and Business Addresses

Create a full list of existing email identities before provisioning the new environment.

Review:

• Active employees
• Former or inactive users
• Mailbox sizes
• Shared addresses
• Aliases
• Forwarders
• Distribution lists
• Contacts
• Calendars
• Resource mailboxes
• Departmental email addresses

Do not automatically create a paid Microsoft 365 user account for every address on the old server.

For example, info@, sales@ and accounts@ could potentially become an alias, shared mailbox or group—but those objects serve different purposes.

An alias is an additional address for an existing mailbox. A shared mailbox has its own mailbox content and can be accessed by permitted users. A Microsoft 365 group follows a different collaboration model.

Shared Mailbox Licensing

Shared mailboxes should not simply be described as “free mailboxes.”

Microsoft currently allows a shared mailbox to store up to 50 GB without assigning a separate license to the shared mailbox, but users who access it must have licensed Exchange Online mailboxes. Larger shared mailboxes, archiving, litigation hold and some advanced security or compliance capabilities may require additional licensing. Microsoft Learn

Choose the object based on the business use case, not just the apparent licensing cost.

Inventory Business Data

Microsoft 365 migration may involve more than email.

Review:

• Local user files
• Departmental folders
• File servers
• Network drives
• Google Drive
• Existing OneDrive content
• SharePoint sites
• Documents associated with Teams
• Shared business folders

Decide where different types of information should live before migration.

Moving every file into one SharePoint site or OneDrive account without considering ownership, permissions and collaboration requirements can create a difficult environment after migration.

Identify Applications That Send Email

This is one of the most important parts of the assessment.

Check whether any of the following use the existing email server:

• Website contact forms
• Printers
• Scanners
• ERP systems
• CRM platforms
• Accounting software
• Monitoring platforms
• Firewalls and security appliances
• Business applications
• Scheduled scripts
• SMTP relay services

A migration can appear successful for employees while automated invoices, website forms or equipment alerts silently stop sending.

Important 2026 SMTP AUTH Change

Do not design new application or device mail flows around legacy username-and-password SMTP authentication without reviewing Microsoft’s current direction.

Microsoft’s January 2026 update states that SMTP AUTH Basic Authentication remains unchanged through December 2026, but at the end of December 2026 it becomes disabled by default for existing tenants. For new tenants created after December 2026, Basic Authentication for SMTP AUTH will be unavailable by default; OAuth is Microsoft’s supported modern authentication direction. TECHCOMMUNITY.MICROSOFT.COM

Before migration, determine whether each printer, ERP system, website or application can use the selected Microsoft-supported mail-sending method and whether that method is compatible with your tenant’s security configuration.

Phase 2 — Choose the Right Migration Approach

There is no single Microsoft 365 migration method that works for every organization.

The correct approach depends on:

• Source environment
• Number of users
• Data types
• Mailbox sizes
• Required coexistence
• Available migration window
• Identity architecture
• Business tolerance for disruption

IMAP Migration

IMAP migration is relevant to many cPanel and hosted-email environments.

Microsoft’s native IMAP migration transfers email from mail folders, but it does not migrate contacts, calendars or tasks. Microsoft Learn

Microsoft migration batches can also perform incremental synchronization while supported batches remain active. Microsoft’s current documentation says incremental synchronization for most migration batch types occurs approximately every 24 hours. Microsoft Learn

This can be useful when historical mail is pre-staged before the final MX cutover.

Before using IMAP migration, confirm:

• Source IMAP server details
• Authentication method
• Required credentials
• Mailbox scope
• Unsupported data
• Current Microsoft migration limits

Microsoft can change technical migration limits over time, so link to Microsoft’s current documentation rather than hardcoding every limit into an evergreen article.

Exchange Migration

Organizations running Exchange Server may have different migration options depending on:

• Exchange version
• Current support status
• Hybrid requirements
• Directory synchronization
• Coexistence requirements
• Identity architecture

Do not select an Exchange migration approach based on company size alone.

The source Exchange version and support status should be recorded during the initial assessment.

Be Careful When Decommissioning Hybrid Exchange

Moving all mailboxes to Exchange Online does not automatically mean the final on-premises Exchange server can simply be uninstalled.

In environments with synchronized identities, management of Exchange attributes and their Source of Authority must be handled using a Microsoft-supported approach. Microsoft now documents supported paths for moving Exchange-attribute Source of Authority to the cloud before removing the last Exchange Server. Microsoft Learn

Hybrid decommissioning should therefore be treated as its own planned activity after migration.

Google Workspace Migration

A Google Workspace project may include:

• Gmail
• Calendars
• Contacts
• Google Drive
• Shared files

These workloads should be assessed independently. Email migration and file migration are not necessarily one identical process.

Microsoft’s current migration tooling supports Google Workspace migration scenarios, while Drive content has its own migration capabilities and planning requirements.

Avoid assuming that migrating Gmail automatically migrates every piece of Google Workspace data.

Microsoft 365 Tenant-to-Tenant Migration

Tenant-to-tenant migrations commonly occur during:

• Mergers
• Acquisitions
• Divestitures
• Company restructuring
• Tenant consolidation

They may involve:

• Exchange Online
• OneDrive
• SharePoint
• Teams-related content
• Identities
• Custom domains

Licensing and Workload Scope

Microsoft’s native cross-tenant mailbox migration requires appropriate Exchange licensing plus the Cross-Tenant User Data Migration license for migrating users. Microsoft currently states that this license also covers OneDrive migration. Microsoft Learn

SharePoint cross-tenant migration has separate licensing and eligibility requirements; Microsoft’s current documentation, for example, limits the native Cross-Tenant Shared Data Migration capability to qualifying Enterprise Agreement customers. Microsoft Learn

Teams scope also needs separate assessment. Mailbox migration does not mean every Teams workload, channel or collaboration object automatically moves with it.

Plan Custom-Domain Transfer

A custom domain cannot simply remain active as the same authoritative domain in both Microsoft 365 tenants.

Microsoft requires references to the domain to be removed from the source tenant before that domain can be removed and added to the target tenant. Microsoft Learn

Domain-transfer planning can therefore become one of the most sensitive parts of a tenant-to-tenant cutover.

Verify:

• Domain dependencies
• User addresses
• Proxy addresses
• Groups
• Applications
• Mail routing
• Identity changes
• Target-tenant readiness

before setting the cutover date.

Phase 3 — Prepare the Microsoft 365 Environment

Choose Appropriate Licensing

Licensing should reflect actual business needs rather than simply selecting the cheapest subscription.

Consider:

• Exchange Online requirements
• Desktop Office applications
• OneDrive and SharePoint
• Teams
• Device management
• Microsoft Entra capabilities
• Security controls
• Compliance requirements

Avoid hardcoding plan prices into an evergreen migration guide because Microsoft commercial terms and included capabilities can change.

Prepare the Tenant and Domain

Preparation may include:

• Microsoft 365 tenant configuration
• Custom-domain addition
• Domain ownership verification
• User provisioning
• Groups
• Shared mailboxes
• Administrative roles

Create the necessary identities and mailboxes before changing live email routing.

Verifying ownership of a domain does not require immediately switching the MX record.

Plan Administrative Roles

Do not make every migration technician or internal IT employee a Global Administrator simply for convenience.

Use appropriate roles such as:

• Exchange Administrator
• SharePoint Administrator
• User Administrator
• Security roles
• Global Administrator only where genuinely required

Least privilege reduces unnecessary administrative exposure.

Phase 4 — Prepare Security Before Migration

Security should be part of the migration design rather than something added after cutover.

Configure MFA and Identity Protection

Plan MFA for users and give additional attention to privileged administrator accounts.

Microsoft Security Defaults provide a baseline without additional Entra licensing, while Conditional Access requires at least Microsoft Entra ID P1. Microsoft 365 Business Premium also includes Conditional Access capabilities; risk-based Conditional Access requires Entra ID P2. Microsoft Learn

Do not simply enable complex access policies immediately before cutover without testing them.

Verify:

• User registration
• Administrator access
• Required exclusions
• Device/application compatibility
• Emergency access procedures

Microsoft currently recommends maintaining two appropriately secured cloud-only emergency-access accounts for break-glass scenarios. Microsoft Learn

Protect Privileged Accounts

Review:

• Who needs privileged access
• Whether separate administrator identities are appropriate
• MFA requirements
• Emergency access
• Unnecessary administrators
• Conditional Access where licensed

Privileged accounts should receive stronger protection than normal business accounts.

Plan SPF, DKIM and DMARC

Email authentication does not move automatically with mailbox data.

Review:

• SPF
• DKIM
• DMARC
• Website senders
• ERP and CRM platforms
• Marketing systems
• SaaS applications
• Other legitimate mail sources

Use Only One SPF Record per Domain

Microsoft explicitly states that only one SPF TXT record is allowed per domain or subdomain. Multiple SPF records can cause an SPF permerror. Microsoft Learn

If Microsoft 365, a website, CRM and another service all legitimately send email for your domain, their permitted sending infrastructure must be represented correctly in one valid SPF policy rather than by creating several SPF records.

SPF also has DNS lookup limits, so complex sender environments should be reviewed carefully.

Configure Microsoft 365 DKIM Correctly

For Microsoft 365 custom-domain DKIM signing, Microsoft currently requires two DKIM selector CNAME records, normally selector1 and selector2, to support signing and key rotation. Microsoft Learn

Therefore, describe the task as:

Configure DKIM CNAME selectors and enable DKIM signing

rather than simply “add a DKIM record.”

Validate DMARC After SPF and DKIM

DMARC relies on alignment with SPF and/or DKIM.

Verify:

• All legitimate sending sources
• SPF alignment
• DKIM signing
• DMARC reporting
• Current policy behavior

Avoid moving immediately to an aggressive DMARC policy until legitimate senders have been verified.

Microsoft documents p=none as monitoring-only and stronger quarantine or reject policies as enforcement options. Microsoft Learn

Review Microsoft 365 Security Controls

Depending on licensing and business risk, review controls such as:

• Anti-phishing policies
• Safe Links
• Safe Attachments
• Conditional Access
• External sharing
• Audit logging
• Endpoint security
• Identity protection

This is a natural place to link to Microsoft 365 Security Services and your broader Cybersecurity Services in Saudi Arabia page.

Phase 5 — Prepare Data for Migration

Migration is a good opportunity to reduce unnecessary data and fix obvious permission problems.

Review:

• Inactive users
• Obsolete mailboxes
• Old aliases
• Oversized mailboxes
• Duplicate folders
• Old files
• Incorrect permissions
• Unsupported files
• Former employee data

Do not delete business information simply to reduce migration effort. Retention, legal, compliance and operational requirements should take priority.

Protect Critical Data Before Migration

Migration is not a backup strategy.

A migration tool exists to move data from one environment to another.

A backup and recovery strategy exists to restore information when data is lost, corrupted, deleted or otherwise unavailable.

Protect critical business information according to the organization’s actual retention and recovery requirements before major migration changes begin.

Phase 6 — Run a Pilot Migration

A pilot can reveal problems before they affect the whole company.

Do not test only the easiest mailboxes.

A representative pilot might include:

• A manager
• A standard office user
• A large-mailbox user
• A user with shared-mailbox access
• A mobile-heavy user
• Someone using shared files
• A user dependent on an ERP or CRM application

Test:

• Email
• Contacts
• Calendars
• Outlook
• Mobile access
• Shared mailboxes
• OneDrive
• File permissions
• Business applications
• Website-generated email
• Authentication and MFA

Resolve pilot issues before moving the wider organization.

Phase 7 — Perform the Migration

The detailed procedure depends on the source environment, but the high-level process commonly looks like:

Prepare migration users or batches
↓
Start migration or synchronization
↓
Monitor progress
↓
Review failures
↓
Resolve problematic items
↓
Validate migrated users

Do not promise that every Microsoft 365 migration will finish within a fixed number of hours.

Migration duration can be affected by:

• Source environment
• Migration method
• Mailbox size
• File volume
• Available bandwidth
• Microsoft service limits
• API limits
• Errors and remediation

Phased migrations may be appropriate for larger or more complex environments.

Phase 8 — DNS and Email Cutover

DNS changes affect live communication, so treat cutover as a controlled project stage.

MX Cutover Is Not Instant Everywhere

After the MX record is changed, inbound mail does not necessarily switch everywhere at the exact same second.

DNS resolvers may continue using a cached version of the previous MX record until its TTL expires. Microsoft migration guidance similarly describes mail beginning to flow toward the new tenant as the MX TTL expires. Microsoft Learn

For a period during cutover, some senders may therefore still deliver to the previous environment.

Keep the old mail environment available until migration and mail routing are properly validated.

Lower TTL in Advance

Review DNS TTL values before the scheduled cutover.

Where appropriate, lowering TTL sufficiently in advance can reduce the time old DNS information remains cached.

Changing the TTL only a few minutes before cutover does not retroactively clear DNS entries that were already cached under the previous, longer TTL.

Plan this change before the migration window.

Website Hosting Can Remain Separate

Moving email to Microsoft 365 does not require moving the company’s website.

For example:

• Website → existing web host
• Email → Microsoft 365
• DNS → appropriately configured provider

can all remain separate.

This distinction is particularly useful for businesses moving from cPanel email while keeping the WordPress site on the same hosting server.

Phase 9 — Post-Migration Validation

Do not declare the project finished simply because the migration dashboard displays “successful.”

Test the actual business environment.

Post-Migration Validation Checklist

• ☐ Internal mail works
• ☐ External inbound mail works
• ☐ External outbound mail works
• ☐ Outlook connects
• ☐ Mobile devices connect
• ☐ Shared mailboxes work
• ☐ Calendars are available where migrated
• ☐ Contacts are available where migrated
• ☐ Distribution lists/groups work
• ☐ OneDrive files are accessible
• ☐ SharePoint permissions are correct
• ☐ Teams works for the supported/migrated scope
• ☐ Website forms send successfully
• ☐ ERP and CRM notifications work
• ☐ Printers/scanners send where required
• ☐ SPF has one valid policy containing legitimate senders
• ☐ DKIM signing works for required domains
• ☐ DMARC alignment/reporting is checked
• ☐ MFA works
• ☐ Administrator access is verified
• ☐ Users can access required business files

Include actual users from different departments in testing rather than relying only on the administrator’s account.

Phase 10 — Prepare and Support Employees

A technically successful migration can still feel unsuccessful when employees cannot sign in, locate files or configure Outlook.

Users may need guidance on:

• Microsoft 365 sign-in
• MFA registration
• Outlook setup
• Mobile email
• OneDrive
• SharePoint
• Teams
• New file locations
• Password and security practices
• Reporting problems

Tell employees:

• When the migration will happen
• What will change
• Whether passwords or profiles will change
• What action they must take
• Where they can obtain support

Good communication reduces confusion during cutover.

Phase 11 — Validate Before Decommissioning the Old Environment

Do not cancel the old mail provider, delete source tenants or remove infrastructure immediately after cutover.

First verify:

• Mail flow
• Migrated data
• Permissions
• Business applications
• SMTP dependencies
• User access
• Recovery requirements
• Outstanding migration errors

Then complete the planned decommissioning process.

For Exchange hybrid environments, follow Microsoft’s current Exchange Source-of-Authority and decommissioning guidance rather than simply uninstalling the final Exchange server. Microsoft Learn

Microsoft 365 Migration Considerations for Saudi Businesses

Saudi organizations should combine migration planning with the operational, privacy and cybersecurity requirements relevant to their own environment.

Consider:

• Multiple offices and branches
• Jubail, Eastern Province and nationwide users
• Remote employees
• Arabic and English support
• Working-hour impact
• Business continuity
• Personal-data requirements
• Cybersecurity obligations
• Third-party applications
• Internet connectivity between branches
• Support coverage during cutover

A manufacturing business using ERP, printers, scanners, shared mailboxes and remote sites needs a different migration plan from a consultancy using only Outlook and OneDrive.

Do Not Assume Microsoft 365 Data Is Automatically Stored in Saudi Arabia

Microsoft announced that its Saudi Arabia East datacenter region is scheduled to become available in November 2026 for supported cloud and AI workloads. Source

However, as of the current Microsoft 365 data-residency documentation, Saudi Arabia is still listed as a Future Local Region Geography rather than among the currently available Microsoft 365 Local Region Geographies. Microsoft Learn

Do not tell customers that Exchange Online, SharePoint, OneDrive or other Microsoft 365 data will automatically reside inside Saudi Arabia merely because the tenant belongs to a Saudi organization.

Before making a data-location commitment, verify:

• The specific Microsoft 365 service
• Tenant geography
• Current Microsoft Product Terms
• Applicable data-residency commitments
• Current service availability

Microsoft 365 administrators can review supported service locations in:

Microsoft 365 Admin Center → Settings → Org settings → Organization profile → Data location. Microsoft Learn

Consider Applicable Saudi Privacy and Cloud Requirements

Where relevant, organizations should assess requirements under Saudi Arabia’s Personal Data Protection Law (PDPL) and its regulations, particularly when personal data may be transferred outside the Kingdom. SDAIA’s transfer regulation sets requirements around transfers of personal data outside Saudi Arabia. DGP

Organizations within relevant NCA scope may also need to consider the Cloud Cybersecurity Controls (CCC 2-2024). NCA states that CCC 2-2024 addresses cloud cybersecurity from both Cloud Service Provider and Cloud Service Tenant perspectives and includes data-localization-related updates. National Cybersecurity Authority

The exact requirements depend on the organization, data, sector and regulatory scope. Do not assume every Saudi private company has identical compliance obligations.

Common Microsoft 365 Migration Mistakes

Migrating Without an Inventory

Missing users, aliases, business applications or file locations often creates problems after cutover.

Choosing the Wrong Migration Method

IMAP, Google Workspace, Exchange and tenant-to-tenant migrations have different capabilities and prerequisites.

Treating Every Address as a Licensed User

Aliases, shared mailboxes and groups serve different purposes. Design them according to how the business uses each address.

Ignoring Printers, Websites and ERP Applications

Legacy SMTP dependencies frequently become visible only after the old server is removed.

Creating Multiple SPF Records

A domain should have one valid SPF record containing the required legitimate senders. Multiple SPF records can cause SPF failure. Microsoft Learn

Changing DNS Before Microsoft 365 Is Ready

Mailbox provisioning, mail routing and user access should be validated before changing MX records.

Migrating Without a Pilot

A pilot can expose authentication, device, mailbox and application issues before the wider cutover.

Treating Security as a Post-Migration Task

MFA, administrative roles and email security should be planned before users start working in the new environment.

Assuming Migration Is Backup

Migration and recovery serve different purposes.

Cancelling the Source Too Early

Keep the source environment available until validation, remaining synchronization and decommissioning requirements are complete.

Microsoft 365 Migration Checklist for IT Teams

Before Migration

• ☐ Inventory users and mailboxes
• ☐ Identify shared mailboxes, aliases and groups
• ☐ Review mailbox sizes
• ☐ Inventory files and business data
• ☐ Identify website, ERP, printer and SMTP dependencies
• ☐ Review Basic Auth SMTP dependencies for 2026/2027 readiness
• ☐ Choose migration method
• ☐ Verify migration-specific licensing
• ☐ Prepare Microsoft 365 tenant
• ☐ Verify custom domain
• ☐ Plan any tenant-to-tenant domain transfer
• ☐ Create users/groups/mailboxes
• ☐ Plan administrator roles
• ☐ Configure MFA/security baseline
• ☐ Plan SPF, DKIM and DMARC
• ☐ Review DNS TTL
• ☐ Protect critical data
• ☐ Communicate with employees
• ☐ Run a pilot migration

During Migration

• ☐ Monitor migration batches
• ☐ Review failed items
• ☐ Resolve migration errors
• ☐ Validate representative users
• ☐ Perform planned final synchronization
• ☐ Change DNS according to the cutover plan
• ☐ Verify inbound and outbound mail flow
• ☐ Monitor support requests

After Migration

• ☐ Test user accounts
• ☐ Verify shared mailboxes
• ☐ Verify applications and devices
• ☐ Configure Outlook and mobile access
• ☐ Verify OneDrive and SharePoint permissions
• ☐ Validate Teams scope
• ☐ Verify MFA/security controls
• ☐ Verify SPF, DKIM and DMARC
• ☐ Test backup/recovery arrangements
• ☐ Support users
• ☐ Document the final environment
• ☐ Keep the source available until validation is complete
• ☐ Follow supported decommissioning procedures

How NABCO Supports Microsoft 365 Migration in Saudi Arabia

A Microsoft 365 migration can involve identities, email, DNS, security, devices and business applications—not simply copying mail from one server to another.

NABCO can support Microsoft 365 migration projects in areas that match its current technical capabilities, including:

• Migration assessment and planning
• Microsoft 365 tenant preparation
• User and mailbox configuration
• Email migration
• Domain and DNS configuration
• MFA and identity setup
• Microsoft 365 security configuration
• Outlook and device setup
• SMTP and business-application review
• Post-migration testing
• User transition and support

For a source-specific process, link here to your cPanel to Microsoft 365 Migration Guide.

For security planning, link naturally to your Microsoft 365 Security Services page.

Planning a Microsoft 365 migration? Talk to NABCO about your existing environment, users, applications and migration requirements.

Microsoft 365 Migration FAQs

What should be included in a Microsoft 365 migration checklist?

A migration checklist should cover the source environment, users, mailboxes, files, licensing, identities, security, migration method, pilot testing, DNS, applications, user transition and post-migration validation.

Can Microsoft 365 migrate email from cPanel?

Many cPanel mailboxes can be migrated using an IMAP-based approach where the source environment supports it. IMAP migration primarily moves email-folder content; contacts, calendars and tasks need separate consideration. Microsoft Learn

Should we change the MX record before migrating email?

Usually, historical data is prepared or pre-staged before final mail-routing cutover. Mailboxes and Microsoft 365 mail flow should be ready before switching MX.

Can an info@ or sales@ mailbox be a shared mailbox?

Possibly. The correct design depends on whether the address needs an independent mailbox, shared user access or simply another address for an existing mailbox. Shared-mailbox licensing and feature requirements should also be checked. Microsoft Learn

Does IMAP migration move calendars and contacts?

No. Microsoft’s native IMAP migration moves mail-folder content but not contacts, calendars or tasks. Microsoft Learn

Does changing the MX record take effect immediately?

Not necessarily. Cached DNS information may continue directing some senders to the previous server until the existing TTL expires.

Do we need SPF, DKIM and DMARC after migration?

They should be reviewed as part of the email-authentication design. SPF identifies permitted senders, DKIM signs supported outbound mail and DMARC uses SPF/DKIM alignment to apply policy and reporting. Microsoft Learn

Is Microsoft 365 migration the same as backup?

No. Migration moves workloads or data to another environment. Backup and recovery provide separate protection against loss, deletion, corruption or other recovery scenarios.

Is Microsoft 365 data automatically stored in Saudi Arabia?

Do not assume so. As of September 2026, Microsoft’s Microsoft 365 residency documentation still lists Saudi Arabia as a future Local Region Geography. Verify the specific tenant, workload, Product Terms and Data Location Card before making a residency commitment. Microsoft Learn

Final Thoughts

A reliable Microsoft 365 migration checklist begins before the first mailbox or file is copied.

Inventory the current environment, choose the correct migration method, verify licensing, prepare identities and security, test representative users, plan DNS carefully and validate every business-critical application after cutover.

For Saudi businesses, migration planning should also consider data governance, applicable privacy and cybersecurity requirements, branch connectivity and the actual Microsoft 365 data-location commitments available to the organization.

The objective is not simply to move data.

It is to make sure employees, applications and business processes continue working securely after the transition.