Hello Max Tevs,
Yes, failing back from Azure to new vCenters is possible by considering it as a failback to an alternate location. However, it is crucial to ensure that the new environment is properly configured to replicate the original setup as closely as possible. This includes setting up a new vCenter and a new configuration server or appliance that can communicate with Azure Site Recovery.
If the on-premises virtual machine or vCenter doesn't exist before reprotecting the virtual machine, the scenario is called an alternate location recovery.
The reprotected workflow creates and recovers the virtual machine to the same ESX host on which the master target server is deployed. This includes any datastore managed by vCenter on which the appliance is situated and is accessible (with read and write permissions) by the appliance, can be chosen (original/new).
Note: you can fail back only to a virtual machine file system (VMFS) or vSAN datastore. If you have a (RDM), reprotect and failback won't work.
The following article states that the original vCenter and Configuration server need exist for any replications and failbacks from Azure to VMware
The original vCenter and Configuration server are needed if you intend to failback to the original location. because you can't deploy a new configuration server to an existing vCenter, nor you add a new vCenter to the existing configuration server and failback into the new vCenter. hence in original location recovery we need the same vCenter and Configuration server. However, in alternative location recovery we need a new vCenter and configuration server or appliance.
Below link is to Set up a process server in Azure for failback:-
I hope this clears your doubts. If you have any further questions, feel free to ask.
If you found this informative, please consider accepting an answer as a token of appreciation. And don't forget to give it a thumbs up 👍 if it was helpful.