Office 365 Tenant Migration - What to look for in a failed scenario

I was working with a client recently that involved migrating several companies into a single Microsoft 365 tenant.  One of those companies already coexisted in a separate 365 tenant and needed to migrate to the new universal tenant.  Migrating the domains attached to the old tenant involves separating those attributes in Active Directory that are attached to the domain.  The attributes that we are concerned with are as follows:

There are alot of additional factors to consider when migrating between tenants such as what services are being utilized by the old tenant.  Typical items include:

In my scenario, I had to worry about Exchange and SharePoint.  The company was using Exchange Online Protection to scrub their inbound mail, then forward it onto the on-premise Exchange servers for delivery.  They were not utilizing 365 mailboxes.  The migration for this service was fairly simple.  Stop mail-flow to the old tenant.  Enable the users in the new tenant.  Redirect mailflow via MX record change to the new tenant.  The client was also moving away from EOP for their primary spam\virus protection and wished to utilize Mimecast for these services.  We were able to configure Mimecast and then use it direct mail directly to the on-premise servers and then at our discretion to the EOP services in 365 on the new tenant.   If you were concerned with keeping exiting settings of EOP you could use the following guide from Microsoft for migrating those settings:

As far as SharePoint was concerned, this was a bit more tricky.  We could not lose the accounts in the old tenant as deleting any of them to free up the domain for migration would cause all of their permissions within SharePoint to be lost once their data was moved.  We had to devise a plan to migrate the data and keep the security intact.  Ultimately, the SharePoint migration client (Content-Matrix) was configured to use the onmicrosoft upn on the source tenant, and the original domain on the target tenant.  This meant we had to have the dirsync to the new tenant completed, which meant the domain needed to be migrated beforehand.  

The tenant migration began simply enough.  The steps in this process are as follows:

  1. Stop the Dirsync on the on-premise Dirsync machine.  Disable the scheduled task.
  2.  Connect to Office 365 via Powershell
  3. Run the following script to change the UPN and the Primary email address for all objects in the source tenant (adjust last variable).
    1. Get-MsolUser | ForEach { Set-MsolUserPrincipalName -ObjectId $_.ObjectId -NewUserPrincipalName ($_.UserPrincipalName.Split(“@”)[0] + “”) }
  4. Perform a Get-Msoluser -domain
    1. This will give you a list of all users still attached to the domain that is being migrated.
After performing the above steps, I still had many users attached to the domain, even though their UPN and primary email address was changed correctly.  The only thing that was common for these users were these users had been previously enabled on premise in Lync.  Lync was no longer on-premise, and had been migrated to Skype for Business in 365 in a previous project.  It had also been decommissioned.  The fix for these users was to create a view in the 365 admin console for the source domain, and then remove and reassign their Lync license in 365.  Only after performing this step did the account become free from the domain.  I can not elaborate at this point specifically why this worked.  Perhaps there was an attribute within Skype that was tied to the domain, and the only way to clear it was remove and reassign the license.  If you find yourself with accounts that you can't explain, you may want to try this trick.

Once all of the users were no longer assigned to the domain I was safely able to delete the domain and reassign it to the new tenant.  I then created the Dirsync and imported the objects into the new tenant.  At this point, SharePoint security could be mapped between users and the migration was complete.

Labels: ,