It's always the Load Balancer

Ok, this is probably an (intentionally) inflammatory title, but in this case, it's absolutely true.

A common Exchange Online migration issue we see is the SourceMailboxAlreadyBeingMovedTransientException which I previously blogged about.  One of the most common reasons we see for this error is a communications error (found using the command in the previous blog) that looks like this:

 CommunicationErrorTransientException: The call to 'https://MRSPROXYHOST/EWS/mrsproxy.svc SERVER.domain.com (14.3.178.0 caps:05FFFF)' failed.
Error details: The remote endpoint no longer recognizes this sequence. This is most likely due to an abort on the remote endpoint. The value of wsrm:Identifier is not a known Sequence identifier. The reliable session was faulted.

The reason you see this is because MRS Proxy uses WCF's implementation of reliable sessions.  In this scenario each request is sequenced (numbered) and the current (expected) sequence number is held in memory in MRS Proxy (In 2010 on the Client Access Server).  The reason for the error is that the request was sent to a different CAS than was previously being used (and thus the new CAS didn't know about the previous sequence).  In Exchange 2010, we require HTTP(s) sessions for MRS Proxy to be sticky to a particular CAS (also referred to as persistence or affinity).  It also needed to be client IP-based persistence because the MRS Proxy client component doesn't actually store and persist cookies, rendering all forms cookie-based affinity useless.  Additionally, since MRS Proxy connections use NTLM authentication, you can't do persistence on the Authorization HTTP header.  If you see this error, it's almost certainly the load balancer not maintaining persistence.  You'll see this primarily when migrating from Exchange 2010 because Exchange 2013 and later doesn't require load balancer persistence.

Hope this helps.