Exchange 2007 on-premise to Exchange 2013 running on IaaS migration

Occasional Contributor

Hello Team,

I am looking to migrate Exchange 2007 running on Onpremise to migrate on Exchange 2013 running on Iaas Virtual machines. I will have Site to Site VPN and requirement infrastructure deployed. I have below 2 queries-

  • Once coexistance configured and Exchange 2013 Infrastructure running on IaaS promoted as Internet facing CAS, will redirection to legacy on-premise Exchange 2007 infrastrucutre will work smooth or any issues are expected?
  • If I deploy 2 Servers (CAS/MBX) having both the roles, can I use DAG for mailbox server high availability and Azure LB for CAS Load balancing.

I know Exchange running on Azure IaaS is less recommened due to cost and other factors and O365 is recommended solution but this is one of clients requirement hence please suggest. Thank you.

1 Reply


First of all please take a look at this


It says the following:


Deployment of Exchange 2013 on Infrastructure-as-a-Service (IaaS) providers is supported if all supportability requirements are met. In the case of providers who are provisioning virtual machines, these requirements include ensuring that the hypervisor being used for Exchange virtual machines is fully supported, and that the infrastructure to be utilized by Exchange meets the performance requirements that were determined during the sizing process. Deployment on Microsoft Azure virtual machines is supported if all storage volumes used for Exchange databases and database transaction logs (including transport databases) are configured for Azure Premium Storage.


So keep in mind to configure all storage services as recommended in order to get support in any case.


From my point of view the redirection will work smooth as long as the VPN connection and your local network routing is working properly (keep in mind that it's just another network site in Azure).

As far as the LB is concerned, I think you could use the Azure LB for your CAS. But as states a third party LB service like KEMP or others might work out better for your Exchange Org. If you want to be sure set up a test environment and simply test it with a couple of test users in Azure...