Edgio told customers its platform would run until November 2025. It went dark on 15 January 2025, taking with it 300 points of presence, more than 7,000 ISP interconnections, and over 275 Tbps of capacity serving roughly 935 customers (DataCenterDynamics, 2024; elevenflo, 2026). Amazon Prime Video, Sony, Samsung and Microsoft's Azure CDN were all on it. This is the third CDN exit in three years, and the pattern is stable enough to plan against. This is the CDN migration sequence we run when the wind-down date is not negotiable.
Sources: DataCenterDynamics (2024), Telecoms.com (2023), elevenflo (2026), Streaming Media Blog (2026).
Read the right-hand column twice. In all three cases Akamai acquired contracts, not assets. No network transferred. That distinction is the single most consequential fact in this article, and it is the one most coverage buries.
If your contract "moves to Akamai," you are not being migrated in any technical sense. You are being sold a new service on a different network with different peering relationships, a different PoP footprint, a different cache architecture, and different configuration semantics. Your commercial relationship has continuity. Your p95 latency, your cache hit ratio, and your config do not. Teams that treat a contract transfer as a paperwork exercise discover this in production.
The market context matters for how you plan: the vendor pool shrank from 2023 to 2026 while total CDN delivery revenue was flat to down by low single digits (Streaming Media Blog, 2026). Akamai reported $1.25 billion in delivery revenue for 2025, down 5% year over year — and that figure included the acquired Edgio, StackPath and Lumen contracts, without which delivery revenue would have fallen close to 9% (Streaming Media Blog, 2026). Delivery is a shrinking-margin business with a consolidating supplier base. Plan for more of these events, not fewer.
The wind-down date is not a promise
Edgio's commitment ran to November 2025. The actual shutdown was 15 January 2025 — and even that date came with a caveat. Microsoft told Azure customers it could not guarantee Edgio would not cease operations earlier due to circumstances beyond its control, froze configuration changes on Edgio profiles from 3 January, and force-migrated workloads from 7 January for anyone who had not acted (Microsoft Learn).
The mechanic behind this is worth understanding, because it repeats. During a Chapter 11 wind-down, the network stays up only as long as someone funds it. Akamai agreed to pay certain costs for Edgio to operate its network through the transition (DataCenterDynamics, 2024). That funding is a commercial arrangement between two parties, neither of which is you.
Treat any announced wind-down date as the latest possible date, not the expected one, and assume the configuration freeze lands two weeks before it. The freeze is the deadline that actually binds you, because after it you cannot change origins, purge, or add hostnames on the dying platform.
What actually breaks, in order of how badly
The CNAME swap is the easy part. Here is what determines whether the cutover takes three weeks or three months.
The three at the top are where forced migrations go over schedule. If you serve paywalled video or protected downloads, your signed-URL scheme is the critical path, not your DNS. In the migrations INXY runs, that single dependency sets the timeline more often than any other factor, and it is almost never the one teams plan around first.
The WAF row deserves separate planning. Managed rulesets differ enough between providers that a ruleset which was quiet for two years will generate false positives on day one somewhere else. Budget a tuning cycle, or decouple the decision entirely by running [WAF and DDoS protection → /security-and-protection] independently of the delivery layer, so a future CDN change does not force a security re-tune at the same time.
The 30-day cutover sequence
- Days 1–3: Inventory every hostname and every consumer of it. Not just what is in your CDN dashboard — grep the codebase, the mobile app source, installer scripts, CI configuration, partner integrations and documentation for the CDN hostname. This is the step teams skip and regret. When Edgio went down, dotnetcli.azureedge.net and dotnetbuilds.azureedge.net were baked into .NET install scripts, Docker configurations and CI/CD pipelines across the ecosystem, forcing Microsoft to stand up replacement domains and ask every downstream consumer to update references (The Hacker News, 2025). Anything compiled into a shipped mobile binary cannot be cut over on your schedule at all — it moves at app-store release cadence.
- Days 1–3, in parallel: Export the full current configuration and the last 30 days of logs. Configuration and log access die with the platform, sometimes before the traffic does. You need the logs to validate cache hit ratio parity afterwards, and you cannot get them retroactively.
- Days 3–7: Shortlist on the constraints that are hard to change, not on price. Signed-URL compatibility, edge-compute requirements, PoP coverage in your top five eyeball networks, and log format. Price is negotiable in an emergency. Token-scheme compatibility is not.
- Days 5–10: Provision certificates for every hostname on the new provider. Start early. Let's Encrypt enforces issuance rate limits per registered domain, and an emergency migration of dozens of subdomains is exactly the shape of request that hits them. If you control your own certificates, import rather than reissue.
- Days 7–14: Build config parity and run the new provider in log-only mode. Deploy WAF rules in detection mode, replicate cache rules, and put a test hostname live on the new CDN pointing at the same origin. Compare cache hit ratio by content type against the exported baseline. A hit-ratio gap here is a configuration bug, and it is far cheaper to find now than during cutover.
- Days 14–18: Implement dual-token validation. Your origin should accept both the old and new signed-URL schemes for the duration of the migration. Without this, every cached player session and every in-flight download breaks at the moment of cutover.
- Days 18–21: Lower DNS TTLs to 60 seconds and let the old TTL expire fully. If your records have been sitting at 86,400, you need a full day at the old value before the new low TTL is universally observed. Do this before you need it.
- Days 21–24: Pre-warm the new edge. A cold cache means every request is an origin miss. Cutting a high-traffic property over to an empty cache produces a thundering herd against origin at exactly the moment you have the least tolerance for it. Warm the top-N objects by request volume, and confirm origin shield is enabled and configured before you send real traffic. If your [origin servers → /hosting-solutions] were sized against a warm-cache baseline, this is the step that exposes it.
- Days 24–27: Cut over by weight, not by switch. Move 5% of traffic, hold, watch origin load, error rate and p95 latency by region. Then 25%, then 50%, then 100%. Weighted DNS gives you a rollback that takes one TTL rather than one incident review.
- Days 27–30: Validate, then decommission. Reconcile the first full billing period against modeled volume, confirm log pipelines and SIEM ingestion, retire dual-token validation only after the longest signed-URL expiry window has passed, and raise DNS TTLs back to normal.
Thirty days assumes you have the engineering capacity to run this alongside your roadmap. Most teams holding a wind-down notice do not. If that is your situation, [managed migration and DevOps support → /devops-and-management-solutions] is the difference between hitting the freeze date and negotiating with a bankruptcy trustee.
What no vendor will tell you
Consolidating onto the survivor re-concentrates the risk you just got burned by. The default response to a CDN failure is to accept the acquirer's contract, because it is the path of least resistance during an emergency. But the reason you are in an emergency is single-provider concentration, and the acquirer is by definition a provider in a consolidating market with shrinking delivery margins. You have solved the immediate incident and preserved the structural exposure.
Switching CDN can silently change your origin egress bill. Google Cloud's CDN Interconnect discount applies automatically to traffic destined for allowlisted CDN IP ranges — no configuration required. Move your delivery to a provider outside that allowlist and your origin-to-edge traffic reprices to standard internet egress. Google also roughly doubled CDN Interconnect and peering list prices on 1 May 2026, from $0.04 to $0.08 per GiB in North America (Google Cloud, 2026; SpendArk, 2026). If your origin is in GCS, model the origin-side cost of each CDN candidate before shortlisting. Most CDN comparisons never mention it because the charge appears on a different provider's invoice. We cover the mechanics in [our breakdown of cloud egress pricing → /blog/cloud-egress-fees-comparison].
"Multi-CDN" bought as insurance and never exercised is not insurance. A second provider with a stale configuration, expired certificates and an untested failover path will not save you at 3am. If you run multi-CDN, run real traffic through both continuously, even at a 90/10 split, and rotate which one carries the majority once a quarter.
What breaks in production
The cache hit ratio drops and nobody notices for a week. Different providers derive cache keys differently. The config looks equivalent; the hit ratio is not. Origin load and origin egress both rise, and if you are not monitoring hit ratio by content type you will see it first on the bill.
Purge stops working mid-deploy. Release pipelines that call the old provider's purge API keep returning success against a dead endpoint, or fail the build. Audit every automation that touches the CDN, not just the CDN itself.
Geo-routing behaves differently. Anycast footprints differ. A user population that was served from Frankfurt may land in Amsterdam. Usually fine; occasionally it breaks a geo-fencing or licensing rule that was implicitly relying on the old topology.
The old provider's logs disappear before your finance team reconciles the final invoice. Export before, not after.
Rollback is impossible after the freeze. Once the dying platform stops accepting configuration changes, your rollback path is gone. Complete the cutover before the freeze, not before the shutdown.
How to buy so this is never an emergency again
Four contract and architecture decisions, worth more than any provider comparison:
- Abstract the hostname. Serve assets from a hostname you control, on DNS you control, with the CDN behind a CNAME. Never publish a provider-owned hostname into a client, an installer, or a mobile binary.
- Keep the signed-URL scheme in your application layer where you can support two providers simultaneously, rather than delegating it entirely to the edge.
- Negotiate configuration export and log portability into the contract. In writing, with a defined format. It costs nothing at signing and is unobtainable during a bankruptcy.
- Avoid deep edge-compute lock-in for logic that could live at origin. Edge compute is the least portable thing you can adopt, and the switching cost is invisible until the day you need to switch.
The decision framework
When a shutdown notice lands, answer three questions before you shortlist anything:
- What is my configuration freeze date? Work backwards from that, not from the shutdown date. It is typically the real deadline.
- What is my least portable dependency — tokens, edge compute, or WAF? That dependency sets the migration timeline and eliminates most candidate providers. Choose against it, not against price.
- Am I re-concentrating? If the answer to the emergency is one provider again, you have deferred the same incident rather than resolved it.
INXY brokers CDN capacity across multiple vendors on a single contract and a single invoice, which is what makes the fourth option available: adding or removing a provider without a new procurement cycle, and running a warm second CDN without doubling your commercial overhead. It also means we can tell you when the acquirer's offer is genuinely the right landing spot — a conclusion a CDN vendor cannot credibly reach about its own bid.
If you are holding a wind-down notice, the fastest useful step is a compatibility check, not a quote. Send your current configuration export and traffic profile and we will tell you which providers can actually accept your token scheme and match your PoP coverage, before you spend a week shortlisting ones that cannot. [Request an infrastructure audit → /book-a-demo]. If you would rather review the components first: [CDN, streaming and data delivery → /data-delivery], [dedicated servers, colocation and racks → /hosting-solutions], or [WAF, anti-DDoS and edge security → /security-and-protection].
FAQ
What happens when a CDN provider shuts down? Service ends on a published wind-down date, but configuration changes are typically frozen one to two weeks earlier, and the date can move in if funding for the network fails. Customer contracts are often sold to another provider without any network or technology transferring, which means the acquirer is a new deployment rather than a continuation.
How long does a CDN migration take? For a straightforward static-asset workload, two to four weeks including validation. Properties using signed URLs, edge compute, or a tuned WAF ruleset take considerably longer, because those components are provider-proprietary and require application changes rather than configuration translation. Inventory your least portable dependency first — it sets the timeline.
Did Edgio customers automatically move to Akamai? Akamai acquired Edgio's customer contracts, not its network, technology or personnel. Affected customers had to deploy onto Akamai's infrastructure as a new implementation. Microsoft separately force-migrated Azure CDN from Edgio workloads to Azure Front Door from 7 January 2025 for customers who had not acted, describing the automatic path as best-effort.
Should I switch to multi-CDN after a provider failure? Multi-CDN removes single-provider concentration, but only if both providers carry real traffic continuously. A standby CDN with stale configuration and expired certificates fails when you need it. Below a certain traffic volume the operational overhead of maintaining config parity across two providers can exceed the resilience benefit.
Why does my cache hit ratio drop after migrating CDNs? Providers derive cache keys differently — query-string handling, header inclusion, cookie variance and device-class segmentation all vary. A configuration that looks equivalent can fragment the cache and produce more origin misses. Compare hit ratio by content type against your pre-migration baseline, which is why exporting logs before the old platform goes dark matters.
Can changing CDN affect my cloud bill? Yes. Google Cloud's CDN Interconnect discount applies automatically to traffic bound for allowlisted CDN IP ranges. Moving delivery to a provider outside that allowlist reprices origin-to-edge traffic at standard internet egress rates. Google roughly doubled peering list prices in North America on 1 May 2026, making this a larger consideration than it was previously.
Written by Dmitry Schulz, Senior Infrastructure Solutions Architect at INXY Hosting. INXY is a vendor-agnostic infrastructure marketplace and consultancy, brokering dedicated servers, CDN, colocation and cloud capacity across multiple providers on a single contract.
Published 29 August 2026. Provider exit dates and pricing verified at time of publication; CDN market conditions change and this page is reviewed quarterly.
