Microsoft 365 Tenant Migration with AAD Connect reusing same domain

Recently we had a need to migrate to a new tenant space largely due to COVID19 and extreme downsizing and company structure changes.  I can't stress enough that a successful migration is about planning and staging before any of the migration has actually begun.  Additionally, use AAD Connect to your advantage!  Convert as many cloud only accounts to internally sync'd accounts as possible as this can save you a ton of work.

Note: I'm not going over adding the necessary PowerShell modules Microsoft 365 that are needed.

This is not a comprehensive guide as each environment is going to have it's own unique areas, but this worked great for me and can be used as a template for someone else.

The migration had a few requirements.

1. We had an internal domain connected with AAD Connect - intdomain.com which was not the primary domain in tenant.
2. There were 8 domains total in the tenant used for various email accounts. 4 domains were moving, 4 were not.  The intdomain.com was moving
3. A handful of users had a single user account with email addresses across all 8 domains!

I found that planning for this was very complicated, but execution was actually very simple!  Note that this was for under 50 users and I completed it solo.  I'm sure it could be simplified farther with more scripts or tools.  

Planning / Staging:

First I started with looking at all the different types of accounts and integrations that would be effected. In particular sorting through various service accounts setup for SMTP Auth when these accounts are both cloud only or internal sync.  Additionally, some users are cloud only accounts.

So to start, a handy export was needed from the Tenant - Users and Groups into csv.  You can then change this file to xlsx and start adding more columns and add a filter.  I recommend then adding columns for identifying which accounts are for SMTP Auth, break down which are AADSync (which is included in the export), which accounts need to have Forwards in place to new tenant, which domains are moving, etc.

Now came pre-staging of the OLD environment.  

Since I had accounts that had emails across all 8 domains I began to identify them and break them into 2 accounts.  The one that had domains that would be moving set as Internal AD accounts.  The ones not moving I created new cloud only accounts and setup forwards to their internal account.  This could easily be scripted for large groups.  I used Shared Mailboxes to save on cost.  I used Forwarding instead of adding permissions to the shared mailbox so that after migration I wouldn't have to change them again.

I did the same thing for any Shared Mailboxes, Distribution groups, etc.  Get everything for the domains that are moving converted to AAD Sync internal groups if possible!  With this when you reconnect AAD Connect to the new tenant and do the first sync all of your work will be done for you.

I also moved SharePoint and Onedrive.  For SharePoint our sites were small and not built out, so a simple "Mover" migration was sufficient.  You can find a link to mover in the SharePoint admin console under migration.  I didn't actually migrate Onedrive, instead we handled that from the client computer end (ie disconnect then reconnect to new tenant and let it upload everything again).

Create new Tenant:

You can create your new tenant at any point, you'll just need to add a valid license to it.  Of course the tenant name will be yourname.onmicrosoft.com, make it a good one this time!  Learn from my mistakes, DON'T make it the company name, who'd of figured those could change so often... marketing people... ;)

Create a user account for each user account that will be moving.  This can easily be scripted.  They will all have name.onmicrosoft.com for their username. 

Note: we licensed ours several days prior to migration.

I also added one AAD Premium P1 license and one Azure Information Protection Premium Plan 1 to the new tenant.  This allowed us to do a lot of configuration to the environment prior to migration.

Ie, SharePoint pre-stage and config, Exchange rules and other config, Spam filter, and the gobs of other settings that I wanted locked down.

Week prior to Migration:

We used BitTitan MigrationWiz to move our mailbox information.  So, we did a pre-stage less 30 days 1 week prior to the go day.

I also informed everyone that everything was going to break on the "go" day.  For simplicity sake we had each user leave their computer turned on so that we could manually fix their Teams, Onedrive, Outlook, Office apps, and MS Edge Sync on day of migration.  This was doable for us do to our small user count.  I'm sure there are better ways...  More on what I did to fix each app at bottom.

I also pulled all of the LegacyExchangeDN just in case I needed them.  Easier now then later...

Get-Mailbox | Select Name, PrimarySMTPAddress, LegacyExchangeDN | Export-Csv 'pathtofile\LegacyExchangeDN.csv' -NoTypeInformation

Get-DistributionGroup | Select Name, PrimarySMTPAddress, LegacyExchangeDN | Export-Csv 'pathtofile\LegacyExchangeDNgroups.csv' -NoTypeInformation

Create a user migration List:

Also, I created a csv file of all my users I had pre-staged in the new tenant.  On day of migration their UPN will need changed prior to reconnecting AADConnect and I wanted it done easy.

CSV file needs to have at least 2 columns with the following headers.  Name this userCloud.csv

PrimarySMTPAddress and UPN

PrimarySMTPAddress is the username in the new tenant, ie jdoe@name.onmicrosoft.com

UPN is proper primary email address you will want them to have. ie jdoe@mydomain.com

Day prior to Migration:

On the day prior I ran another Pre-Stage with MigrationWiz to get everything up to that day.  I don't want to be sitting around for hours waiting for the final staging.

Day of Migration:

1. Changed MX Records to an invalid record for each domain.  This made any mail sent to us get "held" by the sending server for retry instead of giving back an NDR.  I want all that mail to come through once I've moved the domains.
2. Run the final MigrationWiz, I also removed everyone's access from SharePoint.  Wait for final pass to finish before proceeding!
3. Add an empty root OU to AD, this is temporary.
4. Run AADConnect configuration, and point it to that empty root OU you just created.  When the sync runs there with be NOTHING to sync and so it will process this as removal of ALL of your AADSync objects.  Just like that it removed everything for you so you can remove your domains.
5. Remove any objects that were cloud only objects for the moving domains.  
6. Under Settings - Domains - click on each domain and go through the tabs, you'll see what objects are left on each domain.  Once the domains that are moving are cleared of all objects you can delete each of the domains!
7. Now you can go to your new Tenant and add each domain. Hint: use a different web browser for each tenant so you're not having to constantly login and out. For PowerShell use 2 different VM's.
8. Now we're going to fix the UPN for all of the new Tenant pre staged users.  You're going to use the CSV you created with Powershell
$users = Import-Csv 'path to file\userCloud.csv'
foreach ($user in $users){Set-MsolUserPrincipalName -UserPrincipalName $user.PrimarySmtpAddress -NewUserPrincipalName $user.upn }
9. Now all of the users in the new tentant have the proper accounts that MATCH their internal Active Directory UPN's.  This way AADSync will automatically associate them properly.
10. Go back to AADSync and configure it to point to your proper OU's again.  Let the sync run and bingo, you now see that it associated properly AND all your groups are back and created / populated with group membership.
11. Fix your MX Records and test!  Don't forget to setup SPF, DKIM, DMARC again as needed.
12. Note that you need to create "cloud only" distribution groups and add membership back.  If you converted them to Active Directory prior then they where automatically created by the sync
13. Test your emails setup out again!  Send and Receive
14. Now it's time to fix apps

Fix Apps: 

I found this part to be the worst.  Overall it went fine, but it's tedious.

Note this is for Windows 10 only.  Other OS's may be different.

Some machines signing out in one place caused others to auto sign out.  Some didn't, IDK.

1. I started with ensuring everything was closed.
2. Opened Control Panel, switch to small icons, open Mail, Show Profiles, Delete
3. Opened Excel (or Word), File, Account, Sign Out
4. Open Settings, Accounts, Accesss work or School, expand the account, Disconnect.
5. Also checked under Accounts, Email & Accounts, and removed anything I could. 
6. Opened Edge browser, Settings, Sign Out of profile, Did not clear their favorites and other info.
7. Dumped linkes to SharePoint as I saw this (and added the new site)
8. Opened OneDrive and Unlink this PC (note it prompts that it will stop synching and a copy of the files will be left on the PC).
9. Open Teams and Sign out
10. Reboot
11. Open up each and setup new.  Edge, OneDrive, SharePoint, Office, Teams.  Note that GPO's or Azure AD can help do this automatically for you with SSO and device mgmt if you have it.

Finally, notified users to sign out of Teams, SharePoint, Onedrive, etc on their mobile phones.  In Outlook mobile app delete the account (for Onedrive connector too) and add back new.

Clean Up!

At this point you should be back up and running.  Time to just start combing through settings and objects and doing any cleanup that is necessary.  Hopefully if you did this it went as well as mine did.  

Don't forget your scanners and other components that use SMTP Relay or alerting of that sort!

I'll also throw SharePoint in here, I had used Mover to move everything after the fact and then manually added back permissions.  We weren't using a lot of SharePoint at the time so it wasn't a big deal.  Of course, if you're using powerapps, powerautomiate, lots of SharePoint, and other then you'll want to spend more time than I did looking at these solutions.  (we do now, and what a nightmare that would be all on its own!)

Hopefully this helps someone.