Amazon Elastic Transcoder support ended on 13 November 2025. For file-based video processing, AWS recommends AWS Elemental MediaConvert; for live-video encoding, AWS identifies AWS Elemental MediaLive instead.
The right replacement depends on what your workflow does, not simply on which service name sounds closest. Start by listing your inputs, outputs, timing requirements and dependencies, then map each job to the service designed for it.
Elastic Transcoder support has ended
The discontinuation is already in effect. AWS’s service notice says that, from 13 November 2025, customers can no longer access the Elastic Transcoder console or its resources. Treat this as a shutdown, not a future deadline: do not plan on opening the old console later to retrieve a preset or inspect a job.
AWS’s service notice and pricing page is the primary reference for the status. The AWS migration guide maps file-based workflows to MediaConvert. AWS’s MediaConvert FAQ distinguishes the service from MediaLive, which AWS recommends for live-video encoding.
This distinction matters if your operation includes both a library of recorded videos and a live channel. A system that encodes an uploaded sermon or a batch of news clips is doing file processing. A system that encodes an incoming live feed for broadcast is doing live encoding. They may share storage or delivery components, but they are not the same job and should not be migrated under one assumed replacement.
If existing configuration is missing, do not assume AWS’s old conversion scripts will recover it. The published sample scripts rely on calling Elastic Transcoder to retrieve resources, and their README warns that this access ends with the service. Check exports, infrastructure definitions, application configuration and backups first. For account-specific recovery questions, ask AWS Support; the available guidance does not establish a universal recovery route after shutdown.
Identify the jobs and outputs in use
Before choosing a successor, write down what Elastic Transcoder actually did in your workflow. A useful inventory starts with each source: where the file or live input came from, what starts processing, what output you expected, where it was stored, and what system was notified when it finished.
For every output, note the container and codec, resolution, frame rate, audio treatment, captions, packaging format and destination. Also record requirements that are easy to overlook: overlays, scaling, encryption or DRM, file naming, metadata, access permissions and retention. If one source produced several renditions, document each separately rather than describing the whole job as “make it ready for streaming”.
Then identify the workload type and service boundary. Does a file arrive, get processed and become available later? That is a file-based workflow to assess against MediaConvert. Is a camera, encoder or other live source being encoded as it arrives for a broadcast? That points to MediaLive. A workflow may contain both: for example, recorded programme files may be processed for an archive while a separate live event is encoded for transmission.
Capture operational behaviour as well as media settings. Record who or what submits jobs, how retries work, whether jobs run in parallel, where logs and alerts go, and how downstream applications learn that an output is ready. A migration can produce a playable file and still fail operationally if the application never receives its completion event or the output lands at a path the player does not check.
This inventory is also the basis for a fair cost and turnaround comparison. Job duration, output characteristics, volume, concurrency, region and any acceleration needs can all affect the design and bill. Avoid treating a single sample job or advertised starting rate as a forecast for your account; use representative jobs and current region-specific information.
Choose MediaConvert for file processing
MediaConvert is AWS’s recommended destination for file-based transcoding workflows. In practical terms, it processes media files into configured outputs rather than encoding a live input as it arrives. If your Elastic Transcoder setup handled uploaded recordings, pre-produced clips or batches for later playback, start by mapping those jobs to MediaConvert.
AWS describes MediaConvert as supporting a broad set of codecs and processing features, including HEVC, Apple ProRes, AV1, Dolby Audio, CMAF outputs, captions, overlays, scaling and audio normalisation. Its migration article also states capabilities up to 8K resolution and 120 frames per second. These are AWS’s published capability claims, not a guarantee that every combination suits your particular source, output or account. Check the current service documentation and test the exact settings you require.
A replacement decision should begin with the required result, not a feature checklist. If a phone-recorded devotional programme must become a particular playback format with captions and a logo overlay, confirm each requirement against current MediaConvert support. If the existing workflow uses a streaming package or DRM arrangement, verify that the replacement produces compatible outputs and that the playback side can still consume them. A codec being supported does not by itself prove that the entire delivery chain is compatible.
Throughput and turnaround should be tested using your own material. AWS says MediaConvert is optimised for processing more files in parallel and describes accelerated transcoding as an option. That does not tell you how long your queue will take under your workload, nor whether acceleration is worthwhile for it. Measure representative short and long files, include peak batch periods, and consider how much delay your publishing process can tolerate.
The pricing model also needs a workload-specific estimate. AWS describes on-demand pricing based on output duration and characteristics, with Basic and Professional tiers, per-second billing and volume discounts; its migration article describes reserved pricing with a 12-month commitment. Prices and availability can change, so consult the current AWS pricing information for your region and estimate from the outputs you actually plan to make. A commitment may not suit a seasonal channel or a small team whose volume is hard to predict.
MediaConvert is a better fit when files are processed before viewers need them, and when batch output, format conversion or post-production processing is the core task. If your requirement is to take an active live feed and encode it for broadcast, do not select MediaConvert merely because it is the named migration destination for Elastic Transcoder. That is a different workload.
Choose MediaLive for live encoding
For live-video encoding, AWS points to AWS Elemental MediaLive. This is the important boundary in the migration: MediaConvert is the file-processing replacement, not the live-video encoding replacement. If you were sending a live camera or programme feed into an encoding workflow, assess MediaLive and the rest of the live contribution and delivery chain.
A live workflow has different failure and timing concerns from a file job. You need to consider how the source enters the system, what happens if the input is interrupted, which output destinations are required, and how operators see and respond to a fault. Compare the required codecs, resolution, frame rate, audio layout, captions, packaging and delivery path with current MediaLive documentation. Also map the monitoring and recovery responsibilities: a live channel has no finished job event that can simply be retried tomorrow.
For a small YouTube channel, first establish whether you actually need a cloud live encoder. A pre-recorded video played continuously is not necessarily the same as encoding an incoming live feed. Some operators use a computer or another workflow to send a repeating playlist; others need to encode a genuine live source. The distinction changes both the service choice and the operational burden.
If your channel depends on a local computer staying connected, document what happens during a power cut, network drop or unattended restart. The practical concerns in monitoring a 24/7 YouTube stream with an Android phone are useful regardless of which encoding route you use: remote visibility helps you notice a problem, but it does not replace a tested recovery plan. Likewise, if a playlist should bridge multiple clips without ending the broadcast, keeping an FFmpeg stream running between playlist videos is a separate operational question from choosing a cloud video-encoding service.
Do not use a live service to solve a file conversion problem simply because the source material will eventually be broadcast. Nor should you push a file-processing service into a live role without verifying that it supports the timing and input behaviour you require. Keep the workload classification explicit in the design and in the migration plan.
Recreate jobs, presets and templates
Once the target service is chosen, recreate the behaviour rather than trying to preserve old configuration names. Translate each legacy job into its inputs, output groups, destinations, media settings, notifications and failure handling. Then build a new preset or template only where it captures a repeatable requirement; a template is useful when it prevents staff from selecting inconsistent output settings, not simply because an old preset existed.
AWS’s February 2025 migration article describes workflow guidance and a script-based approach for converting presets. AWS Samples also published scripts for preset and job-setting conversion. However, the sample README says the scripts call the Elastic Transcoder API to retrieve resources and would stop working after discontinuation. Since the service has been shut down, do not make those scripts the first step or assume they can query old account state now.
Instead, gather the surviving sources of truth: exported JSON or XML, application code, deployment templates, logs, saved screenshots, job submission payloads, media specifications and notes from the people who operated the workflow. A configuration file may reveal a destination bucket or a preset identifier without preserving the full media settings, so compare evidence from more than one source. If a value cannot be established, mark it as an open question and test alternatives rather than silently guessing.
Conversion tools can still be useful when you already have the relevant settings. Treat their output as a draft mapping, not as a validated production configuration. Check every field that affects the output and every integration that affects the process. A converted preset that looks plausible may still differ in audio handling, caption behaviour, image placement or naming convention.
Keep a traceable mapping table while rebuilding. For each former job, record its purpose, evidence source, new service, replacement configuration, unresolved assumptions and test result. This makes review easier when several teams share responsibility for the migration, and it helps you decide which old jobs can be consolidated and which represent genuinely different outputs.
Plan and validate the migration
A safe migration is staged. Begin with a requirements inventory and a target design; then create the new configuration in a test path or other controlled environment. Run representative files or a non-production live input, compare the results with expected behaviour, and only then move a workflow that viewers or customers depend on. Do not interpret the vendor’s migration guidance as a promise of one-click equivalence or guaranteed approval of your outputs.
Validation should compare the result against the source workflow, not merely confirm that a file was created. Check picture and sound from start to finish, inspect the beginning and end of clips, and verify that duration and aspect ratio are as expected. For each required output, check codec, container, resolution, frame rate, bitrate behaviour where relevant, captions, audio channels, overlays, encryption and packaging. Confirm that downstream playback works on the devices and applications your audience uses.
Test failure paths as well as successful runs. What does the submitting application do if a job is rejected, delayed or retried? Does a repeated event create duplicate output? Does a failed output remain in a location that a consumer could mistake for a finished file? For live encoding, test what the operator sees if the source drops and how they restore the feed. Write down the manual steps that still require a person.
Plan a cutover with a clear rollback decision. Keep the old workflow’s evidence, source files and known-good outputs available according to your own retention policy, but do not rely on Elastic Transcoder itself being accessible. Define what would make you pause a rollout: a missing caption track, an incompatible package, unacceptable processing delay, a broken notification or an unexpected cost pattern. Those are requirements-based decisions, not universal thresholds.
Cost validation belongs in the same plan. Use actual representative inputs, output settings and expected volume to estimate the target design using current regional pricing. Include any surrounding storage, event, monitoring or data-transfer services that your workflow uses, and check whether an acceleration or commitment choice changes the economics. Review actual usage after launch before expanding the migration to every queue or channel.
For a recurring YouTube channel, the migration can also expose problems that are not in the transcoder settings: source reliability, playlist behaviour, or whether a stream resumes after a network interruption. The guide to RTMP reconnects that do not resume an FFmpeg YouTube stream is relevant when testing that specific failure mode. It should not be treated as a substitute for the AWS service decision; it addresses the broadcaster’s reconnect behaviour.
Check downstream workflow dependencies
A transcoder rarely stands alone. Trace every hand-off from source to viewer: storage location, job submission, permissions, output bucket or destination, notification, database update, player or distribution system, and monitoring. AWS’s migration guidance discusses integration with services including S3, SNS, SQS and CloudWatch. If your workflow uses any of them, recreate and verify the permissions and event behaviour rather than assuming that a similar output will preserve the old wiring.
Pay particular attention to names and paths. A downstream player may expect a fixed key pattern, a manifest alongside segments, or a particular folder for each channel. A successful encoding job can still look like an outage if it writes to a new path that the application does not poll. Similarly, a notification that changes shape or arrives at a different stage may cause a workflow to publish incomplete media.
Review access boundaries and secrets while rebuilding. Determine which role submits jobs, which role reads source material, and which consumers read outputs. Avoid broadening permissions just to make a test pass; identify the missing action or resource and grant only what the design requires. Keep credentials and stream keys out of shared notes and logs.
Finally, assign operational ownership. A small channel may have one person who uploads files and checks playback; a larger workflow may have separate media, application and cloud teams. Name who watches alerts, who can pause a batch, and who decides whether an output is good enough to publish. If the migration changes a manual step, update the runbook before the person who used to know the old process is unavailable.
Choose a route that matches the channel
The decision can be made with a short set of questions. The table is a starting point; the final design still needs to match current service documentation and your own requirements.
| What the workflow needs to do | Service to assess | Why it fits | What to verify |
|---|---|---|---|
| Process uploaded or stored files into delivery formats | MediaConvert | AWS recommends it for file-based Elastic Transcoder workflows | Exact output formats, features, queueing, integrations and regional pricing |
| Encode an incoming live video source for broadcast | MediaLive | AWS identifies it for live-video encoding | Input and output design, monitoring, recovery, latency needs and costs |
| Process recorded files and separately encode a live event | Both, for distinct jobs | The workflow contains two different workloads | Clear service boundaries, shared storage and end-to-end hand-offs |
| Play a pre-recorded loop as a continuous YouTube stream | First define the playback and broadcast design | A continuous channel does not automatically mean live encoding is the file-processing problem | How the source is played, sent, monitored and recovered |
There is no universal winner between these services because they address different tasks. MediaConvert is the relevant AWS replacement for files; MediaLive is the service AWS points to for live encoding. If you operate a nonstop channel from a pre-recorded playlist, decide whether the challenge is preparing the files, maintaining the outgoing broadcast, or both. These are separate decisions.
Some channel operators do not need to keep a local computer running a file loop. For that specific pain, StreamNeo turns an uploaded video into a 24/7 YouTube live stream, so you do not have to leave your own computer on to keep that broadcast running. It is YouTube-only and addresses that playback-and-broadcast use case, not a replacement for an AWS file-processing pipeline or a general live-encoding platform.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Is Amazon Elastic Transcoder still available?
No. AWS says support ended on 13 November 2025 and that users can no longer access its console or resources after that date. Check AWS’s current official service information if you need to confirm account-specific details.
What should replace Elastic Transcoder for file-based jobs?
AWS recommends AWS Elemental MediaConvert for file-based video processing and provides a migration guide. The right configuration depends on your source, required outputs, integrations and operational needs, so validate representative jobs before cutover.
Is MediaConvert the replacement for live-video encoding?
No. AWS identifies AWS Elemental MediaLive for live-video encoding. MediaConvert is the file-processing destination; classify the workload before selecting a service.
Can the AWS sample scripts retrieve my old jobs now?
Do not assume they can. The AWS Samples README says the scripts retrieve resources through the Elastic Transcoder API, which stopped being available when the service was discontinued. Look for exports and backups, and contact AWS Support about account-specific recovery questions.