Understanding how the DR tool is communicating with the deployment is important, and we can improve our documentation to highlight that. However, in this case, while there is a chance that requests may make it from the target site to the source site, there's no chance that the restore will be able to run. Once the new environment is set up, a unique key is generated to decrypt and encrypt tokens. Site A will use key 1 and site B will use key 2. A token created in site B will have been encrypted using key 2, and if that token is used in site A, it can't be decrypted using key 1. The first restore will always fail if requests were making their way to site A.
Aside from that, there's no real requirement that the target machines are in their own virtual network; typically that'll happen if you use the DR tool to support geographic redundancy, but in the case of migrating between newer hardware or operating system, that won't be the case or necessary.
