Office 365 Migration Best Practices

Competitor and Microsoft migration guidance consistently starts with discovery. Create a migration inventory before choosing dates or batch sizes so the project team knows what is moving, what depends on the source environment, and what requires separate remediation.

1. Users and mailboxes: Record primary, shared and archive mailboxes, mailbox sizes, inactive accounts, aliases, and any mailboxes that should not move.
2. Mail flow and domains: Document accepted domains, MX and Autodiscover dependencies, connectors, forwarding, SMTP relay, and applications or devices that send mail.
3. Identity and access: Identify the authentication model, administrative access, MFA requirements, target identities, and licensing needed for the selected migration path.
4. Client and application dependencies: Record Outlook versions, mobile clients, line-of-business applications, scanners, ticketing systems, CRM integrations, and other services tied to the current mail environment.
5. Migration scope: Decide what must migrate, what can be archived or excluded, and which workloads require a separate migration plan.

Use this inventory as the baseline for the Office 365 migration checklist and for pilot-user selection.

Before migration, document the current environment and define what must be ready in Microsoft 365. A written baseline makes it easier to identify dependencies, estimate effort, assign ownership, and decide whether the project is ready for a pilot. Recommended pre-migration practices include:

1. Assess the source environment: Inventory users, mailboxes, shared and archive mailboxes, distribution or Microsoft 365 groups, domains, connectors, forwarding rules, applications, retention requirements, and other dependencies that may affect the move.
2. Estimate data volume, network capacity, and migration windows: Record mailbox counts and sizes, available bandwidth, business-hour constraints, and expected migration concurrency. Use a pilot to establish practical throughput rather than relying only on theoretical bandwidth.
3. Understand Office 365 subscriptions:

   Confirm that the target subscriptions and licenses support the mailbox, storage, archive, security, and compliance requirements identified during assessment. Compare the available Business and Enterprise plans before provisioning target users. See Microsoft's business plans and enterprise plans comparisons.

4. Define scope and success criteria: Record the users and workloads in scope, migration phases, target dates, validation criteria, escalation owners, and any compliance or retention requirements that must be maintained.
5. Reduce unnecessary migration scope: Review inactive accounts, obsolete data, duplicate content, and data that should be retained elsewhere according to organizational policy. Moving only approved in-scope data can reduce migration load and simplify validation.
6. Choose the right migration method:

   Choose an approach that matches the source platform, coexistence requirements, project size, migration window, and operational constraints. See the Office 365 migration methods guide for a dedicated comparison of available approaches.

7. Create the migration plan: Define preparation, pilot, migration batches, incremental passes where supported, cutover, validation, communication, and rollback or remediation responsibilities. Keep owners and decision points clear for each phase.

Define go/no-go criteria before production: Do not start a production batch only because the planned date has arrived. Confirm that target users and licenses are ready, authentication works, mapping has been reviewed, the pilot has passed the agreed validation checks, required DNS or domain changes are understood, and the support team knows the escalation path.

Prepare the communication plan: Identify pilot users and production waves, tell users when their batch and cutover will occur, explain any sign-in or Outlook changes, and provide a support contact for post-cutover issues. User communication should be part of the migration plan rather than an afterthought.

Before production, also verify target users and licensing, confirm source-to-target mailbox mapping, and run a pilot with representative mailbox sizes and conditions. Where customized pairing is required, review user-defined mailbox and folder mapping. If EdbMails provisioning will be used, confirm the automatic mailbox creation and licensing requirements.

Working from a step-by-step list? Our Office 365 migration checklist covers the same planning stages in a quick-reference format.

After the assessment and pilot are approved, execute the migration in controlled phases. The exact sequence depends on the source and migration method, but the following practices apply to most Office 365 migration projects:

1. Set up Office 365: You will first have to set up your Office 365 environment before undertaking the migration. It's all about setting up users accounts, configuring permissions, and the security features to go with, such as multi-factor authentication.
2. Plan for Microsoft 365 throttling: Service-side throttling can affect migration throughput when many operations run concurrently. Build schedule tolerance into the project, use pilot results to estimate throughput, and avoid treating a short best-case test as a guaranteed production rate. See Microsoft 365 and Office 365 throttling.
3. Migrate in controlled batches: After the pilot, move approved users in manageable batches. Keep source-to-target mapping consistent and use supported Office 365 migration filter settings only when the project requires a selective data scope.
4. Review migration results: Check the migration status and reports after each batch. Investigate failed, skipped, or warning items before cutover, and validate representative mailboxes and folders in the target rather than relying on a completion status alone.
5. Resolve exceptions before cutover: Review failed, skipped, and warning items after each batch. Record the affected mailbox, reason, remediation action, owner, and whether the item must be resolved before cutover or can be handled afterward.
6. Keep a cutover contingency: Define the conditions that would postpone the cutover, who can make that decision, and how users and mail flow remain on the existing environment if validation has not passed. The exact rollback approach depends on the source platform and migration method.
7. Run the final incremental pass before cutover: With EdbMails, the initial migration is a full migration. Subsequent runs using the same source and target from the previous migration on the same computer are incremental and process supported new or changed items. Run another incremental migration close to cutover, retain the approved mapping, and review the report before switching users and mail flow.
8. Complete cutover and target configuration: Once migration is complete, configure and optimise your Office 365 environment to meet the needs of your business. This step is about configuring elements such as mobile device management, data loss prevention, configuring Outlook for your users, and adding MX records to the new Office 365 server for mail routing.

After cutover, continue validation until the migrated users and required services are operating as expected. Post-migration best practices include:

1. Support users after cutover: Communicate sign-in, Outlook profile, mobile-device, and service changes, and provide a clear escalation path for access or mail-flow issues.
2. Validate users and mail flow: Confirm representative users can sign in, access expected mailbox data, send and receive mail, and use the target configuration intended for the project.
3. Implement security measures: Execute the necessary identity and access management, data protection, and compliance controls. See our Office 365 migration security best practices guide for the full checklist, including MFA enforcement, Conditional Access, and least-privilege access.
4. Use acceptance criteria to close the migration: Confirm the agreed mailbox and folder checks, representative item validation, user sign-in, mail flow, Outlook or client readiness, migration-report review, and exception ownership. Record unresolved items and the operational handoff before declaring the batch or project complete.

When EdbMails is used for the migration, align the software workflow with the project plan rather than treating tool configuration as a substitute for assessment and cutover planning. Recommended practices include:

1. Keep mapping consistent: Verify source-to-target mailbox mapping before the first production run and retain it for subsequent runs.
2. Use a pilot: Test representative mailboxes before expanding to larger batches.
3. Use incremental migration correctly: The initial run is full; subsequent runs with the same source and target from the previous migration on the same computer are incremental for supported new or changed items.
4. Use filters only for an approved scope: If the project excludes older or unnecessary data, document the filter criteria before migration so validation uses the same scope.
5. Review reports after each run: Investigate warnings or failed items and perform representative target checks before cutover.
6. Separate migration from cutover: Complete data migration and validation first, then perform the project-specific DNS, domain, Outlook, and mail-flow changes at the planned cutover stage.

For supported migration scenarios and product capabilities, see the Office 365 migration tool. For procedural preparation, continue with the Office 365 migration checklist.