Microsoft 365 Migration Checklist for Small Businesses

Before You Start the Migration

• [ ] Document the current email environment: number of mailboxes, total data size, email client versions in use
• [ ] Identify any shared mailboxes, distribution lists, and room/resource accounts
• [ ] Check domain DNS access — you will need to add and modify DNS records during migration
• [ ] Confirm your Microsoft 365 subscription plan is appropriate (Business Basic for email-only; Business Standard or Premium if desktop apps and security features are needed)
• [ ] Plan the migration during a lower-activity period — a weekend or start of a slow week
• [ ] Communicate with staff about the migration timeline and what will change for them

DNS and Domain Preparation

• [ ] Confirm you have admin access to your domain registrar (where your domain is registered) and DNS provider
• [ ] Verify your domain in Microsoft 365 admin centre before starting email migration
• [ ] Identify all current DNS records (MX, SPF, DKIM) and document them before any changes
• [ ] Plan the DNS cutover — this is the point at which email starts flowing to Microsoft 365

Mailbox Migration

• [ ] Choose migration method:

• [ ] Run pre-migration checks in Microsoft 365 admin centre to identify any issues
• [ ] Start mailbox migration — email continues to flow to old system during this phase
• [ ] Verify all mailboxes and data are present in Microsoft 365 before DNS cutover

DNS Cutover

• [ ] Update MX records to point to Microsoft 365 (mail.protection.outlook.com)
• [ ] Update SPF record to include Microsoft 365 sending IPs
• [ ] Enable DKIM signing in Microsoft 365 Security centre
• [ ] Configure DMARC record (start with p=none if this is your first DMARC deployment, move to p=reject once mail flow is confirmed)
• [ ] Allow up to 48 hours for DNS propagation — test mail flow from external addresses

Client Configuration

• [ ] Configure Outlook on all desktops (use autodiscover — should require only email and password)
• [ ] Configure mobile devices (iOS Mail / Outlook app)
• [ ] Verify shared mailboxes are accessible from Outlook
• [ ] Test calendar and contacts access
• [ ] Test email sending and receiving from within and outside the organisation

Post-Migration Security Configuration

• [ ] Enable MFA for all users (required — should not be optional)
• [ ] Configure Conditional Access policies if on Business Premium
• [ ] Configure Microsoft Defender for Office 365 (anti-phishing, safe links, safe attachments) if on Business Premium or higher
• [ ] Configure email archiving and retention policies
• [ ] Configure litigation hold or in-place hold for regulated industries

After Migration — One Week Check

• [ ] Confirm all staff are successfully using Microsoft 365 for email
• [ ] Confirm no email is still routing to the old system
• [ ] Decommission old email server or cancel old email hosting subscription
• [ ] Document the new environment (DNS records, admin accounts, user list)

Why Microsoft 365 Migrations Go Wrong

Most Microsoft 365 migration problems are not technical failures — they are planning failures. Understanding the most common causes of troubled migrations helps avoid them.

Undiscovered legacy systems. Many businesses have applications, automated processes, or integrations that connect to email or file storage in ways that are not immediately apparent. A line-of-business application that sends email alerts, an accounting platform that generates reports via email, an automated backup that emails logs — these all need to be discovered and considered before migration.

Incorrect MX record timing. Cutting over email (changing the MX records) before the Microsoft 365 tenancy is fully configured means email starts delivering to the new environment before it is ready to receive it. Email sent during this window may be lost or undeliverable.

Incomplete licence planning. Starting the migration with too few licences, or the wrong plan tier for some users, causes problems mid-migration when users cannot be provisioned correctly.

Outlook profile confusion. After email migration, users' Outlook applications still have the old profile configured. Until the profile is updated, Outlook is connecting to the old email system (which is no longer receiving new email). Staff think Outlook is working but they are missing email.

Missing email archive or historical data. If the old system has a large mailbox or email archive, migrating only recent email and leaving historical data behind creates a split that causes ongoing frustration.

Pre-Migration: The Environment Assessment

Before beginning a Microsoft 365 migration, complete a structured environment assessment:

Current email system. What is the current mail server or hosted email service? How many mailboxes? What is the approximate total data size?

Domain configuration. Who manages the domain and DNS? Do you have access to make DNS changes? Are there existing SPF, DKIM, or DMARC records that will be affected?

Shared mailboxes and distribution groups. List all shared mailboxes (info@, accounts@, support@) and distribution lists (all@, team@). These need to be recreated in Microsoft 365.

Applications and integrations using email. What applications send email? What applications connect to Exchange or IMAP for receiving email? Document every integration.

Calendars and contacts. Are shared calendars in the current system? If so, how are they managed and how will they be migrated?

OneDrive and SharePoint scope. If the migration includes file migration (from a file server, NAS, or Google Drive), what is the total data size and folder structure? What permissions need to be preserved?

The Migration Sequence That Minimises Disruption

Week 1: Tenancy setup.

• Create the Microsoft 365 tenancy
• Set up the domain in the admin centre (verify domain ownership)
• Create all user accounts, shared mailboxes, and distribution groups
• Configure Security Defaults and MFA
• Configure email settings (transport rules, spam filter, DMARC/DKIM)
• Do NOT change MX records yet

• Install Microsoft 365 apps on all devices
• Set up Outlook profiles connecting to Microsoft 365 accounts (while old mail still delivers to the old server)
• Confirm Teams and SharePoint are accessible
• Test all integrations with the new tenancy

• Run final email migration tool pass to bring historical email into Microsoft 365
• Change MX records to point to Microsoft 365 (allow 24-hour propagation)
• Change SPF records to authorise Microsoft 365 for sending
• Enable DKIM in Microsoft 365

• Confirm email is flowing correctly into Microsoft 365 mailboxes
• Confirm all applications are sending and receiving correctly
• Confirm Outlook is configured correctly on all devices
• Monitor for any missed integrations or applications still attempting to connect to the old server

Specific Migration Scenarios

Google Workspace to Microsoft 365. Microsoft provides a Google Workspace migration tool in the Microsoft 365 admin centre. Email, contacts, and calendar data migrate. Google Drive data requires a separate migration tool (SharePoint Migration Tool with Google Drive as the source, or a third-party tool). Expect user adjustment time — the applications are different and users need orientation.

Hosted email (cPanel, Plesk) to Microsoft 365. Relatively straightforward — IMAP migration using the Microsoft migration tool, then DNS changes. No complex integration dependencies in most cases.

On-premise Exchange to Microsoft 365. The most complex scenario. Requires Hybrid configuration or a phased cutover. For small businesses on Exchange 2013–2019, a staged migration over several weeks allows departments to move in batches. Exchange 2010 and earlier require careful planning as hybrid configuration has limitations.

Netluma IT manages Microsoft 365 migrations for SE Queensland businesses. Call 1300 521 162 to discuss your specific situation and get a migration plan.

Netluma IT manages Microsoft 365 migrations for SE Queensland businesses. Call 1300 521 162 to plan your migration.