This post starts the documentation of a single project – migration of a bunch of users between two 365 tenants.This is Part One which goes over the project and planned approach. I will detail the steps including scripts, reports, actions an whatnot in future instalment then add some links in here. They will all be tagged with “T2T Migration Project”
Part One – Introduction and Approach
Part Two – Identifying Users and Objects
Part Three – Setup of New Tenant
Part Four – Data Migration with Quest-On-Demand
Part Five – Domain Migration
Part Six – Destination Tenant User Setup
All the scripts for this project are available at https://github.com/jmattmacd/O365-Tenant_to_tenant
So I recently found myself engaged to migrate 7800 users between two tenants. These were live on both sides so I had 1 weekend of interruption after which the migration must be fully completed.
The migration was complicated by a few issues
- The UPN and a email Domain had to be migrated. The UPN domain was Federated with an ADFS infrastructure. Thankfully the client was not requiring ADFS on the target, they were happy with pass-through authentication.
- The Source domain was synced with an AD Connect infrastructure which also synced another 40,000 users along with other object from 17 other AD domains.
- The data set (email, onedrive, teams, 365 groups) was around 25TB
Approach
The method I went with:
- Identifying and reporting on the objects (Users, groups, teams, DLs) which were in scope of only the target domain, the tenant is shared between 27 other business
- Setup of new tenant
- Pre-creating the accounts and seeding the data over a month and a half using Quest On Demand1
::Outage Window Start:: - Removing the domains from every object on the source tenant, setting everything with a temporary new domain
- De-federating the federated domain
- Dropping both domains from the source and registering them on the target
- Scripting the UPNs on the target tenant from the .onmicrosoft.com domain to the newly migrated original UPN domain
- Setting up a new AD Connect instance and syncing the users to the target using soft match to match the emails.
- Rebuild scripted out items from step 3
- Delta sync of data in Quest On Demand
::Outage Window Ends::
Rationale
- Preseeding the data. Most guides seem to recommend a cut off, the setting your new ad connect up to sync your users then shifting the data at 1 week, 1 month, 1 year, total increments. This always seemed crazy even on small scale deployments, soft match works perfectly fine so long as you remember to change the UPNs and primary SMTP addresses to match and dont have any duplicate entries. In my case I wont because I am scripting them out of a tenant which is on AD Connect.
- Quest On Demand. There are loads of these third party data moving tools. I will at some point review the ones I’ve used including Quest but they all do pretty much the same thing – Connect to mailboxes with EWS using impersonation and drag the data over. Quest also does Team chats, SharePoint, 365 groups and most importantly is comparatively cheap. We bought it direct at £6.70 a user license but that was buying ~8000. It is not without issues which Ill document when I write that part but with some light persuasion and cajolery it did what I needed. Again I’ll go through its Pro’s and Cons in a review later
Links
1 QUEST ON DEMAND – https://quest-on-demand.com/#/landing
