How to migrate email to Microsoft 365 from an old Exchange server or Gmail

Short answer: For most small businesses, migrating email to Microsoft 365 takes two to six weeks end to end and follows one of three paths: a cutover migration (best for under 150 mailboxes from Exchange 2013+ or hosted Exchange, everyone moves over a single weekend), a staged migration (legacy Exchange 2010 or larger user counts, mailboxes move in batches), or a Google Workspace migration (use the Microsoft 365 native Google Workspace migration tool or BitTitan MigrationWiz). The actual mailbox copy is usually the easiest part. The hard parts are the MX record cutover, keeping mail flowing during the transition, migrating shared mailboxes and distribution lists correctly, and getting Outlook profiles to re-create cleanly on every endpoint without losing local PST data. Skip the planning and you will spend the next month chasing duplicate emails, missing calendar invites, and one user who still cannot send to the CEO’s old distribution list.

This guide walks through the full email migration project: how to pick the right migration method, what to inventory before you touch anything, the actual DNS and MX record cutover sequence, how to handle shared mailboxes, distribution lists, public folders and calendar permissions, the Outlook re-profiling step that breaks for at least one user every time, and the post-migration cleanup that closes the project for good. It assumes you have already chosen Microsoft 365 as your destination – if you are still deciding, see Microsoft 365 vs Google Workspace for small business first.

Email migration to Microsoft 365 at a glance

Source system	Recommended method	Typical timeline	Notable gotcha
On-prem Exchange 2016 / 2019	Cutover (under 150 users) or Hybrid (over 150)	2 to 4 weeks	Public folders, mail-enabled security groups, cert renewal mid-project
On-prem Exchange 2013	Cutover or Staged	3 to 5 weeks	Last fully supported version for cutover; tooling still works
On-prem Exchange 2010 or older	Staged migration or third-party (BitTitan, CodeTwo)	4 to 8 weeks	Native cutover from 2010 is deprecated; expect tooling friction
Hosted Exchange (GoDaddy, Rackspace, etc.)	IMAP migration or cutover (if exposed)	2 to 4 weeks	Provider-specific export limits, no calendar/contacts via IMAP
Google Workspace	Microsoft 365 native Google Workspace migration tool	3 to 6 weeks	Calendar resource mailboxes, shared drives mapping, MX cutover delay
Generic IMAP (cPanel, ISP mail)	IMAP migration (Microsoft 365 Migration Manager)	2 to 4 weeks	No calendar, contacts, or rules migrate – inbox content only
PST file consolidation	Network upload via AzCopy + Office 365 Import Service	1 to 3 weeks	Free but slow; per-tenant ingestion limits apply

Pick the method that matches your source. Mixing methods (for example, IMAP for inboxes + manual calendar export) creates user confusion and orphaned data. The right answer is whichever single method moves the most data with the least manual cleanup.

What to inventory before you start

Email migrations fail when the project plan is built around mailbox count alone. Mailbox count is the easy number. The hard numbers are everything else.

Mailbox inventory

• Total mailbox count, separated by user mailboxes, shared mailboxes, resource mailboxes (rooms, equipment), and distribution lists (or Google Groups).
• Total mailbox size in GB. M365 mailboxes are 50 GB on Business Standard / Basic, 100 GB on Business Premium and most enterprise plans.
• Largest mailbox size and average mailbox size. A handful of 80 GB mailboxes on Business Standard licenses will not fit.
• Number of mailboxes with active archive mailboxes (online archives), and whether those need to migrate.

Mail flow inventory

• Where does the MX record currently point? Who controls DNS for the domain? If DNS is at the same vendor as your old email host, plan to move DNS first or be prepared for that vendor to drag their feet on a cutover.
• Are there SPF, DKIM, and DMARC records currently published? You will rewrite all three for Microsoft 365.
• Are there inbound connectors (third-party security gateway like Proofpoint, Mimecast, Barracuda)? Those need to be reconfigured for the new tenant or removed.
• Are there outbound connectors (CRM sending mail through Exchange, line-of-business apps using SMTP)? Every one of these will break at cutover unless it is reconfigured to authenticate to Microsoft 365 SMTP or migrated to Microsoft Graph.
• Are there transport rules (mail flow rules) on the source? Disclaimer footers, encryption rules, blocking rules. Each one needs to be re-created in Exchange Online if it is still needed.

Identity inventory

• Are user accounts in Active Directory on-prem, Entra ID (Azure AD) only, or a mix? If on-prem AD exists and will continue to exist after migration, you need Entra Connect (formerly Azure AD Connect) configured to sync identities, and you need to decide between password hash sync, pass-through authentication, or federation.
• For Google Workspace migrations: are users currently signing in with Google credentials elsewhere (SSO into other apps)? Those SSO integrations need to repoint to Entra ID.

Endpoint inventory

• How many endpoints (Windows, Mac, mobile)? Outlook profiles need to be re-created on each one, or in some cases reset.
• Are users on Outlook 2013 or older? Outlook 2013 reaches end of support for connecting to Exchange Online – get them upgraded before the migration, not during.
• Are there mobile devices with Exchange ActiveSync profiles configured? Those need to be removed and re-added after cutover.

Calendar and resource inventory

• Number of room mailboxes and equipment mailboxes. Migrate these as resource mailboxes in M365.
• Shared calendars with custom permissions. Those permissions do not always survive migration cleanly and may need to be re-applied.
• Public folders on Exchange. Public folders are the most common migration disaster – plan to retire them, migrate to shared mailboxes or SharePoint, or use a Microsoft 365 public folder migration (which exists but is rough).

This inventory step is also one of the items the cloud migration checklist for small business calls out as easy to skip. Skip it and the issues come up at cutover when there is no time to deal with them.

Picking the right migration method

Cutover migration (Exchange to M365)

A cutover migration moves all mailboxes from on-prem Exchange or hosted Exchange to Microsoft 365 in a single batch. Officially supported up to 2,000 mailboxes, in practice it works well up to about 150 and gets risky beyond that.

When it fits:

• Exchange 2013, 2016, 2019, or hosted Exchange exposed via Outlook Anywhere / EWS.
• Under 150 mailboxes.
• You can tolerate a single cutover weekend where mail flow shifts.
• You do not need to keep on-prem Exchange running long term.

When it does not fit:

• Exchange 2010 (deprecated for cutover – use staged or third-party).
• Over 150 mailboxes (cutover gets unstable at scale).
• You need on-prem Exchange to coexist long term (use hybrid).

How it works: You connect Microsoft 365 to the on-prem Exchange via the migration endpoint, run an initial sync of all mailboxes (this can take days – it is a full copy), then on cutover day you change the MX record, run a final delta sync, and decommission the source.

Staged migration

Staged migration moves mailboxes to M365 in batches over several weeks. Designed originally for Exchange 2003 and 2007 (both retired) and still available for Exchange 2010. Most modern projects use cutover or hybrid instead, but staged is the right answer for some legacy environments.

When it fits:

• Exchange 2010 source (cutover from 2010 is deprecated).
• You want to migrate users in groups (department by department) rather than all at once.
• You have a lot of mailboxes and a hybrid is overkill.

The trade-off: during the staged migration, some users are on the source and some are on M365 simultaneously. Mail flow gets routed via a coexistence configuration. It is more complex to operate and more expensive to set up than cutover.

Hybrid migration

A hybrid configuration lets on-prem Exchange and Microsoft 365 coexist long term. Free/busy calendar lookups work across both, mail flow is integrated, and you can move mailboxes one at a time.

When it fits:

• Over 150 mailboxes.
• You want to move users in waves (week-by-week, no big-bang cutover weekend).
• You need on-prem Exchange to keep running for a while (for compliance reasons, or because some legacy app depends on it).
• You have Exchange 2013 or newer.

When it does not fit:

• Small businesses that just want to be done with on-prem Exchange. Hybrid adds operational complexity for the duration that on-prem stays alive.

Hybrid requires running the Exchange Hybrid Configuration Wizard, which has gotten significantly better but still has edge cases. Plan for an experienced engineer to handle this part.

Google Workspace to Microsoft 365 migration

The path for a Google Workspace source is fundamentally different from an Exchange source. There is a native Microsoft 365 Google Workspace migration tool that handles mail, calendar, and contacts – this has matured significantly and is the right starting point for most projects. For more complex environments (calendar resource mailboxes, large shared drives, retention complexity), third-party tools like BitTitan MigrationWiz or CloudM can be more reliable.

The major gotchas on Google Workspace migrations:

• Calendar resource mailboxes (rooms, equipment): the native tool handles these but requires correct Google Calendar resource configuration. Validate in pilot.
• Shared drives are a separate migration project from email. They map to SharePoint, not OneDrive. See how to migrate a file server to SharePoint and OneDrive for the file side.
• Email aliases: Google’s alias model (additional email addresses on a single account) maps cleanly to M365’s proxy addresses, but make sure aliases come across with the mailbox.
• Forwarding rules: Google forwarding rules do not always migrate. Audit and re-create.
• Vacation / out-of-office responses: do not migrate. Tell users to re-set them after cutover.
• Service accounts (the no-mailbox account that sends from your CRM): map these to M365 shared mailboxes or service principals, not user mailboxes.

IMAP migration

IMAP migration is the catch-all for sources that are not Exchange and not Google Workspace – cPanel mailboxes, ISP-hosted mail, generic IMAP servers. It only migrates inbox content. Calendar, contacts, rules, and folder permissions do not migrate over IMAP. Plan to handle those manually or with separate tools.

The Microsoft 365 Migration Manager (formerly the migration dashboard) supports IMAP natively. You provide source server credentials per mailbox or via a CSV, point at the destination, and it copies. Slow but reliable for what it does.

The DNS and MX cutover sequence

This is where most email migrations either go cleanly or go sideways. The MX record is the public DNS pointer for “where does mail for this domain go?” When you change it, the entire internet starts routing your mail to the new destination. Get this wrong and mail bounces for hours.

Pre-cutover DNS prep (1 to 2 weeks before)

• Lower your MX record TTL to 300 seconds (5 minutes) or 600 seconds. The default TTL is often 3600 (1 hour) or higher. Lower it at least one full TTL period before cutover so that DNS resolvers worldwide pick up the new low value before the actual cutover.
• Provision SPF, DKIM, and DMARC records for M365 but do not publish them yet (or publish them in test/none mode).
• Add the M365 tenant verification TXT record for your domain (this is required to add the domain to your tenant; do this early).
• Configure inbound and outbound connectors if you are using a third-party security gateway.

Cutover sequence (cutover day)

1. Run the final delta sync of mailboxes. For cutover migration, this is the last incremental copy. For staged or hybrid, this is moving the final batch.
2. Change the MX record to point at your M365 tenant’s MX endpoint (typically <tenant>.mail.protection.outlook.com).
3. Update SPF to include spf.protection.outlook.com and remove the old source. SPF is one record per domain – misconfiguring it is the #1 reason post-cutover mail flow breaks.
4. Update DKIM to publish the M365 DKIM keys (CNAMEs to selector1._domainkey and selector2._domainkey).
5. Update DMARC if you have one. Start in p=none mode to monitor before tightening.
6. Update Autodiscover. Either delete the old autodiscover CNAME or point it to autodiscover.outlook.com. This is what makes Outlook automatically find the new server when users open it for the first time after cutover.
7. Run mail flow tests immediately. Send mail in (from an external account), send mail out (to an external account), reply to a previous thread, send a calendar invite, accept a calendar invite. If any of these fails, you have a configuration problem to fix in the first hour, not the first day.

Post-cutover DNS hygiene (1 week after)

• Raise the MX TTL back to 3600 (1 hour) or higher once you are confident.
• Tighten DMARC to p=quarantine then p=reject over the following weeks.
• Decommission the old DNS records that pointed at the source system.

The full sequence sounds simple, but the order matters. Changing MX before SPF means mail flows in correctly but outbound mail from M365 may be marked as spam by recipients. Changing SPF without including M365 means M365-sent mail fails SPF and gets flagged. Changing Autodiscover too early means Outlook clients cannot find the source server in the final hours before cutover.

Migrating shared mailboxes, distribution lists, and aliases

User mailboxes are usually the easy part. Shared mailboxes, distribution lists, and aliases are where the migration tooling stops doing the work for you.

Shared mailboxes

Shared mailboxes in Exchange and Google Workspace map to shared mailboxes in Microsoft 365. The migration tool will move the content. What does not always migrate cleanly:

• Full Access permissions (who can open the mailbox).
• Send As permissions (who can send mail appearing to come from the shared address).
• Send on Behalf permissions (who can send mail with “on behalf of” header).

Plan to re-apply these permissions in M365 after migration. Document the source-side permissions before the migration starts so you can re-create them. See how to set up a shared mailbox in Microsoft 365 for the M365-side configuration.

Distribution lists vs Microsoft 365 Groups

This is one of the most common migration design decisions. Distribution lists in Exchange / Google Groups can map to:

• Distribution lists in M365 (simple, traditional, no shared workspace).
• Mail-enabled security groups (used to grant permissions in addition to distribution).
• Microsoft 365 Groups (newer, includes shared inbox, calendar, SharePoint site, Teams integration).
• Shared mailboxes (if the use case is really “a single inbox several people watch”).

Microsoft is steering everyone toward M365 Groups, and they are the right answer for most active collaboration use cases. But blanket-converting every distribution list to a Group is wrong – some are just announcement lists where a Group’s overhead is unnecessary. Decide per list. See Microsoft 365 Groups vs distribution lists vs shared mailboxes: what to use when for the decision framework.

Aliases and proxy addresses

Every additional email address a user receives mail at (jane.smith@, jane@, j.smith@) is an alias. In M365 these are called proxy addresses on the mailbox. The migration tool usually moves these correctly, but validate in pilot for at least 5 users. Missing aliases means missing mail.

The Outlook re-profiling step (and why it bites)

After cutover, every Outlook desktop client needs to either auto-detect the new mailbox location (if Autodiscover is correctly pointed at M365) or have its profile manually reset. This is where post-cutover help desk load comes from.

The clean version: user opens Outlook, Autodiscover finds the new server, Outlook prompts for credentials (or completes silently if the device is Entra-joined), and the new mailbox starts downloading.

The not-clean version: Outlook still has cached endpoints from the old server, Autodiscover does not work because the old DNS is still cached locally, and the user gets cryptic credential prompts in a loop. Fix: delete the Outlook profile from Mail (Microsoft Outlook) in Control Panel, restart Outlook, let it create a new profile.

What complicates this:

• Local PST files. Some users have years of email in PST archives attached to their Outlook profile. Re-creating the profile drops those attachments. Document the PST locations before cutover, re-attach after.
• Outlook signature settings. Stored in %APPDATA%\Microsoft\Signatures – survive profile reset, but worth confirming.
• Cached mode and offline files. The OST file from the old mailbox stays on disk after profile reset. Delete the old OST to free space. New cached mode download can take hours for large mailboxes on slow connections.
• Mobile devices. Native iOS/Android mail apps need the old account removed and re-added. Outlook for iOS/Android usually just works with M365 modern auth.

For Macs running Outlook for Mac: similar process, but the profile management is different. Plan for a Mac-specific runbook step.

Common email migration problems and how to avoid them

Some of these are universal, some are source-specific. Almost all of them are predictable with a real pilot.

Mail flow loops or NDRs immediately after cutover

The MX record cut over but a backup MX or transport rule somewhere is still routing through the old server. Mail bounces between the two and times out. Audit DNS thoroughly the day before cutover. Remove old MX backups. Check for “send connector” or “outbound smart host” entries on the source.

SPF failures (mail going to spam after cutover)

You forgot to update SPF, or you updated it but a third-party sending service (mailing list software, CRM, ticketing system) is still hardcoded to send via the old domain. Find the third-party senders, add their IPs / include records to SPF, or move them to send via Microsoft 365 SMTP (with proper authentication).

Calendar invites disappearing or duplicating

Calendar invites from before the cutover sometimes do not survive the migration cleanly, especially recurring meetings with many attendees and exceptions. The tooling has gotten much better, but plan for a few users to need calendar fixups in the first week. Communicate this expectation upfront.

Distribution list members not migrated

Distribution lists came across, but the membership did not. Common with hosted Exchange providers that handled DLs differently from on-prem. Validate DL membership immediately post-cutover with a script that compares pre-migration export to post-migration state.

Service accounts and CRM email broken

Your CRM was sending email through the on-prem Exchange via a hardcoded SMTP relay. Cutover happens, CRM continues to try the dead relay, sales team has no idea their auto-emails stopped sending. Audit every service that authenticates to your email system, document the credentials and target server, plan for each one to be reconfigured at cutover.

Public folders breaking everything

You decided to migrate public folders. Now you are stuck for a week trying to get them to work. Public folder migrations are notoriously fragile. Strong recommendation: retire public folders during migration. Move public folder content to shared mailboxes, SharePoint document libraries, or Teams channels. The migration becomes dramatically easier.

Mobile device push notifications stop working

Cutover happens, mobile users do not get notifications until they remove and re-add the account. Communicate this upfront. Send instructions the day before. Have help desk ready for the first morning.

Slow initial mailbox download on user devices

Cutover went smoothly, MX flipped, Outlook re-profiled – but a 50 GB mailbox in cached mode is going to take all day to download on a normal home internet connection. For users with very large mailboxes, consider doing the initial cached mode download from the office before sending them home, or temporarily switch them to Online Mode (no local cache) until they are on a fast connection.

Post-migration cleanup

The migration is not done at cutover. The cleanup phase is where you close the project for good.

Validate every workload

• Send and receive test mail from each domain, including aliases.
• Verify shared mailbox access for every shared mailbox.
• Verify distribution list membership.
• Verify calendar permissions and resource booking work.
• Verify mobile device sync works.
• Verify mail flow rules (transport rules) are functional.
• Verify connectors (inbound from security gateway, outbound to legacy systems) are working.

Decommission the source

This is the part that gets skipped. Do not skip it. A running on-prem Exchange after migration is an attack surface, an unnecessary license cost, and a source of future confusion when someone accidentally points a service at it.

• 30 day standby period: leave the source up but block all inbound mail flow. This catches any service or user account you missed that needs the old system.
• Final mailbox export: export each source mailbox to PST as a final archive, store in encrypted long-term storage.
• Decommission: shut down Exchange services, remove the AD attributes, remove DNS entries (Autodiscover, MX backup, internal SRV records), uninstall Exchange properly, remove from monitoring.
• Hardware: secure-wipe the storage, dispose per the same data destruction policy used in the cloud migration checklist for small business.
• Licensing: cancel hosted Exchange or Google Workspace subscriptions only after the 30-day standby is complete.

Tighten DMARC

You started DMARC at p=none. Once you have monitored the DMARC reports for 2 to 4 weeks and confirmed all legitimate mail is aligning, move to p=quarantine, then to p=reject. This is a long-term security improvement that pays dividends.

Train users on what changed

• New Outlook profile (already happened).
• New webmail URL (outlook.office.com or office.com).
• New mobile app recommendation (Outlook for iOS/Android, not native mail).
• Where to find shared mailboxes in the new environment.
• Calendar booking in M365 (works the same, but resource mailboxes show up differently).
• For Google Workspace migrations: M365 has different naming for everything. A 30-minute training session saves the help desk hundreds of tickets.

Lock down the new tenant

You just inherited a fresh M365 tenant with default security. Do not stop at “the migration worked.” Apply the security baseline before anything else: MFA on all accounts, conditional access policies, audit logging enabled, modern auth enforced, legacy auth blocked. See Microsoft 365 security hardening for small business for the exact configuration. The migration project is the right time to do this – users are already adjusting to the new system, and the security baseline becomes part of “how we use M365” rather than a later change.

Plan for backup

Microsoft 365’s native retention is not a backup. The day after the migration is the right time to set up third-party Microsoft 365 backup, before users start generating new content that you cannot recover. See Microsoft 365 backup: why built-in retention is not enough for what to look for in a backup product and why this matters.

Picking the right Microsoft 365 license tier

The license you pick matters for what features users get post-migration. Most SMBs land on Business Standard ($12.50/user/month) for the basics or Business Premium ($22/user/month) if they need the security features (Defender for Office 365, Defender for Business, Intune, conditional access).

Migration itself does not require a specific license tier – Business Basic at $6/user/month works for the migration. But if you migrate to Basic and then upgrade to Premium later, you have to deal with the license-tier change separately. Pick the license you actually want for the long term before migration, not after. See Microsoft 365 licensing explained for small business for the full breakdown.

The other licensing pitfall: post-migration, businesses often discover they overprovisioned licenses for the migration (“we need them all to be on Business Premium for the cutover”) and then forget to right-size. See how to reduce your Microsoft 365 costs without losing features for the post-migration license review.

Common email migration mistakes

1. Skipping the pilot. Picking 5 to 10 representative users (one from each department, one with a giant mailbox, one with shared mailbox access, one with a mobile device, one power user with rules and signatures) and migrating them a week before the rest. Every issue you find in the pilot is one you will not be debugging at 9am on Monday with 50 users blocked.

1. Doing the migration on the same weekend you change something else. Do not also upgrade Outlook, change ISPs, or roll out new laptops the same weekend. One change per cutover.

1. Not lowering the MX TTL ahead of time. If your MX TTL is 3600 (1 hour) and you change it on cutover day, mail can be misdirected for up to an hour while DNS propagates. If you lowered it to 300 a week before, propagation is 5 minutes.

1. Forgetting third-party senders. CRMs, mailing list software, ticketing systems, monitoring alert senders, e-commerce platforms – any system that sends mail “from” your domain. Each one needs reconfiguring or SPF inclusion.

1. Not communicating with users. Users need to know what is happening, when, and what they need to do. A 3-paragraph email a week before, a 1-paragraph reminder the day before, and a short instructional email cutover morning. Plus help desk on standby.

1. Trying to migrate public folders. Just retire them. The pain is rarely worth it.

1. Skipping the source decommission. The old system is an unnecessary cost and a security risk. Plan it in.

1. Skipping the post-migration security baseline. You just got a clean M365 tenant. The day after migration is the right time to enforce MFA, conditional access, and modern auth – not three months later.

1. Underestimating the help desk load on day one. Plan for 30 to 50% of users to need some kind of touch on the first day post-cutover – mostly Outlook profile prompts, mobile re-add, or “where did my [thing] go” questions.

1. Choosing the wrong source license tier (Google Workspace specifically). Some Google features that businesses rely on (Vault retention, advanced calendar resource booking, shared drives) require equivalent M365 features that are only on Business Premium or above. Audit before assuming Business Standard is enough.

How long does email migration actually take

Migration scope	Typical timeline
10 to 25 mailboxes, simple Exchange or hosted	2 to 3 weeks
25 to 100 mailboxes, on-prem Exchange with shared mailboxes and DLs	3 to 5 weeks
100 to 250 mailboxes, hybrid with phased move	6 to 10 weeks
Google Workspace to M365, any size	Add 1 to 2 weeks for Google-specific gotchas
Public folders included	Add 2 to 4 weeks (or skip them)
Heavy third-party integration audit	Add 1 to 3 weeks

Roughly half of that timeline is planning, inventory, and DNS prep. The actual mailbox copy is usually days. The cutover weekend itself is one weekend. The post-cutover validation and cleanup is another 1 to 2 weeks.

If a vendor quotes “we’ll migrate your email next weekend” with no inventory or planning, that is a red flag – the same one called out in how much does cloud migration cost for a small business. Cheap and fast usually means cleanup costs landing on the customer afterward.

How Sequentur can help

If you are planning an email migration to Microsoft 365 and want help with any part of it – or just a second pair of eyes on your runbook – schedule a call.