Office 365 Migration Scenarios

Choose the Office 365 migration scenario by source and target

Start with the systems you are moving from and to. Microsoft also organizes migration planning around the source environment and intended destination. The EdbMails resources below provide the scenario-specific workflow.

Microsoft 365 tenant-to-tenant migration scenarios

A tenant-to-tenant migration moves supported data from one Microsoft 365 organization to another. Common business cases include mergers and acquisitions, divestitures, tenant consolidation, restructuring and rebranding. Microsoft also identifies cross-tenant migration as a common requirement in merger, acquisition and divestiture projects.

• Mergers and acquisitions: Move selected users or business units into the receiving Microsoft 365 tenant.
• Divestitures and spin-offs: Separate selected users and supported data into a different tenant.
• Tenant consolidation: Combine users from multiple Microsoft 365 tenants into the tenant that will remain in service.
• Rebranding or restructuring: Move users while preparing new target identities, addresses or organizational structures.
• Same-domain migration: Plan the mailbox move and custom-domain transfer as separate cutover activities. See Office 365 migration with the same domain.

This scenarios page intentionally stays at the decision level. For the complete source connection, target connection, mapping and migration sequence, use the Office 365 tenant-to-tenant migration guide.

Office 365 to Exchange Server migration

This scenario applies when Microsoft 365 mailbox data must move to an on-premises or hosted Exchange environment. Before migration, verify the target Exchange version, target recipients, administrator access, mailbox mapping and available migration window. Keep the scenario distinct from Exchange-to-Microsoft-365 onboarding, which has different source and target requirements.

Use the dedicated Office 365 to Exchange migration guide for the supported workflow and version-specific preparation.

Office 365 to IMAP migration

Choose this path when the destination is an IMAP-enabled mail platform. IMAP is primarily an email protocol, so administrators should confirm exactly which data types the destination workflow supports instead of treating an IMAP move as equivalent to a full Microsoft 365 mailbox migration. Target mailbox access, server settings and mailbox mapping should be prepared before production migration.

For supported destination platforms and the EdbMails workflow, see Office 365 to IMAP migration.

Office 365 and PST migration scenarios

PST can be the destination when mailbox data needs to be exported from Microsoft 365, or the source when existing PST files need to be imported into Microsoft 365 mailboxes. These are separate workflows and should not be presented as the same migration direction.

• Office 365 to PST: Export selected supported mailbox data to PST. See Office 365 to PST Export.
• PST to Office 365: Import PST data into mapped Microsoft 365 mailboxes. See PST to Office 365 migration.

Public folder, archive and shared mailbox scenarios

Some Office 365 migration use cases involve a specific mailbox type or workload rather than a general user-mailbox move. Treat these as separate scenarios because prerequisites, mapping and validation can differ.

• Public folders: Use the Office 365 public folder migration guide.
• Archive mailboxes: Use the Office 365 archive mailbox migration resource.
• Shared mailboxes: Confirm the source and target shared mailbox configuration and use the relevant Office 365 mailbox migration workflow.
• Microsoft 365 Groups: For group-specific requirements, see Office 365 Group migration.

Migration scenario vs. migration method

A migration scenario describes the source, destination and business use case. A migration method describes how the move is executed. For example, Microsoft documents cutover, staged, hybrid, IMAP and cross-tenant approaches for different source environments and requirements. Do not choose a method only from the scenario name; mailbox count, source platform, coexistence requirements, workload scope and cutover plan also matter.

For method selection rather than scenario selection, see the Office 365 migration methods page.

Capabilities used across EdbMails migration scenarios

The exact workflow depends on the source and target, but several EdbMails capabilities are useful across supported Office 365 migration paths:

• Source-to-target mapping: Map source mailboxes to the intended target recipients; use user-defined mailbox mapping when explicit pairing is required.
• Selective migration: Apply supported filters when the project requires a defined date range or subset of data. See Office 365 migration filter settings.
• Initial and repeat migration: The initial pass is full. Subsequent migration from the same source and target retained from the previous migration on the same computer is incremental, allowing supported new or changed items to be processed before cutover.
• Reports and validation: Review migration results after each pass and resolve failed or skipped items before final cutover.