{"id":1138,"date":"2026-06-12T09:43:27","date_gmt":"2026-06-12T02:43:27","guid":{"rendered":"https:\/\/liveapi.com\/blog\/azure-media-services\/"},"modified":"2026-06-15T11:15:39","modified_gmt":"2026-06-15T04:15:39","slug":"azure-media-services","status":"publish","type":"post","link":"https:\/\/liveapi.com\/blog\/azure-media-services\/","title":{"rendered":"Azure Media Services: What It Did, Why It Retired, and How to Migrate"},"content":{"rendered":"Reading Time: <\/span> 10<\/span> minutes<\/span><\/span>

Microsoft retired Azure Media Services on June 30, 2024 \u2014 a full year after announcing it in June 2023. If you built encoding, live streaming, or video-on-demand workflows on top of it, those workflows have already stopped running, and the accounts behind them are gone.<\/p>\n

Azure Media Services was Microsoft’s cloud platform for encoding, packaging, streaming, and protecting video at scale. For close to a decade it sat behind broadcasters, e-learning platforms, and enterprise video portals. Now it’s a deprecated product, and the people searching for it mostly want one of two things: a clear explanation of what it did, or a working plan to move off it.<\/p>\n

This guide covers both. You’ll get a plain-English breakdown of what Azure Media Services was, the exact retirement timeline and what it means for any leftover assets, the components you need to replace, a step-by-step migration path, and the alternatives \u2014 including Microsoft’s official partners and API-first options \u2014 worth evaluating in 2026.<\/p>\n

What Is Azure Media Services?<\/h2>\n

Azure Media Services was a cloud-based media platform that handled video encoding, adaptive streaming, content protection, and live event delivery through a set of REST APIs and SDKs. Developers used it to ingest source video, transcode it into multiple renditions, package it for HLS and DASH playback, apply DRM, and deliver it through Azure’s network \u2014 without running their own encoding farm.<\/p>\n

At its core, the platform combined a few capabilities that otherwise required separate tools: a transcoding engine, a dynamic packager that produced HLS streaming<\/a> and DASH on the fly, a content protection layer with multiple DRM systems, and live channels for real-time broadcasts. You created an “asset,” ran a job against it, and pointed a streaming endpoint at the result.<\/p>\n

It existed because video infrastructure is hard to build and expensive to operate. Encoding is CPU-intensive, adaptive bitrate packaging is fiddly, and DRM integration with Apple, Google, and Microsoft licensing servers is genuinely painful. Azure Media Services bundled all of that into a managed service so teams on Azure could ship video features without becoming streaming engineers.<\/p>\n

That value proposition still matters \u2014 which is exactly why the retirement left so many teams scrambling for a replacement.<\/p>\n

Azure Media Services Retirement: What Happened and When<\/h2>\n

Microsoft announced the retirement in June 2023 and shut the service down on June 30, 2024. Both the v2 and v3 APIs were retired at the same time, so there was no “stay on the older version” escape hatch. Creation of new Media Services accounts was blocked across all Azure regions ahead of the date.<\/p>\n

Here’s the timeline that mattered:<\/p>\n\n\n\n\n\n\n\n\n\n
Date<\/th>\nWhat happened<\/th>\n<\/tr>\n<\/thead>\n
June 2023<\/td>\nMicrosoft announced the retirement and stopped new account creation<\/td>\n<\/tr>\n
June 30, 2024<\/td>\nStreaming stopped; v2 and v3 APIs retired; Azure Media Player retired<\/td>\n<\/tr>\n
~Early August 2024<\/td>\nEnd of the one-time 30-day account extension window<\/td>\n<\/tr>\n
~90 days after deactivation<\/td>\nAccounts and metadata permanently deleted<\/td>\n<\/tr>\n
June 30, 2025<\/td>\nEnd of Bitmovin’s URL-preservation window for migrated, non-DRM streams<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

When an account expired, all running live events and streaming endpoints stopped within about an hour. The API then went read-only \u2014 it accepted GET requests but rejected PUT, POST, and PATCH operations, with one exception: you could still update CDN settings on streaming endpoints. Roughly 90 days later, the account and all of its metadata were deleted for good.<\/p>\n

One detail saved a lot of teams from total data loss: your actual video files were never inside Media Services. Source videos and packaged files (the .ism<\/code>, .ismc<\/code>, and .mp4<\/code> files) live in your own Azure Storage account, and they survived the retirement untouched. What got deleted was the account data<\/em> \u2014 streaming endpoints, live event configs, and asset metadata. If you exported that metadata in time, migration tools could rebuild your catalog; if you didn’t, you kept the raw files but lost the mapping.<\/p>\n

Microsoft’s stated reason was a focus on “strategic areas of secular growth and long-term competitiveness,” paired with a push to route media workloads through its partner ecosystem instead. You can read the full notice in Microsoft’s retirement guide<\/a>.<\/p>\n

What Azure Media Services Did: Core Components<\/h2>\n

To plan a migration, you need to know which pieces you actually used. Azure Media Services was modular, and most teams only touched a subset. Here are the components, with the replacement category each one maps to.<\/p>\n

Encoding and Transcoding<\/h3>\n

The encoding engine took a source file and produced multiple renditions for adaptive bitrate streaming<\/a>, so playback could adjust to each viewer’s connection. It used presets for resolution ladders and codecs, and it ran as asynchronous jobs against your assets. Any replacement needs a cloud video encoding<\/a> pipeline that outputs HLS or DASH.<\/p>\n

Live Streaming (Live Events)<\/h3>\n

Live events \u2014 earlier called channels \u2014 ingested an RTMP or fragmented-MP4 feed from an encoder, transcoded or passed it through, and served it to viewers in near real time. Teams used this for town halls, webinars, sports, and large broadcasts. Replacements need RTMP ingest<\/a> and low-latency delivery.<\/p>\n

On-Demand Streaming (Streaming Endpoints)<\/h3>\n

Streaming endpoints were the delivery layer. They applied dynamic packaging \u2014 converting your stored renditions into HLS or DASH at request time \u2014 and connected to a CDN for scale. This is the part most teams forget to account for: it’s not just storage, it’s the packaging-and-delivery surface.<\/p>\n

Content Protection and DRM<\/h3>\n

Azure Media Services delivered content encrypted with AES-128 or one of three DRM systems: Microsoft PlayReady, Google Widevine, and Apple FairPlay. It also issued the keys and licenses to authorized players. If you streamed paid or premium content, this is the hardest component to replace cleanly \u2014 see our primer on DRM for video<\/a>.<\/p>\n

Azure Media Player<\/h3>\n

Azure Media Player was the companion HTML5 player that handled the platform’s HLS, DASH, and DRM formats across browsers. It retired on the same date. Any migration needs a new video player<\/a> that supports your chosen streaming format and DRM.<\/p>\n

Video and Audio Analysis<\/h3>\n

Media Services offered analyzer presets that extracted insights \u2014 speech-to-text, faces, and metadata. This capability did not<\/em> die with the platform. Microsoft moved it to Azure Video Indexer, which now runs independently of Media Services and offers stronger transcription, translation, and speaker identification.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Component<\/th>\nWhat it did<\/th>\nReplacement category<\/th>\n<\/tr>\n<\/thead>\n
Encoding\/transcoding<\/td>\nProduced ABR renditions<\/td>\nVideo encoding API<\/td>\n<\/tr>\n
Live events<\/td>\nIngested and served live feeds<\/td>\nLive streaming API<\/td>\n<\/tr>\n
Streaming endpoints<\/td>\nPackaged + delivered VOD<\/td>\nStreaming + CDN<\/td>\n<\/tr>\n
Content protection<\/td>\nAES + PlayReady\/Widevine\/FairPlay<\/td>\nDRM \/ multi-DRM service<\/td>\n<\/tr>\n
Azure Media Player<\/td>\nHTML5 playback<\/td>\nVideo player \/ player SDK<\/td>\n<\/tr>\n
Analyzer presets<\/td>\nAI metadata extraction<\/td>\nAzure Video Indexer<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

How Azure Media Services Pricing Worked<\/h2>\n

Pricing is moot now that the service is gone, but it’s worth understanding because it shapes what a fair replacement should cost. Azure Media Services billed across several axes: encoding was charged per output minute, live events and streaming endpoints carried hourly running costs whether or not they served traffic, and you paid separately for storage and data egress.<\/p>\n

That model caught a lot of teams off guard. A streaming endpoint left running overnight billed all night. Live channels were especially expensive to keep “warm.” When you evaluate alternatives, watch for this same trap \u2014 some replacements charge for idle infrastructure, while usage-based APIs only bill for what you actually process and deliver.<\/p>\n

What the Retirement Means for Your Workloads<\/h2>\n

If you’re reading this after the fact, the practical impact is already clear, but it’s worth being precise about what broke and what didn’t \u2014 especially if you inherited an old project.<\/p>\n

Your streaming URLs stopped resolving.<\/strong> Once endpoints shut down, every embedded player and app pointing at an *.streaming.media.azure.net<\/code> URL returned errors. Unless you migrated to a partner that preserved URLs, those links are dead.<\/p>\n

Your player needs replacing.<\/strong> Azure Media Player retired too, so even apps that solved delivery elsewhere need a new playback layer that matches their new streaming format and DRM.<\/p>\n

DRM-protected content is the hardest hit.<\/strong> AES and DRM weren’t carried over by the simplest migration paths, so any premium content needs its key delivery and licensing rebuilt on the new platform.<\/p>\n

Your raw files are safe, but the catalog isn’t.<\/strong> The source media in your Storage account is fine. The metadata that mapped those files to renditions, captions, and protection policies was deleted ~90 days after deactivation. If that window passed without an export, rebuilding the catalog is manual.<\/p>\n

Now that you know exactly what needs rebuilding, the rest of this guide is about doing it \u2014 choosing a replacement, moving your assets, and getting playback working again.<\/p>\n

How to Migrate Off Azure Media Services (Step by Step)<\/h2>\n

Whether you’re mid-migration or restarting a stalled one, the path is the same. Work through these steps in order.<\/p>\n

1. Inventory What You Actually Used<\/h3>\n

List the components from the section above that your project touched: encoding only, live plus VOD, DRM, analysis. Most teams over-scope migration by assuming they need a full Azure Media Services clone when they really used two features. Scope to what’s in production.<\/p>\n

2. Export Your Assets and Metadata<\/h3>\n

Confirm your source files are still in Azure Storage \u2014 they almost certainly are. If your account was deleted, you’ve lost the metadata, so document what you can reconstruct: file locations, rendition naming, and any protection policies. Microsoft’s open-source migration tool<\/a> can transform stored assets to stream directly from storage over HLS\/DASH.<\/p>\n

3. Choose a Replacement Category<\/h3>\n

Decide between three broad paths: a Microsoft-recommended partner (Bitmovin, MediaKind, Ravnur), another cloud provider’s media stack like AWS Media Services<\/a>, or an API-first video streaming platform<\/a> that bundles encoding, delivery, and playback behind one API. Your choice depends on how much you want to operate yourself.<\/p>\n

4. Re-Implement Encoding and Delivery<\/h3>\n

Set up your new encoding pipeline to produce the same rendition ladder, then wire it to a CDN for delivery. This is where an API-first option saves the most time. Instead of provisioning encoders and configuring packaging, you POST a source URL and get back a playable HLS<\/a> stream.<\/p>\n

This is a natural fit for LiveAPI<\/a>. It handles instant encoding \u2014 videos are playable seconds after upload regardless of length \u2014 with built-in adaptive bitrate, HLS output, and delivery across Akamai, Cloudflare, and Fastly. For live workloads, it ingests RTMP and SRT and records to VOD automatically, which covers both the live-event and streaming-endpoint roles Azure Media Services used to fill. You replace several Azure components with one video API<\/a> and a few lines of code.<\/p>\n

5. Rebuild Content Protection<\/h3>\n

If you used DRM, configure your new platform’s protection and license delivery for PlayReady, Widevine, and FairPlay, then test playback on each target device. Premium content should not go live until DRM is verified end to end.<\/p>\n

6. Replace the Player and Update URLs<\/h3>\n

Swap Azure Media Player for a player that supports your new format and DRM, then update every embed, app, and link to the new streaming URLs. Partners like Bitmovin could preserve non-DRM URLs through June 30, 2025; most other paths required URL changes.<\/p>\n

7. Migrate Video Analysis Separately<\/h3>\n

If you used analyzer presets, move that workload to Azure Video Indexer, which now runs on its own. Its transcription, translation, and speaker-identification models are stronger than the old presets, so this step is often an upgrade rather than a lateral move.<\/p>\n

Azure Media Services Alternatives in 2026<\/h2>\n

There’s no single drop-in replacement, so the right alternative depends on your priorities \u2014 minimal operations, deepest control, or fastest time to ship. Here’s the landscape.<\/p>\n

Microsoft’s Recommended Partners<\/h3>\n

Microsoft pointed customers to three partners, all available through the Azure Marketplace with their own migration guides:<\/p>\n