I cannot possibly see how this MX record swap is going to work...

[thecomputerguy]

Company A and Company B

Company A bought Company B and is now the parent company. I am the MSP for Company B... Company A, the now parent company has their own MSP and a single in-house IT person. The parent company is out of state and has retained me for MSP services for Company B because they want to maintain a local IT provider (me).

Company A stated that they want to absorb Company B into their tenant under their email structure.

johndoe@companyb.com

Will now become

johndoe@companya.com

They asked if I would handle the migration and I said I would but it would be billed outside of the MSP agreement as this is not maintenance for the tenant, this would be billed as a separate project. They said they would check with their MSP as their MSP contract is all encompassing. Their MSP agreed to do the migration as a part of their contract and asked for Global admin on Company B. I happily obliged as migrations have increasingly become more difficult as security has increased at O365. Now as Company A is the parent, they are my Boss now.

They are ready to do the cutover and I said OK, I'll just need to enable external forwarding on the Company B tenant so that we can forward emails from johndoe@companyb.com to johndoe@companya.com

They said uhh no we're just going to change the MX record. I explained that I don't think that is going to work because of the DNS being a mismatch and the email records not aligning.

So TLDR, essentially they believe that post migration, they can change the DNS on Company B to match Company A and all new emails sent to johndoe@companyb.com will magically deliver to johndoe@companya.com

So they are changing the record as follows:

Current: 0:companyb-com.mail.protection.outlook.com
Post Migration: 0:companya-com.mail.protection.outlook.com

I don't see how emails sent to johndoe@companyb.com will somehow magically make it to johndoe@companya.com into an entirely different mailbox on an entirely different domain.

All of their current clients will still be emailing johndoe@companyb.com obviously until companyb.com gets organically phased out.

Am I wrong here?

God just typing all that out sounds confusing as hell, I hope it makes sense.

I have a feeling I am slowly being phased out as after this I will essentially lose control of any user management as I was not granted any tenant access at Company A. So no password resets, no new users, no O365 backup, no MFA resets ... nada. It's getting a little messy as I will not be able to adequately tend to the needs of Company B.

But it is what it is for now.

 

[Sky-Knight]

And they are absolutely correct. You are performing a tenant to tenant migration.

You... buy an appropriate number of MIgrationWiz licenses. You make sure all your mailboxes have an onmicrosoft.com email address. You create new destination mailboxes. You configure MigrationWiz to map the onmicrosoft.com mailboxes in the source tenant to the new mailboxes in the destination tenant. You start syncing mail... (note at this point the migration is usually using onmicrosoft.com addresses on BOTH sides)

Then you document who has what email addresses.

On cutover day...

You drop the domain from the source tenant. (mail sync is still working because you did onmicrosoft.com)
You add it to the destination tenant.
You add the old emails as aliases to the appropriate mailboxes.
Users are instructed to reconfigure M365 logins.

You wait a day or so, and run a final sync of mail with MigrationWiz, and finally kill the source tenant and migration software.

A fair bit of this will be on them to do, you need access to BOTH tenants to migrate mail.

Now, there's a fair bit MORE work to do to migrate SharePoint and other components, but that's the mail rundown.

Given this exchange, I expect they're doing this in a rough way to make you look bad... beware.

 

[thecomputerguy]

And they are absolutely correct. You are performing a tenant to tenant migration.

You... buy an appropriate number of MIgrationWiz licenses. You make sure all your mailboxes have an onmicrosoft.com email address. You create new destination mailboxes. You configure MigrationWiz to map the onmicrosoft.com mailboxes in the source tenant to the new mailboxes in the destination tenant. You start syncing mail... (note at this point the migration is usually using onmicrosoft.com addresses on BOTH sides)

Then you document who has what email addresses.

On cutover day...

You drop the domain from the source tenant. (mail sync is still working because you did onmicrosoft.com)
You add it to the destination tenant.
You add the old emails as aliases to the appropriate mailboxes.
Users are instructed to reconfigure M365 logins.

You wait a day or so, and run a final sync of mail with MigrationWiz, and finally kill the source tenant and migration software.

A fair bit of this will be on them to do, you need access to BOTH tenants to migrate mail.

Now, there's a fair bit MORE work to do to migrate SharePoint and other components, but that's the mail rundown.

Given this exchange, I expect they're doing this in a rough way to make you look bad... beware.

That makes total sense I didn't even think about them adding companyb.com domain to their tenant and using the old emails as aliases.