Skip to content
Devsoft

Article

Three checks before you migrate Exchange to Microsoft 365

The migration tooling matters less than the three things that decide whether cutover is uneventful or painful: your DNS, your shared mailboxes, and your distribution lists.

By Devsoft Solutions

Most Exchange migrations to Microsoft 365 go fine. The ones that go badly almost always go badly for the same three reasons. None of them are about the migration tool you pick. They are about the parts of the environment that the tool does not touch.

If you are about to start a tenant assessment or you are mid-cutover and something feels off, these are the three places to look.

1. DNS, and who actually controls it

The DNS cutover at the end of an Exchange migration is the single most error-prone step. The tool moves the mailboxes. DNS decides whether mail flows.

Before the migration starts, confirm three things in writing:

  • Who owns the registrar account, and who has credentials to make changes
  • Where the MX, SPF, DKIM, and DMARC records currently live
  • Whether the DNS provider is the same as the registrar, the hosting provider, or someone else entirely

We have seen cutovers stall because nobody had the password to the right account at 5 p.m. on a Friday. Do this discovery a week before you need it, not the morning of cutover.

2. Shared mailboxes, public folders, and distribution lists

The mailboxes for individual users move cleanly. The shared resources are where things break.

For each shared mailbox, decide whether it stays a shared mailbox in Exchange Online, becomes a Microsoft 365 group, or gets deprecated in favor of a Teams channel. The right answer depends on the use case, and “we will figure it out post-cutover” is not a plan.

For distribution lists, audit which ones are still in use, which are abandoned, and which need to become dynamic groups. Stale distribution lists are a low-effort find that always pays back.

For public folders, ask whether anybody actually uses them anymore. The honest answer is often “no,” and the migration is a good chance to retire them rather than carry the technical debt forward.

3. Calendar permissions and delegations

Calendar permissions and mailbox delegations are easy to lose in a migration if you do not catalog them first. An executive whose assistant has full access to their calendar will notice within an hour of cutover if that access is missing.

Export the current state with Get-MailboxPermission and Get-MailboxFolderPermission before you migrate. Compare against the new state after cutover. Restore anything that did not carry over.

Do these three checks early, document the answers, and the tool you pick for the actual migration becomes the boring, easy part.