Microsoft 365 migration checklist for small businesses

Moving a small business to Microsoft 365 is not technically difficult, but it is unforgiving of skipped steps. A missed DNS record breaks email, a forgotten shared mailbox strands an invoice inbox, and a migration announced by email on the morning it happens creates a queue at the IT desk. This checklist covers the phases Dig IT works through on every migration for businesses across Hertfordshire, west Essex and London, with notes on the three most common starting points.

Phase 1: discovery and licensing

Most migration problems are discovery problems in disguise. Before touching the tenant, build a complete picture of what exists today.

• List every mailbox, including shared, resource and forwarding-only addresses. Aliases and distribution lists are the ones most often missed.
• Record mailbox sizes. Anything over 50 GB needs an archive plan because that is the standard Business plan mailbox limit.
• Identify every domain that sends or receives email, including old trading names still in use on stationery.
• Map file locations: shared drives, Google Drive, Dropbox, a file server, personal desktops. Decide what goes to SharePoint, what goes to OneDrive and what is archived.
• Find every system that sends email through your domain: accounting software, a website contact form, a scanner, a CRM, an alarm panel. Each one needs reconfiguring or an SMTP relay.
• Note devices per user and their operating system versions. Windows 10 is out of support, and very old Office versions will not connect to Exchange Online.
• Choose licences. The Business Basic, Standard and Premium comparison sets out the differences. Mixing plans per user is normal.

The output of this phase is a spreadsheet that becomes the migration plan. If you cannot fill in every column, you are not ready to start.

Phase 2: tenant and DNS preparation

With the inventory done, build the destination before moving anything into it.

1. Create the Microsoft 365 tenant, choose the UK as the data location, and set up the first global administrator with MFA and a separate break-glass account.
2. Add and verify each domain. Microsoft gives you a TXT record to prove ownership. This does not affect mail flow yet.
3. Create users, shared mailboxes, distribution groups and Microsoft 365 groups from the inventory. Assign licences.
4. Build the SharePoint structure and Teams before files arrive, so content lands in a designed layout rather than a copy of the old chaos. Dig IT's SharePoint and Teams service covers this design work.
5. Apply the security baseline now, while the tenant is empty: MFA for everyone, legacy authentication blocked, admin roles limited. The Microsoft 365 security settings checklist lists the settings.
6. Lower the TTL on your existing MX and related DNS records to 300 seconds, at least 48 hours before cutover, so the change propagates quickly on the day.

The DNS records you will need

SPF, DKIM and DMARC are not optional extras. Without them your outbound mail is more likely to land in spam, and your domain is easier to spoof. Microsoft documents the exact records on Microsoft Learn, and Dig IT's email security service covers the ongoing configuration.

Phase 3: pilot

Never migrate everyone at once without proof. Pick three to five users who represent the business: one heavy Outlook user, one who works mostly on a phone, one from finance with shared mailbox access, and ideally one director who will be first to complain if something is wrong.

Migrate their mailboxes and files, reconfigure their devices, and let them work for two or three days. What you are looking for:

• Does Outlook connect automatically, or does it need manual profile setup?
• Do calendar invites, recurring meetings and delegated calendars come across intact?
• Do the shared mailboxes open and send correctly?
• Do mobile devices receive email and calendar without reinstalling apps?
• Do any line-of-business applications break because they expected the old mail server?

Fix everything the pilot surfaces before scheduling the main migration. A problem that affects one pilot user will affect twenty on cutover day.

Phase 4: migration and cutover by source platform

The sequence is the same for every platform: copy data in the background, switch DNS, run a final sync, reconfigure devices. The tools differ.

From Google Workspace

Microsoft's Google Workspace migration in the Exchange admin centre uses a Google service account to copy mail, calendar and contacts for a batch of users. Google Drive content moves through Migration Manager in the SharePoint admin centre, which converts Google Docs, Sheets and Slides to Office formats on the way. Check complex spreadsheets with scripts or unusual formulas afterwards, and warn staff that Google-specific features such as Apps Script will not survive. The Microsoft 365 vs Google Workspace comparison covers what changes for users day to day.

From hosted IMAP email

Many small businesses start on a web host's email package. IMAP migration in Microsoft 365 copies mail folders using each user's credentials or an admin login, but IMAP carries no calendars, contacts or tasks. Those need exporting separately, usually as CSV, ICS or a PST from an existing Outlook profile. Expect throttling from the old host on large mailboxes, and plan for the copy to take longer than the data size suggests.

From on-premise Exchange

For businesses with up to a couple of hundred mailboxes, a cutover migration moves everything in one batch and retires the server. Larger or more cautious organisations use a hybrid configuration, where the server and Microsoft 365 coexist and mailboxes move gradually. Hybrid is genuinely more complex and needs a valid public certificate, Entra Connect for identity sync, and a plan for eventually decommissioning the server. Do not switch off the old Exchange server until every mailbox, public folder and application relay has been confirmed in the cloud.

Cutover day

1. Run a final incremental sync of all mailboxes.
2. Change the MX, Autodiscover and SPF records.
3. Confirm inbound mail arrives in Microsoft 365 by sending from an external address.
4. Reconfigure Outlook profiles and mobile devices, either by hand for small teams or through Intune for Premium tenants.
5. Point every application relay at the new SMTP settings.
6. Keep the old system readable for at least two weeks in case something was missed.

Phase 5: staff communication and post-migration

Technical success and user experience are different things. A migration that works perfectly but was not explained still generates a bad week.

Before: tell staff the date, what will change (new login, new Outlook profile, new file locations), what will not change (their email address), and who to call. A short walkthrough of OneDrive, Teams and where files now live saves hours of support calls.

On the day: have someone available in person or on a call for the first two working hours. Most issues are password resets and phone reconfiguration, and they cluster in that window.

After:

• Enable DKIM, confirm it is signing, then publish a DMARC record.
• Switch on the third-party backup. The built-in retention windows are not a backup, as does Microsoft 365 back up your data explains, and the Microsoft 365 backup service can start on the same day as cutover.
• Review who has access to which shared mailboxes and SharePoint sites. Migrations copy old permissions, including ones that should have been removed years ago.
• Update the new-starter and leaver process so future accounts are created and closed in Microsoft 365 rather than the old system.
• Cancel the old subscription once the retention period has passed and you have a verified export.

What to do next

If you are planning a move from Google Workspace, a hosted email package or an ageing Exchange server, Dig IT's Microsoft 365 migration service runs every phase above, including the DNS work, the pilot and the staff communication. To talk through your starting point with an engineer, get in touch.