Azure Media Services: What It Did, Why It Retired, and How to Migrate

Microsoft retired Azure Media Services on June 30, 2024 — 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.

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.

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 — including Microsoft’s official partners and API-first options — worth evaluating in 2026.

What Is Azure Media Services?

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 — without running their own encoding farm.

At its core, the platform combined a few capabilities that otherwise required separate tools: a transcoding engine, a dynamic packager that produced HLS streaming 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.

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.

That value proposition still matters — which is exactly why the retirement left so many teams scrambling for a replacement.

Azure Media Services Retirement: What Happened and When

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.

Here’s the timeline that mattered:

When an account expired, all running live events and streaming endpoints stopped within about an hour. The API then went read-only — 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.

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, .ismc, and .mp4 files) live in your own Azure Storage account, and they survived the retirement untouched. What got deleted was the account data — 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.

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.

What Azure Media Services Did: Core Components

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.

Encoding and Transcoding

The encoding engine took a source file and produced multiple renditions for adaptive bitrate streaming, 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 pipeline that outputs HLS or DASH.

Live Streaming (Live Events)

Live events — earlier called channels — 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 and low-latency delivery.

On-Demand Streaming (Streaming Endpoints)

Streaming endpoints were the delivery layer. They applied dynamic packaging — converting your stored renditions into HLS or DASH at request time — 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.

Content Protection and DRM

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 — see our primer on DRM for video.

Azure Media Player

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 that supports your chosen streaming format and DRM.

Video and Audio Analysis

Media Services offered analyzer presets that extracted insights — speech-to-text, faces, and metadata. This capability did not 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.

How Azure Media Services Pricing Worked

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.

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 — some replacements charge for idle infrastructure, while usage-based APIs only bill for what you actually process and deliver.

What the Retirement Means for Your Workloads

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 — especially if you inherited an old project.

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

Your player needs replacing. 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.

DRM-protected content is the hardest hit. 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.

Your raw files are safe, but the catalog isn’t. 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.

Now that you know exactly what needs rebuilding, the rest of this guide is about doing it — choosing a replacement, moving your assets, and getting playback working again.

How to Migrate Off Azure Media Services (Step by Step)

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

1. Inventory What You Actually Used

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.

2. Export Your Assets and Metadata

Confirm your source files are still in Azure Storage — 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 can transform stored assets to stream directly from storage over HLS/DASH.

3. Choose a Replacement Category

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

4. Re-Implement Encoding and Delivery

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 stream.

This is a natural fit for LiveAPI. It handles instant encoding — videos are playable seconds after upload regardless of length — 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 and a few lines of code.

5. Rebuild Content Protection

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.

6. Replace the Player and Update URLs

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.

7. Migrate Video Analysis Separately

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.

Azure Media Services Alternatives in 2026

There’s no single drop-in replacement, so the right alternative depends on your priorities — minimal operations, deepest control, or fastest time to ship. Here’s the landscape.

Microsoft’s Recommended Partners

Microsoft pointed customers to three partners, all available through the Azure Marketplace with their own migration guides:

• Bitmovin — Offered automatic migration and could preserve existing non-DRM URLs until June 30, 2025. Strong encoding and player tooling, available in 20+ regions.
• MediaKind — Continued streaming existing content in HLS/DASH with AES and full DRM, maintaining URL structure while requiring a host-name update. Available in a smaller set of regions.
• Ravnur — Runs inside your own Azure subscription and specializes in government customers, with support across commercial and Azure Government regions.

Microsoft also listed system integrators — Eyevinn, Southworks, and WhDiYo — to help with the migration build itself.

Other Cloud Media Stacks

If you want to stay with a hyperscaler, AWS Elemental and the broader AWS media suite cover encoding, packaging, and live delivery. The tradeoff is the same one Azure Media Services had: you assemble and operate several services yourself, and idle resources can cost money.

API-First Video Platforms

For teams that would rather not run media infrastructure at all, an API-first platform collapses encoding, storage, delivery, and playback into one service. This is the fastest path back to working video, and it’s where LiveAPI fits: you keep your files in storage, point the API at them or upload directly, and get back HLS streams on a global CDN. It also handles multistreaming to 30+ destinations and automatic live-to-VOD — both things Azure Media Services made you wire up by hand.

The build-versus-buy math is the same one Azure Media Services originally solved: assembling a streaming stack from scratch can take a team months, while an encoding and streaming API gets you to working playback in days. For a deeper build walkthrough, see our guide on how to build a video streaming app.

Is an API-First Replacement Right for Your Project?

An API-first platform is the right call for most teams leaving Azure Media Services, but not all. Use this checklist.

A good fit if you:

• Want video working again in days, not months
• Prefer usage-based pricing over paying for idle encoders and endpoints
• Need encoding, live streaming, VOD hosting, and a CDN from one API
• Are building an OTT platform, an internal video portal, or in-app streaming
• Have a small team and don’t want to run media infrastructure

Probably not a fit if you:

• Have deeply custom encoding pipelines that need per-frame control
• Are contractually tied to a specific DRM or compliance configuration only certain partners support
• Need to keep everything inside your own Azure subscription for regulatory reasons (here, Ravnur or a self-hosted option fits better)

If your old Azure Media Services usage was “encode, stream, and protect video without operating servers,” an API-first replacement matches that intent more closely than rebuilding the stack yourself.

Azure Media Services FAQ

Is Azure Media Services still available?

No. Azure Media Services retired on June 30, 2024. Streaming stopped on that date, accounts went read-only, and they were deleted roughly 90 days later. New account creation was blocked across all regions before the retirement.

Why did Microsoft retire Azure Media Services?

Microsoft cited a focus on strategic growth areas and long-term competitiveness, alongside a decision to route media workloads through its partner ecosystem. In practice, the company chose to exit running the media platform directly and hand it to specialized vendors.

What happened to my videos stored in Azure Media Services?

Your source videos and packaged files stayed in your own Azure Storage account and were unaffected by the retirement. Only the account data — streaming endpoints, live events, and asset metadata — was deleted, about 90 days after the account was deactivated.

What is the best Azure Media Services alternative?

It depends on your goal. Microsoft’s recommended partners (Bitmovin, MediaKind, Ravnur) offer the closest 1:1 replacement. For teams that want to ship fast with minimal operations, an API-first platform like LiveAPI bundles encoding, live streaming, VOD, and delivery behind a single API.

Was Azure Media Player retired too?

Yes. Azure Media Player retired on the same date, June 30, 2024. Any app that used it needs a new HTML5 player that supports the chosen streaming format and DRM systems.

Do I still need to migrate from the v2 to the v3 API?

No. Both v2 and v3 APIs retired at the same time on June 30, 2024, so there’s no benefit to moving between them. The migration that matters now is off the platform entirely.

What happened to video analysis and Video Indexer?

Azure Video Indexer was not retired. Its dependency on a Media Services account was removed before the shutdown, and it now runs independently with stronger transcription, translation, and speaker-identification models than the old analyzer presets.

How long does migrating off Azure Media Services take?

It depends on the path. Re-pointing to a partner that preserved assets can take days, while rebuilding a full custom pipeline on another cloud can take weeks. Using an API-first platform is typically the fastest, since you upload or point at existing files and get playable streams back quickly.

Can I still recover my Azure Media Services data?

Your raw files in Azure Storage are still recoverable. The account metadata that mapped those files to renditions and protection policies was deleted ~90 days after deactivation, so if that window has passed, the catalog has to be reconstructed manually from the stored files.

Moving Forward After Azure Media Services

Azure Media Services solved a real problem — encoding, streaming, protecting, and delivering video without running your own infrastructure — and its retirement didn’t make that problem go away. It just moved the responsibility to you to pick a new home for those workloads.

The single most important decision is how much infrastructure you want to operate going forward. If the answer is “as little as possible,” an API-first platform matches the original appeal of Azure Media Services more closely than rebuilding the stack on another cloud.

Ready to rebuild your video pipeline? LiveAPI gives you instant encoding, RTMP and SRT live streaming, automatic live-to-VOD, HLS delivery across multiple CDNs, and pay-as-you-grow pricing — launch in days, not months. Get started with LiveAPI.