Azure CDN Transition: What Existing Deployments Must Do

Microsoft has put its legacy Azure CDN products on retirement paths and designated Azure Front Door as the strategic replacement. Azure CDN Standard from Microsoft (classic) remains available to existing customers until September 30, 2027, but new profile creation ends on October 1, 2026.

This matters because the deadline applies to a production service, not an optional portal interface. A profile can sit between users and an origin, handling caching, compression, custom domain HTTPS, geo-filtering, and rules that affect every request. Replacing it changes infrastructure at the point where traffic enters the application.

One transition has already happened under worse conditions. Azure CDN Standard and Premium from Edgio were retired on January 15, 2025 after Edgio filed for bankruptcy, and Microsoft told customers to migrate workloads to another content delivery service. That episode showed why waiting for the final quarter is a bad operating plan: certificate validation, DNS access, cache behavior, and security policy all have ways of becoming separate projects.

The confirmed direction is consolidation around Front Door. What should not be inferred is that every classic profile will automatically become a working Front Door deployment. Microsoft supplies migration tooling for eligible configurations, but customers still own testing, DNS changes, monitoring, and cleanup.

Any deployment using Azure CDN Standard from Microsoft (classic) needs a migration plan before September 30, 2027. Retired Edgio profiles are a more immediate exception: they should no longer be treated as functioning infrastructure.

Check the profile SKU rather than relying on an old architecture diagram or subscription name. In the Azure portal, open the CDN profile and inspect Overview or Properties; in an exported ARM template, look for the profile resource and its sku.name value. Inventory endpoints, origins, custom domains, certificates, rules, diagnostic settings, and dependencies that create DNS records outside Azure.

• Record every profile, endpoint, subscription, and resource group.
• Map each endpoint hostname to its origin or origin group.
• Capture custom domain and TLS certificate ownership.
• Export caching rules, redirects, rewrites, compression settings, and geo-filtering policy.
• Find CNAME records and note their DNS time to live.
• List monitoring alerts, log destinations, budgets, and deployment pipelines.

Do not assume an endpoint with little traffic is unused. Mobile applications, firmware, archived web pages, partner integrations, and emergency failover systems can retain hard-coded hostnames for years. Query logs and application configuration before deleting anything.

Classic CDN is mainly an edge caching and content delivery product, while Front Door combines global HTTP routing, acceleration, caching, health-aware origins, and security policy. That broader control plane is useful, but it means migration is not a one-for-one endpoint rename.

Microsoft describes Front Door as a globally distributed application delivery network for static and dynamic web content, with anycast entry points and integrated Web Application Firewall capabilities in its Front Door service overview↗. Azure Front Door is a modern cloud content delivery network (CDN) service, but the practical difference is where operational decisions live.

Front Door Standard suits public origins that need content delivery, routing, and common security controls. Premium is the serious candidate when a web application needs Private Link connectivity or the fuller security feature set. Do not buy Premium solely because its name sounds safer; match the tier to required capabilities.

Microsoft’s tooling can validate and migrate eligible classic profiles, carrying supported endpoint configuration into a Front Door profile. It does not remove the need to inspect unsupported settings, test behavior, or perform a controlled DNS cutover.

The documented process begins with compatibility validation, followed by preparation and migration. Microsoft’s classic CDN migration procedure↗ explains that validation identifies configurations which must be changed before the profile can move.

1. Freeze casual configuration changes and export the current profile.
2. Run the migration compatibility check.
3. Resolve blocking rules, domains, certificates, or origin settings.
4. Choose the Front Door Standard or Premium tier from actual requirements.
5. Create or migrate the profile without moving public traffic yet.
6. Compare headers, status codes, redirects, cache hits, and origin load.
7. Lower DNS TTL before the planned cutover.
8. Change the custom domain CNAME and monitor both services.
9. Keep rollback possible until caches, logs, and error rates settle.

The awkward cases are usually rules engine expressions and domain validation, not file transfer. A redirect that changes path escaping, a query-string cache rule that broadens the cache key, or an origin host header that no longer matches the certificate can produce a deployment that looks healthy while serving wrong content or returning intermittent 502 errors.

Routes, origin host headers, cache keys, certificates, and security rules are the configuration differences most likely to break a migrated deployment. Reproduce only the behavior the application still needs, and preserve the public custom domain where possible to avoid combining a platform move with client, certificate, SEO, and cache invalidation work.

Start with routes. For each domain and path pattern, specify the accepted protocols, forwarding protocol, origin group, cache policy, and rule set. Then verify the origin host header against the certificate presented by the origin; a mismatch is a common cause of failed TLS connections behind an otherwise valid edge certificate.

Cache tests need real objects and real headers. Check Cache-Control, Vary, query strings, cookies, range requests, compression, and purge behavior. Dynamic content should not become cacheable merely because a route was copied from a static asset endpoint. Conversely, sending every request to the origin discards the performance and data transfer benefit that paid for the delivery network in the first place.

Security belongs in the same change review. If Web Application Firewall policy, bot rules, rate limits, or DDoS protection are being added during migration, stage them in detection or logging mode first where available. A CDN replacement and a new blocking policy are two changes. Combining them makes a 403 surge needlessly hard to diagnose.

Lower the custom domain’s DNS TTL ahead of the move, validate TLS on Front Door, and only then change the CNAME. Keep the old endpoint intact during the observation window so rollback is a DNS edit rather than an emergency rebuild.

Certificate readiness is the gate. A Microsoft-managed certificate can require domain validation, while a customer-managed certificate introduces Key Vault permissions, renewal ownership, and version handling. Confirm the certificate covers the exact hostname and that the new route is associated with that domain before sending production traffic.

Test through the assigned Front Door hostname first, but remember that this does not fully reproduce requests to the custom domain. The host header affects routing, redirects, cookies, origin behavior, and certificates. Use a staging hostname or a local host override where operational policy permits, then inspect response headers and application logs.

Long DNS TTLs are only part of the delay. Recursive resolvers and clients can retain answers, while globally distributed edge caches may hold objects under separate cache keys. Monitor traffic on old and new profiles until the old endpoint is quiet, rather than declaring victory when a public DNS checker shows the new CNAME.

Expect a different bill shape rather than a guaranteed increase or decrease. Front Door charges depend on the selected tier, base fees, edge data transfer, requests, origin transfer, and optional security features, while the workload’s regions and cache-hit ratio decide the result.

Build the estimate from billing exports and access logs, not average monthly traffic alone. Record outbound bytes by geography, request counts, peak rates, cache misses, rules, domains, and WAF requirements. Microsoft publishes the current meters on its Azure Front Door pricing page↗, but the calculator still needs honest workload inputs.

A migration can raise origin costs even if the edge rate looks acceptable. Changed cache keys, shorter effective TTLs, disabled caching on a route, or different query-string handling will send more requests to storage, App Service, an API gateway, or another cloud. That origin load also affects reliability and connection limits.

Set a temporary budget and alerts for the new subscription or resource group. Compare edge request volume, data transfer, origin egress, WAF processing, and cache-hit ratio daily during cutover. Do not approve the final shutdown until one full billing cycle has exposed low-frequency traffic and the finance team can map the new meters.

Finish discovery and compatibility work at least two quarters before the retirement date, then move production domains in batches. The final month should be reserved for stragglers and rollback, not first contact with Front Door.

A sensible schedule separates configuration migration from traffic migration:

• First, inventory profiles, owners, domains, origins, rules, certificates, and monthly cost.
• Next, classify endpoints by revenue impact, traffic, compliance, and technical complexity.
• Build a representative Front Door profile and settle the infrastructure-as-code pattern.
• Move a low-risk domain, observe it through normal peaks, and document the failure modes.
• Migrate related applications in batches with explicit rollback criteria.
• Remove old profiles only after logs show no meaningful traffic and dependent teams sign off.

Put dates and named owners against DNS, certificates, WAF policy, application testing, cost review, and incident response. The platform team cannot validate checkout redirects for commerce, and an application owner often cannot change enterprise DNS. That ownership gap is where routine migrations stall.

For background on why edge caching changes origin load and latency, see how a content delivery network works. Teams comparing replacement services should also use a requirements-based CDN provider selection framework, rather than treating Microsoft’s default destination as proof that every workload belongs there.