Cross Tenant Personal OneDrive Data Migration
In the previous chapters, it is stated: Teams make use of several M365 service. Especially for the personal side of Teams, Exchange and OneDrive are heavily involved.
migration, it is required, that ALL data is present in the target environment
for Exchange Calendar and OneDrive (shared files).
Data pre-load is much slow than you expected. This is the most important lesson learned.
While Exchange is
faster than OneDrive, be aware of the time required for the data copying
statement is: none of the existing solutions are SYNC solutions, data is only
copied. Therefore, a co-existence and working parallel in both, source and
target tenant can lead to data inconsistence. If data is changed in the target
environment and in source, any delta sync will overwrite the target data, if
source has a new change date. Same, if the target data is newer, changed source
data will not be copied.
All service in M365 are throttled !
Throttling limits are different across the tenants, smaller tenants have low
limits than larger tenants.
For Exchange, throttling
can be lifted upon certain stage. This must be requested via the support center
in M365. But it is NOT removed.
For OneDrive, this is
even more complex and throttling will occur. There is NO possibility lifting or
removing throttling. Up on throttling limits are hit, the only possibility is
WAITING and reducing the read/write request.
OneDrive, which is
part of SharePoint Online has the following rough guidelines:
The following table
provides estimates of the type of speed you may achieve based on the types of
content you're migrating.
Type of metadata
ISO files, video files
Office files (~1.5 MB)
List items with custom
columns, small files (~50 kb)
250 GB /day
· Large file size migrates faster than smaller ones.
Small file size can result in larger overhead and processing time which
directly impacts the performance.
· Files migrate faster than objects and list items.
Lets do a quick and
simple calculation. Assuming a tenant has 10.000 users and 500TB or SharePoint/
It can simply take up
to 500 days migrating all data into the new target tenant!
Plan enough time for data migration. Test the speed between the production tenants. Be aware, that the migration slows down over time. If you are close to completion, the migration speed will be slower than the former average.
Speeding up the
migration can only be archived by the following 2+1 solutions:
1. Clean-up your environment. Delete and data not in use,
or not required.
2. Limit the amount of data required, e.g. do not copy
version history, only data to certain date
3. Use archiving/ backup solutions and store data
anywhere else, e.g. Azure or on-premises.
Limiting the amount of data required to be copied.
There may be new tools
in the future and it might get better and faster.
In the T2T migration, both tenant will have a co-existence phase. In each tenant DNS Names are registered and used for external service communication. This is from UPN login, Email (SMTP) and Teams SIP calls. A DNS name cannot be registered into two tenants at the same time. The Authority record will not allow this with M365.
There are solution,
providing better user experience, but some service do not allow you working
with both DNS names. Realtime solution, like Teams and data protection solution
have no work-a-rounds.
For T2T migration you
have two choices, either you apply the target DNS to all migrated users and
service, while retire the source DNS domain. Second option is, migrating the
source DNS domain into the target tenant during source tenant decommissioning.
1. SMTP/ Email
Make use of an external cloud based SMTP redirect solution. This will allow an redirect of mail flow from source to target, keeping externally the same DNS domain in your emails send and received.
2. Teams SIP/ Chat and Calls, Meetings
There is NOT possibility redirect or masking SIP flow with two DNS domains. Therefore, during user migration, a user migrated to the target tenant cannot have the source DNS SIP domain. You must use the existing DNS domain, or a temporary DNS domain.
3. Data Protection (MIP/AIP)
MIP depends on an encryption key created in the source tenant, which is build based on the source DNS name. Therefore authentication/ de-/encryption is based on this.
Migrated content, not decrypted will only be accessible as long the source key exists. Therefore I suggest either migrating the key while you move the source DNS domain to the target tenant.
If the target DNS domain shall be used instead, you must de-crypt the data before copying and re-encrypt the data with the new MIP key in the target.
Another challenge are
the shared services, like Teams Team/Channel or SPO and M365 groups service, as
well as other service like Yammer, … There is no simple solution, providing
access to a migrated user from target to source. Two possible solution you can
1. Keeping the user account in source active, while
disabling the personal services if the user is migrated. The user must work in
both tenants. This is complex situation for most of the users.
2. Make us of Guest Access and provide for each user who
is migrated a corresponding guest user access in the source tenant. This is at
least a solution he could life with. But for the migration team, this is
extremely complex and work intense.
The only way making a
T2T less painful for users, is a proper Change & Adoptions approach. Key
users, Champions and more would make a T2T migration more successful.
Mapping is a feature that can be used during migrations from one Microsoft 365
organization to another (commonly referred to as a cross-tenant or
tenant-2-tenant migration). It provides a secure method of establishing one-to-one
object relationships across organization boundaries and automatically
prepares the target objects for a successful migration.
Identity Mapping, data remains within the Microsoft security boundary and is
securely copied directly from the source organization to the target
organization using specially configured Organization Relationships serving
as a unidirectional trust.
This blog article is still designed for 3rd party tool usage and might be updated at a later stage.
OneDrive migration approach:
During mergers or
divestitures, you commonly need the ability to move users OneDrive accounts
into a new Microsoft 365 tenant. With Cross-tenant OneDrive migration, tenant
administrators can use familiar tools like SharePoint Online PowerShell to
transition users into their new organization.
administrators of two separate tenants can use the Set-SPOCrossTenantRelationship cmdlet
to establish an organization relationship, and the Start-SPOCrossTenantUserContentMove command
to begin cross-tenant OneDrive moves.
Some special charaters in users names aren’t supported with ODB cross-tenant migration. This are: “_”, ….
cross-tenant license has been assigned to a user before cross-tenant migration.