Migrating from Azure Media Services: how does it work?

Isometric image of people moving the components of their streaming cloud infrastructure to a cloud with Cloud Video Kit logo

Microsoft is retiring Azure Media Services on June the 30th, 2024. This leaves the companies and developers who were relying on the AMS services for their streaming workflow in need of a new provider.

Although in their article about Azure Media Services retirement Microsoft lists several recommended migration partners, those usually offer proprietary services based on Azure cloud. Many companies, however, are taking a different approach and have begun looking for a different cloud service altogether for their video processing and delivery needs.

One of the most common choices is Amazon Web Services (AWS) and its Media Services. Why? One reason is the fact that they are strong enough to handle the biggest video services such as Twitch or Peacock. Another is the scale of AWS’s investments in their Media Services and the Media & Entertainment sector in general (just take a look at their product updates section).

If you or your company are considering switching the cloud provider, but you are unsure of how the process looks and if it won’t disrupt your regular business – keep reading.

Preparing for the migration: choosing Azure Media Services replacement

Before you decide on a new provider and sign the offer, you might – and should – expect to see a migration plan. In order to create it, the company will need to schedule a consultation to find out more about your existing architecture, as well as your technological or business needs for the future.

Here is what the potential provider might ask you about:

  • Video content type – whether you offer live or VOD content (or both). In the case of live broadcasts, the provider might also ask if you are streaming occasional events or full-time live channels, and if you are recording your live broadcasts as separate files.
  • Required video formats – what codecs (e.g H.264, HEVC) and streaming protocols (e.g. HLS, MPEG-DASH) you are currently using (or would like to use).
  • Content volume – for VOD files, this is usually measured in hours of content. For lives, this might mean the number of events per month or the number of your live channels.
  • Audience size – measured in the number of viewers watching your VOD or live streams, or your CDN traffic.
  • Current video player – the provider might want to determine if you are using a proprietary player (and if so, if it is based on Azure Cloud) or a third party’s service.
  • Content protection – you will need to specify if you want to protect your videos from unauthorised access through URL access limiting, geoblocking, or DRM encryption (and if so, if your current player is DRM-compatible).

This information should allow the new provider to prepare a migration plan and send you an offer.

The migration process: how does it work?

“Video streaming workflow” is a broad term. That makes it hard to describe a migration process that would be 100% accurate for every scenario. The exact steps may vary depending on your current architecture, the chosen provider’s know-how, and their solution.

But you are not reading this article to get a rather unhelpful “it depends” answer. That is why we are going to discuss the process using our Cloud Video Kit service as an example. The reason for that is: migrating from other services was one of the main scenarios we had in mind when designing the solution. It also has a 100% feature parity with the current Azure Media Services package, allowing for a smooth transition.

Here is how it goes:

Step 1 – Creating an account

First, we set up your Cloud Video Kit tenant account. After the migration, it will give you access to the Cloud Video Kit admin panel and let you easily manage and publish your assets.

Step 2 – Migrating the video content

  • VOD

It is the most time-consuming stage. If you stream VOD content, it will need to be migrated from Azure Storage to the AWS cloud storage, Amazon S3. We can handle it in two ways: copying the encoded assets from Azure Storage or uploading the raw source files directly to Cloud Video Kit.

We will always recommend and strive for the first option. Why? Because uploading the raw files is only advisable when you don’t have access to the encoded assets. Once uploaded, they will require extra time – and extra costs – to be encoded into the right format again. Luckily, if you were working with Azure, that is rarely the case. Our team should be able to copy the files from the storage (or record them from a CDN) and keep the costs low.

  • Live

If you plan on streaming live content, we will first create you a live channel within Cloud Video Kit. You will be able to turn it on and off during live events or keep it running to broadcast 24/7. Once the channel is up, it is just a matter of copying the link to the live source into Cloud Video Kit.

Step 3 – Securing your videos

Are your videos secured with Azure Content Protection? If you want to keep the DRM encryption, we will switch you to our Digital Rights Management solution, Cloud DRM. To do that, all we need is the key ID – but it is also possible to encrypt your content with new keys.

Rest assured, you will be able to enjoy the same level of protection. Cloud DRM is powered by the major studio-approved DRMs: Microsoft PlayReady, Google Widevine, and Apple FairPlay.

Step 4 – Changing the Content Delivery Network (CDN)

This one is self-explanatory: if you have been relying on Azure CDN for content delivery, we will switch it to Amazon CloudFront.

Step 5 – Migrating the business logic

This part is about integrating Cloud Video Kit with your current CMS (for example, to add metadata to your videos) and updating the API integration of your streaming service. While some parts of the processes might have to be handled by you or your developers, keep in mind that our team is also ready to assist here.

You might be concerned if the migration doesn’t disrupt your regular business. Don’t worry – the process is designed to let you operate as usual while the transition is ongoing. What you can expect are two environments running simultaneously – the new one, based on Cloud Video Kit, and the former, Azure-based one. Once everything is set up properly, the final step is switching your streaming service to run on the new environment.

If you want to know more about the feature parity of Cloud Video Kit (or its different components, such as Cloud DRM) and Azure Media Services, visit our migration guide.

How long will this take?

While this is, again, an “it depends” type of question (with the crucial factor here being the content volume), here is a general estimate based on our experience:

  • The consultation stage should take about a week.
  • Preparing the migration and creating the migration script is another week.
  • The migration itself is the most tricky part to estimate – but unless you have tens of thousands of hours of VOD to transfer, it should also take around a week.

That gives us a three-week timeframe for the whole migration process. We don’t recommend waiting all the way until June, however – it’s always a good practice to give yourself more time for testing, training, or dealing with potential issues or change requests.

Azure Media Services migration: not as hard as it seems

Migrating from Azure Media Services may seem daunting at first. But, if you choose the right provider and solution, it doesn’t have to disturb your everyday operations. To be on the safer side, though, we recommend starting the process a few months before the migration date and giving yourself time to learn and get used to the new solution.

To read more about Cloud Video Kit and Azure Media Services feature parity and check the migration FAQ, visit our migration guide page.

If you have any questions regarding the migration or AWS Media Services, our certified AWS specialists (we have more than 20 of them on board) will be happy to answer them and clear any doubts.

Don’t wait until the last moment.
Talk to our specialists and plan your migration today.