Microsoft 365 to Microsoft 365 Migration Watchpoints

Migration Admin Requirements

See: Do I Need a Global Administrator (GA) Account for Microsoft 365 Migrations?

How Identities Rebind at the Destination

• Behaviour: In a tenant-to-tenant move the same people exist on both sides, so collaborative content is reconnected by matching source addresses to destination addresses. The Address Replacement CSV is what performs that match. It is what re-assigns permissions on shared files, resource bookings on calendar entries, and delegated access to the new accounts.
• User Impact: Where an address is missing from the mapping, the content still migrates but arrives pointing at the old tenant. Users lose access to shared data, and room and equipment bookings do not bind to the migrated appointments.
• Recommendation: Map users, aliases and groups, and cover every batch type including Resources, Groups, SharePoint and Teams.

Encrypted Items

• Mail: Encrypted mail items arrive at the destination in their encrypted state and remain readable, because both ends are Exchange Online.
• Documents: Documents protected by Microsoft Information Protection or Azure Information Protection labels that enforce encryption do not arrive. They fail at export and must be decrypted at the source beforehand.

Entity Creation

During a migration to Microsoft 365, CloudM Migrate supports the creation of all supported entities.

• Users: Configuration > Destination > User  it only creates users. It cannot license them (no license: no mailbox nor OneDrive!) nor provision OneDrive. See OneDrive Must Be Pre-Provisioned for more information.
• Shared Mailboxes: Shared Mailboxes cannot be created, only users which may be converted to Shared Mailboxes in Microsoft 365. They are migrated as Export & Import Type: User. See Shared Mailboxes for more information. 
• Microsoft 365 Groups & Microsoft Teams: M365 Groups & Teams are created  
• SharePoint Team Sites:
  • Document Libraries:
• Resource Calendars: No notes.
• Public Folders: No notes.

The first four behaviours below are the common causes of mail that appears to be missing after cutover. Troubleshooting Missing Emails After a Microsoft 365 / Exchange Migration is the article to work through when a user reports a gap.

Item Classes and "Missing" Mail

• Behaviour: Only items with the message class IPM.Note and its subclasses are migrated. Non-Delivery Reports, read receipts and system messages are skipped, and they are not logged as failures, so item counts at the destination can be lower than the source with nothing in the logs to explain it.
• User Impact: This is the most common reason users report items as missing after a migration.

The Online Archive Is a Separate Mailbox

• Behaviour: A user's Exchange Online Archive is a separate mailbox from their primary mailbox and is not included in a standard mailbox migration. It has to be migrated in its own right, and it covers mail only.
• User Impact: The primary mailbox migrates perfectly and years of archived mail never leave the source. This is a common cause of apparently missing historical mail after a tenant-to-tenant move.
• Note: Destination users need archive mailboxes enabled before that migration runs, or the mail has nowhere to land.

Litigation Hold and Recoverable Items

• Behaviour: Items held in Litigation Hold or sitting in the Recoverable Items folder live in non-IPM folders and do not arrive at the destination by default.
• Recommendation: Check for holds on the source with Get-Mailbox "username" | Format-Table LitigationHold*. To bring them across, enable Recoverable mail items at the source, and use Recoverable items destination to choose whether they land in Recoverable Items or in the mailbox itself. A label or category can be applied so they are identifiable.

Destination Retention Policies Act on Arrival

• Behaviour: A retention policy on the destination tenant acts on migrated mail the moment it lands, and can move it straight to an archive or compliance folder. The mail migrated successfully but is no longer in the user's primary mailbox.
• Recommendation: Relax aggressive destination retention policies for the duration of the migration, and check the destination Online Archive before raising an issue.

Mailbox Rules

See: Migrating Microsoft Outlook/365 Mailbox Rules

• Behaviour: Mailbox rules carry over on this path, which cross-platform migrations cannot do. They are opt-in via Configuration > Source > User > Migrate mailbox rules.
• Addresses inside rules still point at the source tenant unless Advanced Settings > Domain Replacement > Email is also enabled, because rule addresses are rewritten by domain replacement rather than by the rule migration itself.
• Rules are not refreshed on delta passes. A rule already migrated is left alone, so editing a rule between passes leaves the old version in place alongside the new one.
• Empty source folders referenced by a rule are not created at the destination, so the rule arrives pointing at a folder that does not exist.
• "Pin to Top" actions cannot be recreated and the whole rule is skipped.

Out of Office and Delegates

• Behaviour: Out of office settings and account delegation carry over on this path, which cross-platform migrations cannot do. Each is a separate opt-in setting under Configuration > Source > User: Migrate out of office and Migrate account delegates. Mailbox rules, above, are the third setting in this group.
• User Impact: Neither out of office nor delegation is on by default, so a project that assumes they travel with the mailbox will find delegated access missing at cutover.
• Signatures are not supported for migration currently. Users need to re-create their signature at the destination.

Folder Names Containing a Forward Slash

• Behaviour: A source folder whose name contains a forward slash arrives as two folders. "Forward/slash" becomes a folder named "Forward" containing a sub-folder named "slash". This is how Exchange handles the character on import, not a CloudM Migrate behaviour.
• Recommendation: Rename the affected folders at the source before migrating.

Folder Name Collisions with Protected Folders

• Behaviour: Every Exchange mailbox has protected, special-purpose default folders. Where a user has a mail folder with the same name as one of them, the migration fails for that folder with ErrorFolderExists, because mail cannot be placed into a special-purpose folder.
• The most common example is a mail folder named "Notes", which collides with the default Outlook Notes folder. The other protected names are Calendar, Contacts, Tasks, Journal, Drafts and Sent Items.
• Recommendation: Audit source mailboxes for these folder names and rename them before migrating.

"Sync Issues" Folder Becomes Visible

• Behaviour: The Exchange-generated "Sync Issues" folder, and its Conflicts, Local Failures and Server Failures sub-folders, are hidden from the user on the source but are read as ordinary mail folders. They arrive at the destination as visible folders. Users can safely delete them afterwards.

Recurring series behave differently from single appointments, and per-instance customisations do not all survive. That detail is covered in full by Migrating Recurring Calendar Events: Supported Scenarios and Limitations, which is the article to read before migrating calendar data. The two behaviours below are specific to an Exchange destination.

Split Series Are Not Linked in Exchange

• Behaviour: Where a recurrence rule cannot be recreated accurately, the series arrives as individual appointments so that the entries are at least present. Exchange does not link those appointments, so editing one occurrence at the destination does not affect the others.
• Recommendation: Advise affected users to delete and re-create the series at the destination if they need it to behave as a series again.

Time Zones and All-Day Appointments

• Behaviour: Where a user's calendar time zone differs between the two tenants, events arrive in the wrong time zone and all-day appointments can appear a day out.
• Recommendation: Confirm users have matching calendar time zones on both tenants. As a fallback, set Exchange 2010/Microsoft 365 calendar time zone in the destination settings so a default is applied where no time zone is found on the source item.

Resource Bookings and Address Replacement

• Behaviour: Room and equipment bookings arrive on the migrated appointments, but they only bind to the correct destination resource where the Address Replacement CSV maps the source resource address to its destination equivalent. Without that mapping the appointment arrives with an unresolved room.

Outlook Notes

• Behaviour: Outlook Notes arrive as-is between Microsoft 365 tenants, with content and formatting preserved. On cross-platform paths they have no equivalent at the destination, so this is one of the few data types that survives intact only on a same-platform move.

Default Document Library Name and Tenant Language

• Behaviour: Default document library name must match the name of the library OneDrive actually uses in that tenant. English tenants use "Documents", but other languages differ, for example "Dokumente" in German or "Documentos" in Spanish. Where it does not match, the library is not found and nothing migrates for that user.
• Note: This applies separately to the source and the destination, so a migration between tenants in different languages needs a different value at each end. The same applies to the Given Name field when adding SharePoint sites to a batch.

OneDrive Must Be Pre-Provisioned

• Behaviour: A user's OneDrive site is not created when a license is assigned. It is provisioned the first time the user opens OneDrive. Until then the migration fails for that user with BadRequest ... Unable to retrieve user's mysite URL.
• Recommendation: Pre-provision OneDrive for all destination users in bulk via PowerShell before the migration starts, rather than resolving this one user at a time.

400-Character Path Limit

• Behaviour: SharePoint enforces a 400-character limit on the total file and folder path. Folder and file names are truncated automatically to bring paths within the limit, so files can arrive with shortened names. Paths still over 400 characters after truncation fail.
• Consolidated Long Paths: items that still exceed the limit are placed in the folder named in this destination setting. Leaving the field empty causes those items to fail instead.
• Recommendation: Remediate over-long paths at the source before the bulk pass so filenames stay meaningful at the destination.

SharePoint Team Site/Document Library Folders

It's not possible to specify a folder within a SharePoint Team Site. The deepest level of specificity is Document Library. SharePoint Team Sites may be migrated entirely, or by specifying Document Libraries therein using the Documents path field in your Items to migrate.

Document Version History

Previous document versions can be carried across on this path. The behaviour of what arrives has several watchpoints.

• Major versions only. Minor and unpublished draft versions do not arrive.
• Version numbers are not preserved. Where fewer versions are migrated than exist at the source, the destination renumbers them from 1 upwards rather than keeping the original numbering, so version 12 at the source can arrive as version 3.
• Whole-document failure: if any single version fails to export or import, the entire document fails, including its current version.
• Files of 2GB or larger fail when versioning is enabled. Put those items in a separate batch with versioning disabled.
• Delta behaviour: raising the maximum version count and re-running does not bring extra versions across unless the current version has also changed at the source.
• Extra metadata associated with a version, such as a file rename, does not arrive.
• ⚠️Time and volume: As an example, five previous versions means roughly five times the data per document. Enable it on the bulk pass rather than at delta stage, and plan the schedule around it.
• Required API settings: the source SharePoint Migration API must be disabled and the destination SharePoint Migration API must be enabled. Changing these defaults removes access to the feature. Versioning is set per configuration, so sites or libraries with different version requirements need their own configurations.

Custom Document Metadata

• Behaviour: Include document metadata carries custom SharePoint columns across on this path and is off by default. Standard metadata (Title, Description, Created, Modified, Author, Editor) always arrives regardless.
• Column types that arrive: single line of text, multiple lines of text, number (including currency, integer and decimal), Yes/No, and date and time.
• Column settings are reset to SharePoint defaults at the destination. Default values, enforce unique values, column validation and calculated fields do not arrive.
• User Impact: migrated custom columns are hidden by default in the destination interface, so the metadata looks missing until a user adds the columns to a library view via Column settings and Show/hide columns.
• Licensing: each custom metadata column migrated for a site or user counts as a single SiteMetadata item in the migration summary report.

Permissions and Group Mapping

• Behaviour: Sharing permissions arrive only where Document sharing/permissions is enabled at the source. Patch permissions at the destination adds, updates or deletes permissions on already migrated items so they reflect later source changes.
• Group permissions do not map to distribution groups. For a document's group permissions to arrive, the destination group must be a Microsoft 365 Group, a mail-enabled security group or a security group. Permissions held by a distribution group are dropped.
• Note: mail-enabled security groups and security groups need a suffix in the mapping, for example ExampleMailEnabled@contoso.onmicrosoft.com|mailsecuritygroup and ExampleSecurity|securitygroup.

Communication Sites

• Behaviour: Communication Sites are SharePoint entities and must be treated as Team Sites, even where the URL contains /teams/. Placed in a Microsoft Teams batch they fail, because they have no underlying Microsoft 365 Group or Teams architecture.
• What arrives: the file data in the site's document library. Site pages, web parts and navigation settings do not arrive, so the destination site looks structurally empty even where all the files are present.

Teams needs its own batch and a multi-pass approach. The choice between Direct and Standard mode decides what the destination actually looks like, and the two modes support different content. Migrating Microsoft Teams to Microsoft Teams carries the full in-scope and out-of-scope table for each mode. Read it before choosing a mode, because the decision is difficult to reverse once a Team is finalised.

What Channel History Looks Like: Direct Mode Versus Standard Mode

• Direct Mode uses Microsoft's Import mode and rehydrates channel Posts into the destination channel's own history, so conversations appear in Teams as they did at the source.
• Standard Mode does not rehydrate Posts. Conversations arrive as mail items in the group mailbox, as an HTML document on the Team's SharePoint site, or both. Where they arrive as a document, the HTML file is linked from a conversation in the Posts tab, so users see a single post linking to an archive rather than a conversation history.
• User Impact: the two modes produce visibly different destinations for the same source data. Confirm which one the project is using before setting expectations with stakeholders.

What Is Absent from Rehydrated Channel History

• Behaviour: Direct Mode rehydrates channel messages with their original created time, inline images, @mentions, rich text, reply chains and links to existing files, so the history arrives looking complete. Reactions, videos and announcements do not appear, and content from 1:1 and group chats, private channels and shared channels is not part of this pass at all.
• User Impact: because the conversation history looks complete, the absence of reactions in particular is usually noticed only after cutover.
• Recommendation: Check the mode comparison table linked above for the full list, and set the expectation before the bulk pass. Private channels and 1:1 chats have their own behaviours, covered below.

Teams Stay Inactive Until Finalisation

• Behaviour: During a Direct Mode migration the destination Team is created in a restricted state. It stays inactive and members cannot see or access it until finalisation completes. Where mail is included, the related Microsoft 365 Group mailbox arrives but is hidden, and is not accessible via Outlook until finalisation.
• User Impact: Between the bulk pass and finalisation the Team appears to be missing at the destination. Set this expectation with stakeholders beforehand.

A Finalised Team Cannot Be Migrated Again

• Behaviour: Once finalisation has run against a Team, no further migration can be performed against it. Anything missed at that point cannot be added by re-running. Confirm content is complete before finalising.

Private Channels

• Behaviour: Private channels do not arrive through a Direct Mode pass. They need a separate Standard Mode pass, run after finalisation once the destination Teams are active.
• Channel members must already exist in the destination domain, or the channel arrives without them.
• Channel email does not arrive, because the mailbox is shared across the whole team rather than existing per channel.

Teams Planner

• Behaviour: Planner needs at least two passes and arrives after conversations and documents. Plans, plan titles, owners, plan settings, buckets with their titles and order, and tasks including assignees and timestamps all arrive.
• Does not arrive: task comments, and custom names given to coloured labels. Labels arrive as their default colour names.
• Assignees only resolve where the user is present in the items list, even if that user is not ticked for migration. Tasks assigned to anyone missing from the list arrive unassigned.

Channel Tabs

• Behaviour: Only website tabs and document tabs arrive. Every other tab type is skipped on export and reported in the logs, so a channel with a Planner tab, a Power BI tab or a third-party app tab arrives with those tabs gone.
• Document tabs only arrive where the document lives in the Team itself, not in a personal OneDrive or on another site.
• Note: A migrated document tab that will not render a preview has still arrived correctly and can be downloaded and viewed as normal.

Renamed General Channel

• Behaviour: Where the General channel has been renamed at the source, it arrives as a new channel at the destination. The destination team therefore has both an empty General channel, created automatically when the team was provisioned, and the renamed channel holding the migrated content.

Private (1:1) Chats

• Behaviour: Where Rehydrate Teams private chats is used, only the most recent 10 messages of each chat appear in the users' Teams client. Everything older is archived into the user's mailbox rather than appearing in Teams.
• User Impact: Users open a migrated chat, see ten messages and conclude the rest is lost. Tell them where the archive lands: the folder is named by Advanced Settings > Email > Private chat top-level folder.

See: Migrating Microsoft Shared Mailboxes

• Behaviour: Shared mailboxes are not picked up automatically when the items list is populated. Unless they are added by hand they are simply absent from the migration, with nothing in the logs to indicate they were expected.
• They are added as users, not as shared mailboxes. Set Export Type: User with the primary email address of the source shared mailbox, and Import Type: User with the primary email address of the destination shared mailbox. The entity can be a shared mailbox at both ends. CloudM Migrate simply sees it as a user, and the migration is handled as user to user. Import Type can also be Group where the destination is a group rather than a mailbox.
• What arrives: delegate permissions from the source shared mailbox are fully supported on this path, and source folders and categories arrive as-is.

• What can be migrated to Microsoft 365? (supported features)
• Best Practice Guide: Microsoft 365 Tenant-to-Tenant Migrations
• Migrating Microsoft Teams to Microsoft Teams
• Migrating Recurring Calendar Events: Supported Scenarios and Limitations
• Troubleshooting Missing Emails After a Microsoft 365 / Exchange Migration
• Migrating Microsoft Shared Mailboxes
• Microsoft 365 Document Versioning Migration
• Migrating Custom Document Metadata to SharePoint / OneDrive