Migrate an active DNS name to Azure App Service
This article shows you how to migrate an active DNS name to Azure App Service without any downtime.
When you migrate a live site and its DNS domain name to App Service, that DNS name is already serving live traffic. You can avoid downtime in DNS resolution during the migration by binding the active DNS name to your App Service app preemptively.
If you're not worried about downtime in DNS resolution, see Map an existing custom DNS name to Azure App Service.
To complete the steps, make sure that your App Service app isn't in FREE tier.
1. Get a domain verification ID
When you bind a custom domain preemptively, you accomplish both of the following before making any changes to your existing DNS records:
- Verify domain ownership by adding a domain verification ID with your domain provider.
- Enable the domain name in your App service app.
When you finally migrate your custom DNS name from the old site to the App Service app, there will be no downtime in DNS resolution.
In the Azure portal, open the management page of the App Service app.
In the left pane of your app page, select Custom domains.
Copy the ID in the Custom Domain Verification ID box in the Custom Domains page for the next steps.
2. Create the DNS records
Sign in to the website of your domain provider.
You can use Azure DNS to manage DNS records for your domain and configure a custom DNS name for Azure App Service. For more information, see Tutorial: Host your domain in Azure DNS.
Find the page for managing DNS records.
Every domain provider has its own DNS records interface, so consult the provider's documentation. Look for areas of the site labeled Domain Name, DNS, or Name Server Management.
Often, you can find the DNS records page by viewing your account information and then looking for a link such as My domains. Go to that page, and then look for a link that's named something like Zone file, DNS Records, or Advanced configuration.
The following screenshot is an example of a DNS records page:
Select Add or the appropriate widget to create a record.
For certain providers, such as GoDaddy, changes to DNS records don't become effective until you select a separate Save Changes link.
Add a TXT record for domain verification. The hostname for the TXT record depends on the type of DNS record type you want to map. See the following table (
@ typically represents the root domain):
|DNS record example||TXT Host||TXT Value|
|@ (root)||asuid||Domain verification ID shown in the Custom domains management page.|
|www (sub)||asuid.www||Domain verification ID shown in the Custom domains management page.|
|* (wildcard)||asuid||Domain verification ID shown in the Custom domains management page.|
* records won't validate subdomains with an existing CNAME's record. You may need to explicitly create a TXT record for each subdomain.
3. Enable the domain for your app
Back in the Custom domains page, select Add custom domain.
For Domain provider, select All other domain services to configure a third-party domain.
For TLS/SSL certificate, select Add certificate later. You can add an App Service managed certificate after you have completed domain migration.
For TLS/SSL type, select the binding type you want.
Setting Description Custom domain The domain name to add the TLS/SSL binding for. Private Certificate Thumbprint The certificate to bind. TLS/SSL Type - SNI SSL: Multiple SNI SSL bindings may be added. This option allows multiple TLS/SSL certificates to secure multiple domains on the same IP address. Most modern browsers (including Internet Explorer, Chrome, Firefox, and Opera) support SNI (for more information, see Server Name Indication).
- IP SSL: Only one IP SSL binding may be added. This option allows only one TLS/SSL certificate to secure a dedicated public IP address. After you configure the binding, follow the steps in 2. Remap records for IP based SSL.
IP SSL is supported only in Standard tier or above.
Type the fully qualified domain name you want to migrate, that corresponds to the TXT record you created, such as
Select Validate. Although the dialog shows two records you need for the custom domain to be functional for your app, the validation passes with just the domain verification ID (the TXT record).
If the Domain validation section shows green check marks, then you've configured the domain verification ID correctly. Select Add. If it shows any red X, fix any errors in your domain provider's website.
You should see the custom domain added to the list. You may also see a red X with No binding.
Unless you configure a certificate binding for your custom domain, Any HTTPS request from a browser to the domain will receive an error or warning, depending on the browser.
4. Remap the active DNS name
The only thing left to do is remapping your active DNS record to point to App Service. Right now, it still points to your old site.
(A record only) You need the App Service app's external IP address. In the Custom domains page, copy the app's IP address.
Back in the DNS records page of your domain provider, select the DNS record to remap.
Remap the A or CNAME record like the examples in the following table:
FQDN example Record type Host Value contoso.com (root) A
IP address from Copy the app's IP address www.contoso.com (sub) CNAME
<app-name>.azurewebsites.net *.contoso.com (wildcard) CNAME * <app-name>.azurewebsites.net
Save your settings.
DNS queries should start resolving to your App Service app immediately after DNS propagation happens.
Frequently asked questions
- Can I add an App Service managed certificate when migrating a live domain?
- How do I migrate a domain from another app?
Can I add an App Service managed certificate when migrating a live domain?
You can add an App Service managed certificate to a migrated live domain, but only after you remap the active DNS name. To add the App Service managed certificate, see Create a free managed certificate.
How do I migrate a domain from another app?
You can migrate an active custom domain in Azure, between subscriptions or within the same subscription. However, such a migration without downtime requires the source app and the target app are assigned the same custom domain at a certain time. Therefore, you need to make sure that the two apps aren't deployed to the same deployment unit (internally known as a webspace). A domain name can be assigned to only one app in each deployment unit.
You can find the deployment unit for your app by looking at the domain name of the FTP/S URL
<deployment-unit>.ftp.azurewebsites.windows.net. Check and make sure the deployment unit is different between the source app and the target app. The deployment unit of an app is determined by the App Service plan it's in. It's selected randomly by Azure when you create the plan and can't be changed. When you create two apps in the same resource group and the same region, Azure puts them in the same deployment unit. However, there's no way to make sure that the opposite is true. In other words, the only way to create a plan in a different deployment unit is to keep creating a plan in a new resource group or region until you get a different deployment unit.
Learn how to bind a custom TLS/SSL certificate to App Service.