Download Buy Now

Office 365 Migration: Types, Methods and Complete Planning Guide

If you've been asked to plan an Office 365 migration, the first thing you'll notice is that Microsoft doesn't give you one single path. There's cutover migration, staged migration, hybrid migration, and IMAP migration — and picking the wrong one for your environment can cause weeks of rework.

This guide breaks down every Office 365 migration method in plain language. By the end, you'll know exactly which method fits your organization, what each step involves, and what to check before you start. If you're already past the planning stage and need the actual migration tool, head over to the EdbMails Office 365 migration tool page.

Types of migration Office 365

What Is Office 365 Migration?

At its core, Office 365 migration means moving your organization's email data — mailboxes, calendars, contacts, and folders — from wherever they currently live into Microsoft 365.

That source could be an on-premises Exchange server your company has been running for years. It could be another Microsoft 365 tenant after a company merger. It could be Google Workspace, or a hosted email provider like GoDaddy or Rackspace. The destination is always Office 365, but the route you take to get there depends entirely on where you're starting from.

Regardless of the method, every Office 365 migration goes through three stages:

Stage 1: Pre-migration planning. This is where most migrations succeed or fail. You audit your existing mailboxes, verify your DNS records, assign Microsoft 365 licenses to users, and decide which migration method to use. Skipping this stage is the number one reason migrations go wrong.

Stage 2: Data migration. Mailbox data moves from the source environment to Office 365, either all at once or in batches, depending on the method. During this stage, users typically continue working normally on the source system.

Stage 3: Post-migration cutover. Once migration is confirmed complete, you switch your domain's MX records to route incoming mail to Office 365, update Outlook profiles for your users, and decommission your old mail infrastructure.

The most common Office 365 migration scenarios organizations run into are:

On-premises Exchange Server to Office 365
Office 365 tenant to tenant (cross-tenant migration after mergers or rebranding)
Google Workspace or G Suite to Office 365
IMAP servers such as Gmail, Zimbra, Zoho, and cPanel to Office 365
Legacy PST file archives to Office 365
Office 365 mailboxes back to on-premises Exchange
Office 365 mailboxes exported to PST for backup or compliance

The Four Types of Office 365 Migration

Microsoft officially supports four migration methods. Each one was designed for a specific combination of organization size and source environment. Here is what you need to know about each one.

1. Cutover Migration

Think of cutover migration as the "move everything at once" approach. You set a migration date, move all your mailboxes to Office 365 in a single batch, update your MX records, and you're done. No phasing, no batches, no hybrid infrastructure.

Microsoft supports up to 2,000 mailboxes with this method, but realistically recommends it only for organizations with fewer than 150 mailboxes. Beyond that, a single batch takes long enough that users experience noticeable disruption.

Best for: Small businesses moving from any version of on-premises Exchange (2003 through 2019) to Office 365.

What gets migrated: Mailboxes, contacts, and distribution groups.

One thing to plan for: After the migration, every user needs to reconfigure their Outlook profile to connect to Office 365. This is a manual step you'll need to communicate to your team in advance.

Steps to perform cutover migration:

Register your domain with Office 365 and confirm DNS ownership in the Microsoft 365 admin center.
Create user accounts and assign the appropriate Microsoft 365 licenses.
Create a migration endpoint in the Exchange Admin Center (EAC) that connects to your on-premises Exchange server.
Create a migration batch that includes all your mailboxes and start the migration.
Monitor the batch until all mailboxes report as synced.
Update your domain's MX record to point to Office 365.
Delete the migration batch and guide users through Outlook profile reconfiguration.

Full guide: Cutover Office 365 migration

2. Staged Migration

Staged migration is designed for larger organizations that can't realistically move everyone at once. Instead of a single batch, you split your mailboxes into groups and migrate them over days or weeks. Users in each group get moved, you verify everything is working, and then you move on to the next group.

There is one important constraint here that catches many IT teams off guard: staged migration only works when your source is Exchange 2003 or Exchange 2007. If you're running Exchange 2010 or later, this method is not available to you. You'll need a cutover or hybrid migration instead.

Best for: Organizations with more than 2,000 mailboxes running Exchange 2003 or Exchange 2007.

What gets migrated: Mailboxes only, in batches. Contacts and distribution groups sync through Azure AD Connect rather than the migration batch itself.

One thing to plan for: Calendar and delegation features are not fully available to users until their batch has completed. Users in later batches will have limited calendar access during the migration window.

Steps to perform staged migration:

Confirm you're running Exchange 2003 or 2007 on-premises and that your domain is registered in Office 365.
Install and configure Azure AD Connect to synchronize your on-premises users to Office 365.
In the Exchange Admin Center, create your first migration batch by grouping a logical set of mailboxes (by department or location works well).
Start the batch and let the data sync. This runs in the background.
Once synced, notify that group of users and help them update their Outlook profiles.
Repeat for each subsequent batch until all mailboxes are migrated.
Switch your MX records to Office 365 after the final batch is confirmed.
Decommission your on-premises Exchange server once you no longer need it.

Full guide: Staged Office 365 migration

3. Hybrid Migration

Hybrid migration is what large enterprises use when they need the migration to be as invisible to end users as possible. Rather than cutting over on a set date, you connect your on-premises Exchange environment and Office 365 so they operate as one unified system. Mailboxes can exist on either side, and users can interact with each other seamlessly regardless of where their mailbox lives.

This coexistence can last months or even years, depending on the organization's pace. You move mailboxes in phases, verify everything works, and eventually decommission your on-premises infrastructure when you're ready.

Best for: Enterprises running Exchange 2010, 2013, 2016, or 2019 that need phased migration without disrupting calendar sharing, delegation, or free/busy visibility between users.

What gets migrated: Everything — mailboxes, archive mailboxes, public folders, shared mailboxes, and contacts. You choose what moves and when.

One thing to plan for: Hybrid setup requires running Microsoft's Hybrid Configuration Wizard and setting up Azure AD Connect for directory and password synchronization. It is the most complex of the four methods to configure initially, though day-to-day operation is smooth once it's running.

Steps to perform hybrid migration:

Verify prerequisites: Exchange Server 2010 SP3 or later, valid SSL certificates, and a domain registered in Office 365.
Run the Hybrid Configuration Wizard to establish the connection between your on-premises Exchange and Office 365.
Set up Azure AD Connect for directory synchronization and password sync.
Create Office 365 mailboxes for your pilot users and migrate this first group to validate the setup.
Confirm that calendar sharing, free/busy lookup, and delegation all work correctly across both environments.
Continue migrating in phases, department by department or location by location.
Once all mailboxes are in Office 365, decommission your on-premises Exchange server.

4. IMAP Migration

IMAP migration is the right choice when your source mail system is not Exchange. Gmail, Zimbra, Zoho Mail, Yahoo, cPanel, and any other IMAP-compatible mail server can be migrated to Office 365 using this method.

The catch is that IMAP only migrates email messages and folder structure. Calendars, contacts, and tasks do not come across automatically — those need to be handled separately, either manually or through a dedicated migration tool.

Best for: Organizations moving from Gmail, hosted IMAP services, or any non-Exchange mail platform to Office 365.

What gets migrated: Email messages and folder structure. Calendars, contacts, and tasks are not included.

One thing to plan for: Once you close the IMAP migration endpoint, new emails arriving at the original IMAP mailbox will not automatically forward to Office 365. Timing your MX record switch carefully is important.

Steps to perform IMAP migration:

Register your domain with Office 365 and create user mailboxes with the appropriate licenses.
Collect IMAP server details for your source mail system: hostname, port (typically 993), and SSL configuration.
Build a CSV file that lists each user's email address and IMAP credentials.
Create an IMAP migration endpoint in the Microsoft 365 admin center using the server details you gathered.
Create a migration batch using your CSV file and start the migration.
Monitor progress and confirm all mailboxes and folders sync successfully.
Switch your domain's MX records to Office 365.
Delete the migration batch and help users configure Outlook to connect to their new Office 365 mailboxes.

EdbMails IMAP migration tool

Which Office 365 Migration Method Should You Use?

If you're still not sure which method fits your situation, use this table to compare them side by side.

Criteria	Cutover	Staged	Hybrid	IMAP
Ideal org size	Fewer than 150 mailboxes (max 2,000)	More than 2,000 mailboxes	Any size, complex needs	Any size, up to 50,000
Source environment	Exchange 2003 to 2019	Exchange 2003 or 2007 only	Exchange 2010 to 2019	Any IMAP server
Migration speed	Fast, single batch	Gradual, batch by batch	Gradual, fully phased	Gradual, email only
Data migrated	Mailboxes, contacts, distribution groups	Mailboxes in batches	Full: mailboxes, archives, public folders	Email messages only
Calendar and delegation	Full access after migration	Limited during migration	Full access throughout	Not migrated
Downtime	Brief cutover window	Minimal per batch	None, coexistence model	Minimal
Directory sync required	No	Yes, Azure AD Connect	Yes, Azure AD Connect	No
Outlook reconfiguration	Required for all users	Required per batch	Not required	Required after completion
Setup complexity	Low	Moderate	High	Low
On-premises after migration	Decommissioned	Decommissioned	Coexists until ready to decommission	Not applicable

EdbMails software for Office 365 and Exchange migration

EdbMails is one such single unified Office 365 migration software, which is superior to all native methods of Office 365 migration. Here are some benefits that EdbMails offers in Cutover migration, staged, Hybrid and IMAP migration:

User-friendly interface: The user interface of EdbMails is simple and easy-to-use which can also enable a non-technical user to accomplish the task of Office 365 tenant migration.
Comprehensive Office 365 migration solution: EdbMails is one of the best mailbox migration tools for migrating mailboxes, contacts, calendar, public folders, etc., from one location to another location. Migrate Office 365 from GoDaddy to Microsoft, move from Rackspace Exchange to Office 365, and even perform Gmail to Office 365 IMAP migration with a single tool.
Faster Office 365 migration: With advanced algorithms, EdbMails helps you increase the migration speed, which means you would be done with the migration much quicker compared to the natively available Office 365 migration methods.
Zero downtime migration: EdbMails provides a seamless migration with zero downtime. This means you will be able to continue to access your email data through the migration process without any interruptions.
Automatic mailbox mapping: EdbMails maps the source mailbox with the target mailbox automatically while the migration process is taking place. No manual mailbox mapping is required.
Advanced filters: EdbMails has advanced filters to help you migrate only desired emails like the emails of a certain date range, in a certain folder, etc. Thus, this will save migration time and expense.
Incremental migration: EdbMails provides an incremental migration facility; it allows migrating only new or modified items after the first migration. This facility could shorten the migration time and reduce bandwidth for later migrations.
No data loss: EdbMails ensures absolutely no loss of data during the migration because the data is completely consistent and integral before and after migration.

Common Office 365 Migration Scenarios

Beyond the four native methods above, here are the most frequent real-world migration scenarios and how organizations handle them.

Office 365 tenant to tenant migration

This comes up most often during company mergers, acquisitions, or rebranding. All mailboxes, SharePoint content, and Teams data need to move from one Microsoft 365 tenant to another. Microsoft's built-in cross-tenant tools are limited in scope; most IT teams handling this scenario use a third-party tool to get everything across cleanly. See Office 365 tenant to tenant migration

Exchange to Office 365

Still the most common migration path. Organizations running Exchange Server on-premises for years eventually need to move to the cloud. The exact approach depends on your Exchange version and mailbox count, which is why the method selection table above matters. See Exchange to Office 365 migration

Office 365 to Exchange migration

Not every organization moves permanently to the cloud. Some need to migrate Office 365 mailboxes back to an on-premises Exchange server — whether because of compliance requirements, cost restructuring, a change in IT strategy, or a merger where the surviving entity runs on Exchange. EdbMails handles this reverse migration path and supports all Exchange versions from 2007 through 2019 as the target. Mailboxes, calendars, contacts, and folders all move across without data loss. See Office 365 to Exchange migration

Office 365 to PST export

Exporting Office 365 mailboxes to PST is one of the most common requests IT teams get, usually for one of three reasons: creating an offline backup before a tenant migration, fulfilling a legal hold or eDiscovery request, or offboarding a user while retaining their email history. Microsoft's native eDiscovery export tool works but is known to produce errors on large mailboxes. EdbMails exports Office 365 mailboxes to PST directly, without size limits and without the errors that come with the native approach. See Office 365 to PST export

Bulk PST files to Office 365

Many organizations have hundreds of PST files accumulated over years — sitting on local drives, file servers, or backup tapes. Importing them one by one into Office 365 is not practical at scale. EdbMails handles bulk PST to Office 365 migration with automatic mailbox mapping, so you don't need to manually match each PST file to its corresponding Office 365 mailbox. It processes multiple PST files concurrently and supports incremental import, meaning if a PST has already been partially imported, subsequent runs only bring across what's new. See bulk PST files to Office 365 migration

Google Workspace to Office 365

When organizations switch from Google's productivity suite to Microsoft 365, they need to bring emails, calendars, and contacts with them. EdbMails handles this using a Google Admin account, so you don't need to collect individual user credentials from every employee. See Google Workspace to Office 365

Office 365 Migration Planning Checklist

A migration that fails usually fails in the planning stage, not the execution stage. Run through this checklist before you start.

Before the migration:

Audit all source mailboxes: record the size, item count, and whether each account is active or dormant
Verify domain ownership and confirm you have DNS edit access
Assign the correct Microsoft 365 licenses to all target users before migration begins
Note mailbox size limits: the standard Office 365 mailbox is 50 GB, with an additional 100 GB available through archive mailboxes
Identify all shared mailboxes, public folders, archive mailboxes, and distribution groups — these are easy to overlook and commonly missed
Select your migration method using the comparison table above
Install and configure Azure AD Connect if you're using staged or hybrid migration
Set up the required Exchange impersonation rights or IMAP credentials for EdbMails
Run a pilot migration using 5 to 10 test mailboxes before committing to the full migration
Let users know the migration is coming, what to expect, and when

During the migration:

Monitor the migration dashboard for errors and failed items
Keep source mailboxes active until the migration is fully verified
Do not change MX records until the final batch is confirmed complete

After the migration:

Switch MX records to Office 365
Update Autodiscover, SPF, DKIM, and DMARC records
Help users reconfigure Outlook to connect to their new Office 365 mailbox
Verify that calendars, contacts, and shared mailboxes are all accessible and working
Run one final incremental migration pass to pick up any items that arrived after the initial sync
Decommission legacy mail servers once everything checks out

Full Office 365 migration checklist

How EdbMails Makes Office 365 Migration Easier

The native Microsoft migration tools get the job done for straightforward scenarios, but they have real limitations: no incremental sync, no automatic mailbox mapping, limited data type support, and a requirement to use PowerShell for many tasks. EdbMails fills those gaps.

Here is what EdbMails brings to any Office 365 migration, regardless of which method you're using:

It runs in the background without interrupting your team. EdbMails migrates data while users continue working on the source system. There's no maintenance window and no moment where mail goes missing. See zero downtime migration

It only migrates what's new after the first sync. After the initial migration pass, EdbMails checks for new or changed items and migrates only those on subsequent runs. This is especially valuable for large migrations that run over multiple days. See incremental migration

It maps source mailboxes to target mailboxes automatically. You don't need to build and maintain a CSV mapping file. EdbMails reads the source and target environments and handles the mapping itself. See automatic mailbox mapping

You can filter exactly what migrates. Need to migrate only emails from the last two years? Only certain folders? Only specific mailbox types? EdbMails lets you set precise filters so you're not migrating data you don't need. See filter settings

It migrates more than just email. Unlike native IMAP migration, EdbMails migrates emails, calendars, contacts, tasks, public folders, archive mailboxes, and shared mailboxes in one pass.

No PowerShell required. The whole process runs through a graphical interface. Your IT generalist can run this migration without needing to be an Exchange PowerShell expert.

EdbMails supports every common Office 365 migration scenario: tenant to tenant, Exchange to Office 365, Office 365 to Exchange, Office 365 to PST, bulk PST to Office 365, Google Workspace to Office 365, and IMAP to Office 365, all from one tool.

Choosing the Right Office 365 Migration Method: Common Questions

I have 80 mailboxes on Exchange 2016. Which method should I use?

Cutover migration is the right fit. You're well under the 150-mailbox recommendation, and Exchange 2016 is a supported source. You can complete the entire migration in a single batch, usually within a few hours.

I have 3,000 mailboxes on Exchange 2007. Can I use cutover migration?

No. At 3,000 mailboxes, a single-batch cutover would run for so long it would be impractical. Exchange 2007 is one of only two versions (along with 2003) that support staged migration, so that's your best path here. You'll migrate in batches over weeks while users continue working normally.

I have 4,000 mailboxes on Exchange 2013. Which method works?

Hybrid migration. Exchange 2013 is not supported for staged migration, and 4,000 mailboxes is too many for a practical cutover. Hybrid gives you the flexibility to move mailboxes in phases while keeping full calendar and delegation functionality throughout.

We're moving from Gmail to Office 365. Do any of the Exchange-based methods apply?

None of them. Gmail doesn't run Exchange, so cutover, staged, and hybrid migration are off the table. IMAP migration is the native path, though it only brings across email. If you also need calendars and contacts, EdbMails' Google Workspace to Office 365 migration handles the full data set.

Our company just acquired another company and both use Office 365. How do we merge the tenants?

This is a cross-tenant migration scenario. Microsoft has a native cross-tenant migration feature but it's limited in scope and doesn't cover SharePoint or Teams. Most organizations handling a merger or acquisition use a dedicated tool like EdbMails for this. See tenant to tenant migration

Can we migrate only certain mailboxes and leave others on-premises for now?

Yes, but only with hybrid migration. It's specifically designed for selective mailbox migration where some users live in Office 365 and others remain on-premises, with full interoperability between the two sides.

We need to move our Office 365 mailboxes back to on-premises Exchange. Is that possible?

Yes. EdbMails supports Office 365 to on-premises Exchange migration for all Exchange versions from 2007 through 2019. This is a less common scenario but comes up regularly for organizations with compliance mandates, cost restructuring plans, or post-merger consolidations. See Office 365 to Exchange migration

We have hundreds of old PST files on a file server. How do we get them into Office 365?

Use EdbMails bulk PST to Office 365 migration. It processes multiple PST files simultaneously, maps each PST to the correct Office 365 mailbox automatically, and uses incremental import so re-running the job doesn't create duplicates. See bulk PST to Office 365 migration

Does the EdbMails Office 365 Migration license also cover Exchange to Office 365, IMAP to Office 365, and Google Workspace to Office 365?

No. EdbMails licenses are based on the source server, not the destination. Each migration scenario requires the license that matches where your data is coming from:

If your source is Office 365 (migrating between tenants, or exporting to PST or Exchange), you need the Office 365 Migration license.
If your source is Exchange Server (migrating Exchange to Office 365, Exchange to PST, or Exchange to Exchange), you need the Exchange Migration license.
If your source is an IMAP server such as Gmail, Zimbra, Zoho, or cPanel, you need the IMAP Migration license.
If your source is Google Workspace or G Suite, you need the Google Workspace Migration license.

So if you're migrating from Exchange to Office 365, you purchase the Exchange Migration license — not the Office 365 Migration license — because Exchange is the source. If you're later migrating those same mailboxes from Office 365 to another tenant, that second migration would require the Office 365 Migration license. When in doubt, check the EdbMails pricing page or contact support to confirm the right license for your specific scenario.

Conclusion

Office 365 migration is manageable when you pick the right method for your environment and plan it properly before touching a single mailbox. Cutover is fast and simple for small teams. Staged handles large Exchange 2003/2007 environments at a controlled pace. Hybrid gives enterprises the flexibility to move gradually without any disruption to daily work. IMAP covers everyone else coming from non-Exchange platforms.

Not every migration goes in one direction either. Whether you need to move Office 365 mailboxes back to Exchange, export them to PST for backup or compliance, or import a backlog of PST archives into the cloud, EdbMails handles the full range of scenarios from a single tool.

Whatever your scenario, the planning checklist and method comparison table in this guide give you a solid foundation to start from. If you want to skip the manual configuration and run the migration through a single tool that handles every direction and every data type, explore what EdbMails can do for your organization.

Download

Buy Now