Azure Traffic Manager Cloud Services (multiple websites) and App Services in same region

Question

So we have a scenario where we are currently using Cloud Services to serve two websites, along with some worker roles (worker roles out of scope of this question). We have quite a few environments (5 cloud services env) in the same region, as our users are from a single country.

We are moving towards app services, and we would also like to keep the downtime to minimum. The strategy that we have devised is to configure two app services (one for each website) on every environment and use two trafficmanagers (one for each website) to with two endpoints (priority 1: existing cloud services, priority 2: new app service).

The existing DNS/CNAME configuration is something like following

dev-env.example.com points to website 1 dev-envapi.example.com points to website 2

and the now with the new config I have added two traffic managers, with one as follows dev-env.trafficmanager.net endpoint1 points to cloud service dev-env.trafficmanager.net endpoint2 points to app service (website)

but how do I configure the second website with trafficmanager?

Please find below our existing cloud service webrole and websites config

<WebRole name="App.WebRole" vmsize="Medium" enableNativeCodeExecution="true">
<Sites>
  <Site name="Web">
    <Bindings>
      <Binding name="Endpoint1" endpointName="Endpoint1" hostHeader="dev-env.example.com" />
      <Binding name="Endpoint2" endpointName="Endpoint2" hostHeader="dev-env.example.com" />
    </Bindings>
  </Site>
  <Site name="WebApi" physicalDirectory="WebRole.Api\azure.publish">
    <Bindings>
      <Binding name="Endpoint1" endpointName="Endpoint1" hostHeader="dev-envapi.example.com" />
      <Binding name="Endpoint2" endpointName="Endpoint2" hostHeader="dev-envapi.example.com" />
    </Bindings>
  </Site>
</Sites>
<Endpoints>
  <InputEndpoint name="Endpoint1" protocol="http" port="80" />
  <InputEndpoint name="Endpoint2" protocol="https" port="443" certificate="https" />
</Endpoints>
<ConfigurationSettings>
  <Setting name="AzureSubscriptionId" />
  <Setting name="AzureWebSchedulerCloudServiceName" />
  <Setting name="AzureWebSchedulerJobCollectionMaxQuota" />
  <Setting name="AzureWebSchedulerCertNameConvention" />
  <Setting name="ExternalUrl" />
</ConfigurationSettings>
<LocalResources>
</LocalResources>
<Certificates>
  <Certificate name="Windows Azure Tools" storeLocation="LocalMachine" storeName="My" />
  <Certificate name="https" storeLocation="LocalMachine" storeName="My" />
</Certificates>
<Imports>
</Imports>
<Startup>
  <Task commandLine="Role_Start\Bootstrap.bat" executionContext="elevated" taskType="simple">
    <Environment>
      <Variable name="EMULATED">
        <RoleInstanceValue xpath="/RoleEnvironment/Deployment/@emulated" />
      </Variable>
    </Environment>
  </Task>
</Startup>

Answer 1

So it happens that it works out of the box, we just needed to add have one traffic manager profile per website in the webrole. Target the traffic manager profile with the same url endpoint that is defined in the website in the webrole and we are good to go.

A traffic manager profile with two azure endpoints (one cloud service and one app service) let's say dev-env, dev-env.example.com targeting dev-env.trafficmanager.net. The traffic manager profile had endpoint 1 with priority 1 targeting the dev-env.cloudapp.net (Cloud Service Azure Endpoint), and endpoint 2 with priority 2 targeting the dev-env.azurewebsites.net.

Another traffic manager profile with two azure endpoints (one cloud service and one app service) let's say dev-envapi, dev-envapi.example.com targeting dev-envapi.trafficmanager.net. The traffic manager profile had endpoint 1 with priority 1 targeting the dev-env.cloudapp.net (Cloud Service Azure Endpoint), and endpoint 2 with priority 2 targeting the dev-envapi.azurewebsites.net.

Please note that the endpoint for the cloud service is the same for both traffic manager profiles.

So when we wanted to actually switch, we just turned off the cloud services. Thus reducing the downtime. Also we didn't changes our databases, storage account or any other resources, that's how we were able to keep our downtime to minimum.