Will server to server migration work cross-domain/cross-active directory?

Hi Jamony thank you for responding!

"the old "same org, new Exchange server, move mailboxes" method only works when both

Exchange servers are in the same Exchange organization and Active Directory forest."

This is what I have felt all along was the correct answer - but the problem is I can't FIND any authoritative statement in any of the Microsoft documentation that just states this plainly.  As I stated: "Documentation on microsoft.com seems to say at some points the servers will cooperate with each other and at other points it seems to say each mailserver is atomic"

This is what I'm tearing my hair out on.  It's like Microsoft wants to play both sides.  They want to make baloney marketing-driven claims "this is so easy the mailservers will always talk to each other" and they do this in some documents while in others they say "no you can't"

Do you have ANY authoritative link anywhere in the MS docs that says this is not possible flat out?

"If the new server is in a different AD forest/domain with a separate Exchange organization, it becomes a cross-forest migration. In that case you need a different plan:"

Yes it is absolutely in a different AD forest/domain.  As I said:  "the ACTUAL user ID on the old AD is WONKULATING\exampleuser while on the new AD it will be WONKULATINGGRONKULATOR\exampleuser"

WONKULATING is not the same forest as WONKULATINGGRONKULATOR  (the fact the names are not the same should have clarified this)

"Establish name resolution and network connectivity between forests."

Completed.  I can query any DNS server on the network in either forest/domain for machinename.wonkulating.com and machinename.wonkulatinggronkulator.com and get proper name resolution.

"Decide whether you need AD trust, ADMT, or identity matching."

Completed.  A trust exists between the 2 domains/forests, a user can login to one domain and access files on servers on the other domain without having to authenticate into the other domain, as long as proper rights are applied to the files/directories.   Microsoft no longer supports ADMT and after looking at it, there were far too many "gotchas" to mess around with it.  As I said " I'm not using ADMT or any of that to move user objects over to the new server so userIDs will exist in parallel for some time to allow a gradual migration of file and application servers."

"Use cross-forest mailbox moves"

The description of THIS process is in these 3 links I found:

https://www.petenetlive.com/KB/Article/0001356

https://learn.microsoft.com/en-us/exchange/architecture/mailbox-servers/prep-mailboxes-for-cross-forest-moves

https://learn.microsoft.com/en-us/exchange/recipients/mailbox-moves

According to this, I can only issue a "pull" request from the new Exchange SE mailserver to the old 2016 mailserver for a cross-forest move.  A "push" from Exchange 2016 to Exchange SE is not supported.

The first stumbling block here is the NEW mailserver  -newmail.wonkulatinggronkulator.com- must be able to make a SSL connection to the OLD mailserver -exchange.wonkulating.com-   But, since the old mailserver does NOT have a valid SSL certificate (since the org is using public certificates issued from public CAs who will of course not add wonkulating.com as an additional name into the certificate since we don't own it) it can't do that.

The OLD mailserver has a certificate with exchange.wonkulatinggronkulator.com, of course, and the new mailserver could contact it using that name. But, while a users ACTUAL active directory email address is user1 art wonkulating.com they have a secondary alias of user1 art wonkulatinggronkulator.com on the old mailserver.

So, even if we use MRS to make a migration, and it works, that global wonkulatinggronkulator.com needs to move to the new mailserver.  That means before starting a MRS migration of a mailbox, that global chance must be made - which the moment it is - the old mailserver stops taking mail for all the users and the new mailserver can't take mail for the users because the mailboxes haven't been moved over yet.  And the certificate likely becomes invalid.

Chicken, meet egg.

Basically, I'd have to stop incoming mail and then move all boxes at once.  But there's more fun with this in store I'll get to later.

"or a third-party migration tool."

Any tool like this would be written to use the APIs that exist for MRS (Mailbox Replication Service) Proxy, with is what the textbook commands for cross-forest migration use, and would fail if those commands would not work.  So it gets back once more to the certificate issue and the aliasing issue.

In summary, if I can't run New-MoveRequest in Exchange Management Shell, due to certificate issues like this, or the mailboxes not having the same GUID, then I can't run a third-party tool.

"Plan mail flow, Autodiscover, certificates, and accepted domains carefully."

I can't have one server forward mail to the other server because all incoming mail has destination email addresses of wonkulatinggronkulator.com so both servers believe the mail is supposed to go to itself, not to the other server.  So, mail flow is scotched.

"Move clients after mailbox and namespace cutover."

In other words to borrow a line from "Tron Legacy," a full-on sprint to the new mailserver for all 300 mailboxes.

The moment I cut namespace over the old mailserver stops working.  The only way to do this is to define an outage period, have all incoming mail spool on the bastion host, shut down incoming mail to port 25, tell all users any mail they send during the outage period won't be delivered and to GTF off the old mailserver and stay off of it, then try to migrate all mailboxes over during the outage period, then open back up and cross my fingers we can get all of them migrated over during the outage period.

There's a good chance I'm afraid that settings in all Outlook clients will be broken and we will have to go to each Outlook client and create a new Outlook profile and reconnect Outlook to the new mailserver.  I say that because my experience is Outlook stores the real AD name of the mailserver in it's profile.

It just seems to me the only possible way to do this gradually, a batch at a time, is to do as I already said "I can adjust mail routing on a per-user basis on the bastion host to send incoming mail to the server in wonkulating.com or the server in wonkulatinggronkulator.com depending on which server they are on."

Since both servers think they are authoritative for wonkulatinggronkulator.com, it would get the mail flow properly done.  But this does mean the servers have to remain independent - each thinking it's authoritative for wonkulatinggronkulator.com - even though each is in a different AD forest.