Office 365 Cutover Migration
Office 365 cutover migration is a migration approach in which an on-premises Exchange organization is moved to Microsoft 365 in one main migration phase rather than moving users across multiple long-running batches. It is generally suited to smaller Exchange environments that can plan a defined transition window and do not require long-term coexistence between the source and target.
Microsoft supports cutover migration for up to 2,000 mailboxes, but recommends approximately 150 or fewer because larger environments can take significantly longer to create, synchronize, and complete. For broader project planning beyond the cutover method itself, use the Office 365 migration guide.
What Is Office 365 Cutover Migration?
In a traditional cutover migration, the source is an on-premises Exchange organization and the target is Exchange Online in Microsoft 365. The goal is to prepare the target, migrate the selected Exchange organization in one main phase, redirect mail flow, verify synchronization, and complete post-migration validation.
- All mailboxes in scope are handled as one primary migration batch or phase.
- The target Microsoft 365 organization is prepared before the final transition.
- Mailbox data is synchronized before mail flow is redirected.
- MX and related DNS changes are planned as part of the final cutover.
- A final synchronization or incremental pass can be performed when the migration method requires it.
- Licensing, user access, Outlook connectivity, mail flow, and migrated data are validated after the transition.
When Should You Use Cutover Migration?
| Situation | Cutover suitability |
|---|---|
| Small on-premises Exchange environment | A common cutover scenario, particularly when the organization can move users in one main phase. |
| Need to move the full Exchange organization over a short window | Cutover can fit when a defined weekend or multi-day transition is practical. |
| Long-term coexistence is not required | Cutover is designed for a transition to Microsoft 365 rather than prolonged source/target coexistence. |
| Large mailbox population or complex coexistence requirements | Evaluate another migration approach such as hybrid migration or another supported method. |
| Source and target are both Microsoft 365 tenants | This is tenant-to-tenant migration, not the traditional Exchange cutover method. |
Cutover Migration Requirements
Before creating the migration batch, confirm the source and target are ready for the cutover workflow.
- Source Exchange environment: Identify the Exchange version, mailbox count, mailbox sizes, and any source connectivity requirements.
- Microsoft 365 target: Confirm the target subscription and Exchange Online availability.
- Domain verification: Add and verify the source organization's email domain in Microsoft 365 before migration.
- Permissions: Confirm the administrator account has the permissions required to configure and manage the migration.
- Licensing: Plan license assignment for migrated users at the appropriate stage of the migration.
- Migration connectivity: Validate Autodiscover, endpoint connectivity, firewall/network access, and any source prerequisites needed by the selected migration method.
Before Starting a Cutover Migration
Preparation should be completed before the migration window begins. The Office 365 migration checklist can be used alongside the cutover-specific checks below.
- Inventory the mailboxes, aliases, distribution groups, contacts, and data volumes that are in scope.
- Verify the source Exchange organization and target Microsoft 365 tenant are accessible.
- Confirm the email domain is accepted and verified in Microsoft 365.
- Check migration permissions and authentication requirements.
- Review mailbox sizes and estimate how long synchronization is likely to take.
- Plan the migration window and communicate the expected transition to users.
- Review DNS records and lower TTL values in advance where appropriate.
- Test connectivity and the migration workflow with a small pilot or representative mailbox set when practical.
- Document how Outlook profiles, mobile clients, mail flow, and support requests will be handled after cutover.
How Cutover Migration Works
- Prepare Microsoft 365.
Add and verify the domain, confirm the Exchange Online target, and prepare the required administrator access.
- Prepare the source Exchange environment.
Confirm source connectivity, mailbox scope, Autodiscover or endpoint requirements, and the source credentials or permissions required by the migration method.
- Configure the migration connection or endpoint.
The migration endpoint identifies how Exchange Online connects to the source Exchange organization and is used by the migration batch.
- Create the cutover migration batch.
Add the mailboxes in scope and configure the migration batch so the organization can be synchronized to Microsoft 365.
- Start the initial migration.
Allow the batch to copy mailbox data to Exchange Online. Migration duration depends on mailbox size, item count, network capacity, service limits, and source conditions.
- Monitor and verify synchronization.
Review migration status and errors before redirecting mail flow. Resolve failed or incomplete mailboxes before the final transition.
- Change mail flow to Microsoft 365.
After the migration has reached the required state, update the MX record so new inbound mail is delivered to Microsoft 365. Domain verification and mail routing are separate tasks; changing the MX record does not transfer domain ownership.
- Perform the final synchronization where required.
Use the migration method's final synchronization or incremental process to capture supported changes that occurred after the initial synchronization.
- Validate the migrated environment.
Confirm user access, licensing, Outlook connectivity, inbound and outbound mail, mailbox folders, calendar/contact data, and the migration report before retiring the source environment.
What Happens to Users During a Cutover Migration?
| Stage | User impact |
|---|---|
| Before migration | Users continue working in the source Exchange environment while preparation is completed. |
| During synchronization | Mailbox data is copied to Microsoft 365 while the source remains the active environment according to the migration setup. |
| Final cutover | Mail flow is redirected to Microsoft 365. Users may need to sign in again or update/recreate Outlook profiles depending on the environment. |
| After cutover | Administrators validate mailbox access, Outlook connectivity, inbound/outbound mail, and migrated data before source retirement. |
Common Cutover Migration Scenarios
- Small Exchange-to-Microsoft 365 migration: An organization wants to move its full on-premises Exchange environment to Microsoft 365 in one main migration phase.
- Weekend migration: Most synchronization is completed before a planned weekend transition, followed by mail-flow changes, final synchronization where required, and user validation.
- Replacing an existing Exchange environment: The organization plans to retire an on-premises Exchange deployment after mailboxes, mail flow, and user access have been validated in Microsoft 365.
- Post-acquisition Exchange consolidation: A smaller acquired Exchange environment is moved into a Microsoft 365 organization without requiring long-term coexistence.
Cutover Migration vs Other Migration Scenarios
| Scenario | Typical source and target | Main distinction |
|---|---|---|
| Cutover migration | On-premises Exchange → Microsoft 365 | The organization is moved in one main migration phase and completes a defined final transition. |
| Staged migration | Supported legacy Exchange environments → Microsoft 365 | Users are moved in batches over time rather than as one cutover group. |
| Hybrid migration | On-premises Exchange ↔ Microsoft 365 | Supports longer coexistence and gradual mailbox moves. |
| Tenant-to-tenant migration | Microsoft 365 tenant → Microsoft 365 tenant | Requires cross-tenant preparation and should not be described as the traditional Exchange cutover method. |
If both the source and target are Microsoft 365 tenants, follow the dedicated tenant-to-tenant migration process rather than the Exchange cutover workflow.
How to Minimize User Disruption
Cutover migration should not be presented as a guaranteed zero-downtime process. Disruption can be reduced through careful preparation and a controlled transition.
- Complete as much mailbox synchronization as possible before the final transition window.
- Plan the MX and other required DNS changes in advance.
- Use a final synchronization or incremental pass when supported by the migration workflow.
- Notify users when mail flow and client access will move to Microsoft 365.
- Have Outlook/profile remediation steps ready before cutover begins.
- Keep the source environment available until mail flow, user access, and migrated data have been validated.
Using EdbMails in a Cutover-Style Migration Project
EdbMails can be used to connect source and target environments, select and map mailboxes, run mailbox migrations, review logs, and perform an incremental pass when required. For product-specific capabilities, see the Office 365 migration Tool.
Important: The existing interface screenshots below show the EdbMails Office 365-to-Office 365 workflow. That workflow is a Microsoft 365 tenant-to-tenant scenario, not Microsoft's traditional Exchange cutover method. They are retained here as an interface reference. For an Exchange-to-Microsoft 365 cutover project, use the source workflow appropriate to the Exchange environment and follow the cutover preparation, migration, mail-flow, and validation sequence described above.
EdbMails interface reference
1. Install and launch EdbMails
- Download and install EdbMails, then sign in or start the trial.
2. Choose the migration workflow
- The screenshot below shows the Office 365-to-Office 365 option used for tenant-to-tenant migration. This is a separate scenario from Exchange cutover migration.
3. Connect and select source mailboxes
- Use the supported authentication method for the selected migration workflow and connect the source environment.
- Select the mailboxes that are in scope and continue.
4. Connect the target and review mapping
- Connect the target Microsoft 365 environment and load the required target mailboxes.
- Review mailbox mapping carefully before starting the migration.
5. Start the migration and review reports
- Start the migration, monitor progress, and review the detailed migration logs when the pass completes.
- Download and install EdbMails, then sign in or start the trial.
Post-Migration Validation and Mail-Flow Steps
- Confirm migration completion.
Review migration status, mailbox reports, warnings, and any failed items before changing production mail flow.
- Change MX records to Microsoft 365.
Update the MX record so new inbound mail is delivered to Microsoft 365. Also verify the required Autodiscover and related DNS records for the target environment.
- Complete final synchronization if required.
Run the supported final or incremental synchronization after the last source activity and confirm the migration report again.
- Assign and verify user licenses.
Confirm each migrated mailbox has the Microsoft 365 licensing required for Exchange Online access.
- Verify Outlook and client connectivity.
Confirm Outlook and mobile clients connect to the target environment. Recreate profiles only when required by the environment or troubleshooting outcome.
- Test inbound and outbound email.
Send test messages between internal and external accounts and confirm delivery, replies, and expected mail routing.
- Validate migrated mailbox data.
Review representative mailboxes, folders, calendars, contacts, item counts, permissions where applicable, and migration logs.
- Retire the source only after validation.
Remove or decommission source resources only after migration, mail flow, user access, and data validation are complete and any retention or compliance requirements have been addressed.
Frequently Asked Questions
How long does a cutover migration typically take?
What happens to email during the migration window?
Can I switch to staged migration if my data volume turns out to be larger than expected?
