This website uses cookies to help improve your user experience
A goal scored at a major football tournament starts its life as raw camera footage and has to clear ingest, transcoding, QC, and rights verification before Fox gets its English-language cut, Telemundo gets its separate Spanish-language production, and a properly archived master lands somewhere it won’t be touched again until someone needs it for a retrospective.
Two minutes after a controversial VAR decision, every broadcaster in the rights pool wants the same sequence: the original incident, the referee review, the moment the call gets confirmed. Fox needs it with English commentary cut in. Telemundo wants the Spanish feed. The host broadcaster needs a clean international version with no commentary track at all, and someone on the archive team needs a properly tagged master copy before the referee has even signaled full time. Every one of those requests is hitting a different system, on a different clock, and they all trace back to the same ninety seconds of footage.
Most media organizations aren’t running a tournament. However, even a solid workflow can encounter its own version of the VAR moment when something that wasn’t designed for it lands in the pipeline and the gaps become visible.
Many years of building workflow-driven media asset management (MAM) and media orchestration systems for broadcasters, media companies, and content distributors, including the implementations that went well and a few that didn’t, shape what follows.
We talked to Oleg Stepanyuk, Head of Presales Engineering at Oxagile, who has spent years working directly with broadcasters and media companies on MAM and orchestration implementations, from initial architecture decisions through to rollout.
“Every MAM rollout I’ve worked on succeeds or fails based on whether the workflow can change as quickly as the organization. The platform is almost never the actual bottleneck.”
Key takeaways:
A media asset management workflow is the sequence of steps an organization uses to move video, audio, and image assets from capture to archiving or retirement. The MAM platform stores and catalogs the assets. The workflow is everything that happens to an asset between its arrival and being usable: validation, enrichment, approvals, and handoffs between systems and people.
MAM is often grouped with digital asset management, but the distinction matters in practice:
The types of MAM software available today range from on-premises systems built for tight compliance and security control, to cloud-native platforms designed for elastic capacity and distributed teams, to hybrid deployments that split workloads across both, each suited to a different operational profile.
For a broader walkthrough of MAM features and a deployment checklist, see our media asset management overview.
Most established MAM vendors, Dalet, Vidispine, Tedial among them, offer genuine flexibility, and for organizations operating within a reasonably standard toolset, a packaged platform covers a lot of ground.
Oleg notes:
“The gap opens at the edges. A vendor’s flexibility extends to the integrations already in its connector catalog, the data model it was designed around, and the processing logic it knows how to handle.”
Legacy infrastructure, proprietary partner endpoints, regional toolsets that nobody anticipated at a vendor’s roadmap meeting, these tend to sit outside that boundary. When enough of the operation lives there, workarounds start accumulating faster than configuration can keep up.
Custom workflow orchestration makes sense in a few specific situations:
Oleg comments:
“In most of the implementations we’ve worked on, the MAM platform stays. The orchestration layer built around it handles what the platform was never designed to own, and the two end up doing complementary work rather than competing for the same job.”
Workflows vary across organizations, regions, and operating models, and the steps below get reordered, merged, or split depending on the business.
A typical cloud media asset management workflow moves through seven broad stages.
The delivery and playback layer gets its own treatment in our guide to live streaming platform development.
As Oleg puts it:
“On a diagram, this may seem like a clean line from ingest to archive. In a working media operation, assets loop back through QC after a failed validation, get re-enriched when a new distribution requirement appears, or wait in production far longer than planned while rights clearance takes its time.”
Routing, integrations, handoffs, and observability run across every stage, which is what makes the orchestration layer the real operational backbone, not the stages themselves.
Media asset management workflows can look orderly on a diagram, with a clean line running from ingest to delivery, but real media operations rarely move that way. A feed coming out of a major tournament venue has to clear an ingest server, move through a transcoding farm producing a dozen output formats, pass an automated QC check, get its rights and metadata verified, and land with whichever of a dozen-plus broadcast partners needs that particular version, all before a control room ever sees it.
Orchestration exists to keep that sequence reliable. Storing and cataloging the asset is a separate job, one MAM platforms handle well on their own, and routing it through a dozen interdependent systems is a different problem that most weren’t built to own.
A typical MAM workflow involves ingesting, enriching metadata, producing, delivering, and archiving content within a single platform’s interface.
As media operations grow, staying inside one platform stops being realistic. Assets move across storage systems, transcoders, QC tools, editing environments, playout systems, rights management platforms, and distribution endpoints, sometimes all within the same hour.
Oleg explains:
“One source feed out of a tournament venue reaches Fox’s production team, Telemundo’s separate Spanish-language production, and Bell Media’s Canadian broadcast inside the same few minutes, with each team pulling a different graphics package, commentary track, and replay pace out of that single raw signal.
The most common mistake at this stage is designing workflows around systems instead of the people running them day to day. An operator pulling a clip for Telemundo’s broadcast doesn’t care how elegant the routing architecture is if it adds two extra clicks to getting that clip out before air.”
We’ve spent years building the orchestration layer for broadcasters and content distributors managing exactly this kind of complexity, the routing logic, the system integrations, the parts that don’t show up on the original architecture diagram. Tell us where your current setup breaks down, and we’ll walk through what fixing it actually looks like.
A MAM workflow appears fine on launch day. The cracks appear at any time, even 18 months later, when the original design’s assumptions about volume are no longer met, a new region is folded in, or the tooling underneath is gradually replaced.
The following draws on Oxagile’s multiple years of building workflow-driven MAM systems with media companies, broadcasters, and distributors, including lessons that only became obvious in hindsight.
Media processing tools don’t stay the same. The QC system that a team standardizes on this year may be replaced within a year and a half, often before anyone has finished writing the integration for the previous one. There’s no reliable way to predict which part of the system will be replaced next. And approaching each replacement as its own development project can turn integration work into an unexpected bottleneck.
We’ve gotten the most mileage out of treating workflow steps that handle custom integration work, running a Lambda function, and making an HTTP request as atomic building blocks inside the orchestration layer instead of handling each one as a one-off development ticket. This approach makes a new integration look more like a configuration change than a software release. With it, a workflow designer with basic scripting skills can set up a proof of concept without waiting for a full development cycle.
Oleg notes:
“The workflow itself is rarely the hard part. Keeping dozens of integrations reliable as tools, formats, and business requirements change is where complexity accumulates.
In most of the implementations we’ve worked on, the complexity comes from connecting diverse systems and keeping that connection reliable, not from any single processing step. A transcoder passes through QC before it gets anywhere near a playout system, gets logged somewhere a ticketing system can see it, and clears whatever rule a metadata platform has flagged before editing software ever touches it.”
Once the network of dependencies becomes dense enough, automating a single step becomes less important than maintaining coordination across the entire chain to prevent operational chaos.
Regional teams inside the same organization operate differently from each other almost by default, and forcing them into one rigid process produces workarounds instead of compliance.
A distribution partner in one market needs assets delivered in a specific format with its own metadata schema. An affiliate network in another runs a different QC checklist before anything hits its playout system. A rights holder requires clean versions without embedded branding that everyone else takes for granted. Same source material, entirely different requirements downstream, and a workflow that can only do one thing breaks the moment a second market comes online.
Systems that handle this well rely on finely grained, customizable workflow tasks built around standardized input and output variables, paired with a drag-and-drop interface that lets a non-developer assemble a variation from a shared component library. Input and output values get assigned dynamically based on each task’s outcome, which makes it possible to support a region’s specific requirement without writing new code for it.
Oleg shares:
“We’ve seen organizations over-engineer workflow flexibility and others lock themselves into rigid process chains. The right level usually sits somewhere in the middle.
That balance matters most once an organization has more than a handful of regions, business units, or client accounts running through the same workflow engine, where the underlying conditions almost never hold still long enough to lock in one fixed process.”
Most vendors market standardization as the goal. The implementations that hold up over time accommodate variability instead, without requiring engineering involvement every time a process changes somewhere in the organization.
Oleg illustrates:
“Granularity of workflow bricks is one of the more challenging architectural decisions in a MAM rollout, and its impact can be both positive and negative. If you push too far toward atomic steps, the system becomes difficult to design and harder for operators to run day to day because the level of control that makes engineers happy tends to produce something too complex for people who have to use it under a deadline.
On the other hand, if you go too coarse, the workflow is easy to operate on day one, but it starts to resist change the moment a new region or format appears.”
The middle ground that works involves building reusable sub-workflows for independent segments of the processing chain, raw asset delivery, validation, proxy creation, transcoding for OTT or playout, and keeping input and output variables consistent across every level. A segment built for one part of the chain can then be called from a larger workflow, or swapped out when requirements shift, without pulling everything else apart with it.
A media organization operating across multiple business units needed a single orchestration platform that could handle genuinely different processing requirements in each of them, without forcing every unit into the same workflow shape or spinning up a custom build every time one region needed something different.
The architecture Oxagile designed centered on reusable sub-workflows with consistent input and output contracts across every level, fine enough for a workflow designer to tune a single validation rule without touching the rest of the chain, coarse enough that operators across different units could actually use the system under deadline.
The result was a platform that absorbed new units, new formats, and new processing agreements without a rebuild each time.
A MAM workflow built around how system architects imagined the operation working, instead of how operators actually move through their day, fails in a way that’s hard to spot. Workarounds in a digital asset management workflow may appear here and there, nobody flags them as a problem, and within a few months, the organization is quietly running half the old process alongside half the new one.
Which is why workflow architecture must assume change. New customers, regions, formats, and tools might all need future-proofing.
The six weeks we spent on site with different business units during a recent rollout paid for themselves several times over before we wrote a line of workflow logic. Although each unit was running the same business, the mix of tools, informal rules, skill levels, and habits that operators had developed over the years differed enough by location that imposing a single workflow in the name of consistency would have created more friction than it eliminated. Recognizing this early on shaped the entire architecture.
Expert comment:
“A workflow designed around today’s media operation has a shelf life, and it’s shorter than most teams expect. Something in the stack almost always shifts before the system has fully paid back its implementation cost, and building adaptability in from the start costs less than retrofitting it once growth forces the issue.”
The organizations that avoid a costly redesign at the eighteen-month mark are usually the ones that planned for change before they needed to.
The organizations that hold up at scale have usually figured out that a smaller set of well-built workflow components, reused deliberately across every new region, unit, or client account, is worth more than a custom build for every new situation. A mature media operation is measured not by how many workflows it has built, but by how few it needs because the underlying building blocks do the work.
One rollout clearly illustrated this. The operational units that came onto the platform were all over the place. Some were still coordinating work through spreadsheets, while others were running partial script-based automation, which lacked consistency between sites. Building a custom workflow from scratch for each unit would have created maintenance problems immediately. Instead, we began with the units that had the least automation in place. We converted their spreadsheet-driven processes into proper orchestration while there was still time to gather real feedback. Then, we allowed the resulting sub-workflows to propagate across the other units as they came on board. Each new site received training and documentation alongside the components, so adoption didn’t mean starting from scratch.
In practice, keeping input and output contracts consistent across every component made that propagation work. A sub-workflow designed for one unit’s validation step could be used by another unit with a different toolset because the input and output contracts remained consistent. Over time, designing workflows stopped being a one-off project for each new unit and became more like pulling from a shared library that the organization already owned.
Storage decisions in a MAM rollout sit at the intersection of cost and control, and most organizations land somewhere between fully on-premises and fully cloud native.
Live sports broadcasting makes the tradeoffs concrete. Raw ingest from dozens of venues often lands on local or edge storage first, where bandwidth and latency constraints make cloud ingestion impractical at the moment of capture. Processed proxies and mezzanine files move to the cloud for distribution and collaboration.
The archive material from those same events, rights-sensitive and frequently licensed for retrospectives and highlight packages years later, often stays on-premises, where retrieval costs on large volumes are more predictable than cloud egress fees.
As Oleg mentions:
“Both requirements are real, and they pull in opposite directions. A hybrid setup only works if the file transfer layer underneath it can actually bridge the gap.”
We’ve built this as a dedicated File Transfer Engine that monitors and incrementally syncs between external and internal storage, covering S3 buckets, on-premises servers, FTP and SFTP endpoints, non-native S3 accounts, and Aspera for high-volume transfers. That breadth matters because a media organization almost never standardizes on a single storage protocol across every partner, region, and legacy system it accumulates over time.
A media organization came to us with a system that had done its job well for years, until it hadn’t. What started as a manageable workflow had grown into a patchwork of integrations, storage tiers, and manual workarounds held together by institutional knowledge with no real architecture underneath it.
We rebuilt the underlying structure without replacing what was working, connecting disparate storage layers, consolidating the transfer logic, and giving the operations team a workflow they could actually maintain as requirements kept shifting.
Performance improved. The workarounds disappeared. The system became something the organization could hand off without a three-hour briefing.
MAM initiatives succeed or fail on a single axis: whether the workflow can change as fast as the organization running it. Storage, cataloging, even processing, most platforms handle those competently. What erodes is the layer in between, the routing logic, the integration contracts, the handoffs between systems and teams that have to keep working as new regions come online, tools get replaced, and requirements shift in directions nobody anticipated at launch.
Off-the-shelf orchestrators offer flexibility by design, and within their connector catalogs and data models, they deliver on that promise. The gap shows up when the operation includes legacy systems, proprietary partner endpoints, non-native storage protocols, or rights infrastructure that no vendor anticipated. That’s where the boundaries of a packaged platform become the actual bottleneck, and where the architecture underneath the workflow starts to matter more than the workflow tool itself.
Avoiding a costly redesign has less to do with platform sophistication than with how the work was approached from the start, treating adaptability as a first-class requirement, building integration flexibility in before it was needed, and spending real time with operators before writing a line of workflow logic.
We’ve spent years solving exactly this class of problem for broadcasters, media companies, and content distributors: the orchestration layer, the integrations, the architecture decisions that determine whether a MAM initiative ages well or needs a costly redesign two years in.
If your current setup is starting to show those cracks, let’s talk about what fixing it actually looks like.
Assets enter the system from a camera, contributor upload, or partner feed and immediately go through technical validation, basic metadata capture, and a storage tier decision. Everything (downstream, enrichment, production, delivery) depends on how well that first pass is handled.
Without consistent tagging, transcription, and technical metadata captured at ingest, even a well-organized archive in a cloud tool for media asset management workflows becomes difficult to search. Organizations end up re-shooting or re-licensing content that already exists somewhere in the system, which is one of the more avoidable costs in a media operation.
The vendor UI becomes inadequate when assets start moving across more systems than the MAM platform was designed to handle. This includes transcoders, QC tools, playout systems, and distribution endpoints.
This becomes apparent more quickly when those integrations need to behave differently by region or business unit because a single fixed path becomes ineffective the moment one team requires something that the others don’t.
MAM software doesn’t move files in isolation, it orchestrates what happens to an asset at each stage of its lifecycle. A file entering the system gets validated, tagged, transcoded into the formats each downstream system expects, routed through approval or QC steps, and eventually delivered to a playout system, distribution partner, or archive tier.
The underlying file transfer infrastructure handles the transfer itself, whether that’s an S3 sync, an Aspera transfer, or an FTP endpoint. Still, MAM determines when the move happens, where the file goes, and what condition it needs to be in before it gets there.
