Tenant to Tenant Migration (O365)

thecomputerguy

Well-Known Member
Reaction score
1,326
I've done plenty of migrations from Gsuite or Imap email over to O365 using MigrationWiz.

In this scenario... Company A bought Company B. Both have been working mostly independently. Company A wants to absorb company B into their tenant. Data for Company B is Email and Sharepoint Data. The Sharepoint Data is pretty minimal .... like under 50GB total.

The way I envision this... having not done before is:

1.) Setup licensed user accounts using either a temporary domain like companybtemp.com or by using Company A's .onmicrosoft.com domain.
2.) Perform the Migration from Company B to Company A temp accounts ... i.e.

joe@companyb.com to joe@companya.onmicrosoft.com

3.) Once the Migration is complete verify the domain using a TXT record on the new tenant
4.) Swap the primary email, per user, from the temporary domain to the new domain on the new tenant i.e.

joe@companya.onmicrosoft.com to joe@companyb.com

* Backup Sharepoint Data

5.) Unlicense all user accounts on the original tenant
6.) Delete all user accounts on the original tenant
7.) Delete domain from original tenant
8.) New mail comes to mailboxes in new tenant???

9.) Copy/Paste the Sharepoint data into a new Team on the new Tenant

Does that all sound close to right? Technically the DNS, at least MX and CNAME won't change so how does that work? I assume DKIM/DMARC will need to be redone along with looking over things like Threat Policies and CA Policies.

Or there is this:

1702401944148.png

** ACK FORGOT ABOUT ONEDRIVE STUFF TOO
 
The migration tools work via API now, an enterprise app that you bind into each tenant. In the old days yeah they just did user accounts on each tenant...so you had to think about the logic of the default user names...aka @mydomain.onmicrosoft.com versus @mydomain.com
And which is which, and when do you flip them, etc.
But now..it just puts an agent into each tenant.

What I like to do before migrations, like a week before migrations, punch into their DNS control panel and dial down the TTL for important records..esp those related to mail, such as the MX, and other mail related ones that will change. BUT..in this case...you're staying 365 to 365 and not many will change, just the DKIM really.

EMail is easy
OneDrive is easy
Sharepoint/Teams document libraries...can be easy, for honestly if it's simple..just a library or three..and that small, I'd just copy locally to a healthy rig...and upload it to the new tenant manually.
 
The migration tools work via API now, an enterprise app that you bind into each tenant. In the old days yeah they just did user accounts on each tenant...so you had to think about the logic of the default user names...aka @mydomain.onmicrosoft.com versus @mydomain.com
And which is which, and when do you flip them, etc.
But now..it just puts an agent into each tenant.

What I like to do before migrations, like a week before migrations, punch into their DNS control panel and dial down the TTL for important records..esp those related to mail, such as the MX, and other mail related ones that will change. BUT..in this case...you're staying 365 to 365 and not many will change, just the DKIM really.

EMail is easy
OneDrive is easy
Sharepoint/Teams document libraries...can be easy, for honestly if it's simple..just a library or three..and that small, I'd just copy locally to a healthy rig...and upload it to the new tenant manually.

migration tools work via API now, an enterprise app that you bind into each tenant.

Where do I find this in the source and/or destination tenant?

No need for BitTitan in this scenario?
 
Never do this without a tool like BitTitan, full stop. Just dont.

You will need the reports the migration tool gives you to prove completion, as well as find things that errored out for whatever reason.

Process is as you've described, except on the SharePoint side know that MigrationWiz can only move files, not the sites themselves. If you need to move a SharePoint site, your client is going to have to pay through the nose for a copy of ShareGate. And I mean it, it's $6000 for a year of that tool, and you cannot resell access to it. Your customer will have to buy it.

I will however say... that is hands down the best SharePoint migration and manipulation tool on the market. It's AMAZING.

If the SharePoint sites are just file bins though, MigrationWiz lets you build a matrix that connects source libraries to destinations, click play... watch things sync up just like the mailboxes.

The general migration flow you've already not nailed, setup a new tenant onmicrosoft.com, make all the mailboxes and what not, don't forget the distribution lists. Setup the migration software, babysit the syncs until you're happy, then... on cut-over day you punt the DNS.

I will however... make one suggestion...

Do NOT migrate from productiondomain.com. Make sure all the mailboxes you need to migrate are referenced via their onmicrosoft.com names. That way, when DNS flips the migration will still connect to the source and destination, and you can sync the straggling mail over.

We use the Bittitan User Migration Bundle when we do this.
 
Where do I find this in the source and/or destination tenant?

No need for BitTitan in this scenario?
Yes, BitTitan, or SkyKick, or whatever tool. They have the hand holding "how to guides"...pictures included 'n all. Pretty easy to follow.
After using BitTitan since they were "MigrationWiz"....and used it a few times during their first year or two out when it was just the 2x guys that departed from the Microsoft Exchange team...used to be able to email directly with them for support back then, but I actually find SkyKicks tools even better. However I'll have to use MigrationWiz shortly since I'm migrating from a commercial tenant to a GCC High tenant..and SkyKick doesn't support GCC tenants (yet). They both work great. Not that I don't like MW...I just think that SkyKicks whole service is a bit more, modern/polished.
 
Back
Top