Every Office 365 migration project has the same goal: move users, data, and configurations from one environment to another without disrupting business operations. In practice, roughly 30% of migration projects experience at least one significant failure that requires remediation, rollback, or extended coexistence. The failures are rarely exotic. They are the same seven problems showing up in project after project -- problems that are entirely preventable if you know where to look.
This article is a retrospective based on patterns observed across hundreds of real migration engagements. Whether you are an MSP evaluating tools for a client project, an IT director planning a tenant-to-tenant migration during an acquisition, or a consultant running a Google Workspace to Microsoft 365 migration, these are the failures your team needs to anticipate and prevent. For each one, we explain what goes wrong, why it happens, and what the fix looks like.
MSPs conducting due diligence before quoting migration projects, IT teams building migration runbooks, and anyone who has been burned by a migration failure before and wants to make sure it does not happen again. Each failure includes concrete prevention steps you can add to your project plan today.
1. Missing Distribution Lists in Office 365 Migration
Distribution lists are the most commonly dropped objects in any Office 365 migration. They are not technically mailboxes, so they do not appear in the standard mailbox migration scope. But they are woven into the fabric of every organization's email operations -- and when they vanish, users notice immediately.
The problem is compounded by the variety of group types in Microsoft 365. A single source environment may contain regular distribution lists, dynamic distribution groups, mail-enabled security groups, Microsoft 365 Groups, and nested groups that reference each other. Each type has a different object class, different membership logic, and different migration handling requirements.
In one 2,000-user tenant-to-tenant migration, 340 distribution lists were present in the source. The migration tool handled only standard distribution groups. After cutover, 87 mail-enabled security groups and 23 dynamic distribution groups were missing entirely. It took the IT team 3 full days to manually recreate them -- and another week to fix the nested memberships that referenced groups across both categories.
Why It Happens
Most mailbox migration tools focus on user mailboxes and treat groups as a secondary workload. Dynamic distribution groups are particularly problematic because their membership is defined by OPATH filter queries against Azure AD attributes. Those filters often reference attribute values that exist in the source directory but have not been populated in the target, resulting in groups that exist but have zero members.
How to Prevent It
Full Group Inventory
Export every group type from the source environment using PowerShell or your migration tool's discovery module. Record the group type, member count, SMTP addresses, nesting relationships, and any associated permissions. Do not rely on the Exchange admin center UI alone -- it does not surface all group types in a single view.
Pre-Create Groups in Target
Create all groups in the target tenant during the pre-migration phase. For dynamic distribution groups, verify that the OPATH filter attributes (department, company, office, custom attributes) are populated in the target Azure AD before assigning the filter. Validate membership counts match the source.
Post-Migration Validation
After each migration batch, run a comparison script that checks source vs. target group membership. Flag any group where the member count has drifted. Perform send-to-group tests for every distribution list that serves more than 10 users.
2. Broken Calendar Delegates After Office 365 Migration
Calendar delegation is the invisible infrastructure that keeps executive offices running. An executive assistant who can view, edit, and respond to a manager's calendar is not a convenience feature -- it is a critical business workflow. When delegation breaks during migration, it creates an immediate, highly visible disruption that generates urgent escalations.
Calendar delegate relationships are stored as permissions on the mailbox object, not as standalone objects. They are tied to the user's distinguished name (DN) or legacy exchange DN in the source environment. When users are migrated to a new tenant, those DN references become invalid. The permission entries still exist on the mailbox, but they point to objects that no longer resolve -- effectively creating orphaned ACL entries that Exchange Online cannot evaluate.
Why It Happens
The root cause is that delegate permissions are defined by internal object identifiers, not by email addresses. When a user is recreated in a new tenant (as happens in any tenant-to-tenant migration), they get a new object ID even though their email address is the same. The permission entry on the manager's calendar still references the old object ID from the source tenant. Exchange cannot resolve it, so the delegate sees "You do not have permission to view this calendar" even though the permission appears to be granted.
Both the manager and the delegate must be migrated before delegate permissions can be correctly applied in the target. If the delegate is migrated in batch 1 and the manager in batch 5, the delegate cannot be granted access to a mailbox that does not yet exist in the target. Plan migration batches to keep delegate pairs together.
How to Prevent It
Before migration, export all calendar delegate assignments using Get-MailboxFolderPermission for every mailbox. Map each delegate relationship as a pair: (manager UPN, delegate UPN, permission level). After both users are migrated to the target, reapply the delegate permissions using the target tenant's object references. Verify that each delegate can actually open the manager's calendar in Outlook -- do not rely on the permission being listed in PowerShell output alone, because stale ACL entries can appear valid without actually working.
4. Teams Channels Lost Post-Cutover
Microsoft Teams is one of the most complex workloads to migrate because it is not a single service -- it is a composite of multiple backend systems. A single Teams channel touches Exchange Online (compliance copies of messages), SharePoint Online (channel files and the document library), Azure AD (group membership and ownership), and the Teams-specific chat service (message threading, reactions, mentions, and tabs). A migration approach that handles only one of these backends will produce channels that look migrated but are missing critical pieces.
Private channels add another layer of complexity. Unlike standard channels, each private channel has its own dedicated SharePoint site collection, its own membership model (which is a subset of the parent team's membership), and its own permission boundary. Many migration tools either skip private channels entirely or migrate them as standard channels, losing the access isolation that made them private in the first place.
Why It Happens
Teams migration is often treated as an afterthought -- something to handle "after the mailbox migration is done." By that point, DNS has been cut over, users are working in the new tenant, and the old Teams environment is being decommissioned. Retroactively migrating Teams data from a partially decommissioned environment is significantly harder than doing it as part of the planned migration sequence. Our Microsoft Teams migration guide covers the full sequencing approach.
The Microsoft Teams Import API is the only officially supported method for importing Teams messages with full fidelity -- including original timestamps, sender attribution, reactions, and threading. Tools that use alternative methods (such as posting messages via bot accounts) produce messages attributed to a service account with the current timestamp, not the original sender and date. The Cloudiway Teams migration tool uses the Import API to preserve complete message history.
How to Prevent It
Include Teams in the migration scope from day one. Inventory all teams, channels (standard and private), and their associated SharePoint sites. Verify that your migration tool handles the full composite: messages with threading, files with version history, tabs and connectors, and channel-level permissions. Migrate Teams data before DNS cutover so users have a complete Teams environment waiting for them when they switch tenants. Validate by opening each migrated team, checking that message history is intact, files are accessible, and private channels maintain their restricted membership.
5. Permission Mismatches Across Office 365 Workloads
Permission migration is the thread that ties every other failure in this article together. Distribution lists have permissions. Calendar delegates are permissions. Shared mailboxes are governed by permissions. SharePoint sites, OneDrive folders, Teams channels, and public folders all have their own permission models. When any of these fail to transfer correctly, the result is users who can see data they should not, or -- more commonly -- users who cannot access data they need.
The challenge is that Microsoft 365 uses multiple, overlapping permission systems that do not share a unified model. Exchange uses mailbox-level and folder-level permissions with their own ACL format. SharePoint uses a role-based permission model with inheritance, unique permissions, and sharing links. Azure AD uses role assignments and group memberships. OneDrive uses SharePoint's permission model but adds its own sharing layer. When you migrate data from one tenant to another, each permission system needs to be handled independently -- there is no single "migrate all permissions" operation.
The Most Dangerous Mismatches
The Cloudiway site migration tool handles SharePoint permission mapping as part of the migration workflow, including sites with broken inheritance. For a full overview of SharePoint-specific considerations, see our guide on SharePoint migration and SharePoint to SharePoint migration best practices.
6. Mail Routing Gaps During Coexistence
Mail routing failures are the most immediately visible migration problem. When an email bounces or disappears, users escalate within minutes. Unlike permission issues or missing data that users discover gradually, a mail routing gap is a hard failure that blocks business communication in real time.
The coexistence period -- the window where some users are on the source tenant and others are on the target -- is where mail routing gaps appear. During this period, both tenants need to know how to route mail to users on the other side. This requires connectors, transport rules, and address rewriting that create a bidirectional mail bridge between environments. If any component of this bridge is misconfigured, mail gets lost.
Common Routing Failure Scenarios
External Mail to Migrated Users
After a user is migrated but before DNS MX records are updated, external mail still arrives at the source tenant. Without a forwarding rule or transport connector, that mail sits in the source mailbox while the user is working in the target. This is the most common routing gap and the easiest to prevent with proper mail forwarding configuration.
Internal Mail Between Tenants
A migrated user in the target tenant sends mail to a colleague still in the source tenant. Without cross-tenant connectors, Exchange tries to resolve the recipient locally, fails, and either bounces the message or delivers it to a stub object that nobody monitors. This is especially problematic in tenant-to-tenant migrations where both environments are fully operational.
Alias and Secondary SMTP Routing
Users with multiple SMTP aliases (proxy addresses) may have some aliases routed correctly and others not. If a user's primary SMTP is migrated but their secondary alias is still pointing to the source, mail sent to the alias goes to the wrong place. This is particularly common in organizations that have gone through prior mergers and carry legacy domain aliases.
Cloudiway includes mail routing and free/busy coexistence as part of the migration platform -- not as a separate product or add-on. This means bidirectional mail flow, calendar free/busy sharing, and GALSync are configured as part of the migration setup, not bolted on as an afterthought. Learn more about how the best Office 365 migration tools handle coexistence natively.
7. Incomplete Data Transfers
Incomplete data transfer is the failure that users discover slowly, one missing email at a time. A user searches for a message from two years ago and it is not there. An attachment that was in a subfolder is gone. A calendar event from last quarter has no attendees listed. These are not dramatic failures -- they are quiet erosion of trust in the migration that generates a steady stream of low-grade support tickets for weeks after cutover.
The causes are almost always technical limitations that the migration plan did not account for: API throttling, message size limits, item count limits, unsupported attachment types, or timeout thresholds that silently skip items when the transfer takes too long.
Common Data Transfer Gaps
Following data migration best practices is essential for minimizing transfer gaps. The key is to run incremental sync passes that re-attempt failed items, verify item counts between source and target after each pass, and flag discrepancies before cutover rather than discovering them after. For migrations from Google Workspace, calendar recurrence handling requires particular attention due to differences in how Google Calendar and Exchange store recurring event exceptions -- our Google Workspace to Microsoft 365 migration solution addresses these conversion challenges specifically.
How to Prevent Office 365 Migration Failures
Every failure described in this article has the same root cause: insufficient pre-migration discovery. The migration tool itself is rarely the problem. The problem is that the migration plan did not account for the full scope of objects, permissions, and routing configurations that need to be handled. Here is the prevention framework that addresses all seven failures simultaneously.
Comprehensive Discovery Phase
Spend 20-25% of total project time on discovery. Inventory every mailbox type (user, shared, room, equipment), every group type, every delegate relationship, every permission assignment, every mail flow rule, and every Teams team with channels. Use automated discovery tools -- manual inventory is error-prone and misses edge cases. Refer to our documentation for detailed discovery procedures.
Batch Planning With Dependency Mapping
Do not batch users alphabetically or by department alone. Map delegate relationships, shared mailbox access patterns, and Teams membership to ensure that interdependent users are migrated together. An executive and their assistant should always be in the same batch. A shared mailbox should be migrated before or with its primary users.
Pre-Migration Validation Gates
Before each batch cutover, run a validation check that confirms: all groups are created, delegate permissions are mapped, shared mailbox access is configured, Teams data is migrated, mail routing is bidirectional, and item counts match. Do not proceed until every gate passes. This is the single most effective failure prevention technique.
Post-Cutover Verification Runbook
After each batch cutover, execute a standardized verification checklist: send/receive test emails (internal and external), open shared mailboxes, verify calendar delegate access, check Teams channel accessibility, confirm SharePoint permissions, and validate mail flow for all SMTP aliases. Document results and escalate failures immediately.
The right migration tool automates most of this prevention work. Cloudiway's platform includes automated discovery, dependency-aware batch planning, pre-migration validation, and post-migration verification as integrated features -- not manual steps that depend on your team remembering to run scripts. For a detailed comparison of tool capabilities, see our guide on choosing the best Office 365 migration tool and our broader overview of data migration best practices.
Pre-Migration Checklist: Avoiding All 7 Failures
Use this checklist as a starting point for your migration runbook. Each item directly addresses one or more of the seven failures covered in this article.
Complete Object Inventory
Export all user mailboxes, shared mailboxes, room mailboxes, equipment mailboxes, distribution lists (all types), Microsoft 365 Groups, Teams teams and channels (standard and private), SharePoint sites, public folders, and mail flow rules. Record object counts as your baseline.
Permission and Delegate Mapping
For every shared mailbox: Full Access, Send As, Send on Behalf delegates. For every user mailbox: calendar delegate assignments and folder-level sharing. For every SharePoint site: unique permissions at site, library, and item level. For every Teams team: owners, members, and private channel membership. Store as a structured mapping file.
Mail Routing Configuration
Set up bidirectional mail flow connectors between source and target tenants. Configure forwarding for migrated users. Verify routing for all SMTP aliases and secondary domains. Test with external senders before cutover. Consider using Cloudiway's built-in coexistence to handle this automatically.
Pilot Migration and Validation
Migrate a pilot batch of 10-20 users that includes at least one delegate pair, one shared mailbox with multiple delegates, one Teams team owner, and one user with a large mailbox. Validate every aspect of the migration against your checklist. Do not proceed to production batches until the pilot passes all validation gates.
Rollback Plan With Triggers
Define specific, measurable triggers for rollback: more than X% of mail delivery failures, more than Y delegate access failures, or more than Z support tickets per hour. Assign a decision-maker. Keep source environment fully operational until the post-cutover validation period ends. Budget for rollback in your migration cost model.
Avoid These Failures in Your Next Migration
Cloudiway's migration platform includes automated discovery, pre-migration validation, built-in coexistence, and post-migration verification -- addressing all seven failure categories in a single integrated workflow. Talk to our team about your project requirements or get an instant quote for your migration scope.
