An honest decision framework for broadcasters and rights holders choosing between traditional REMI, cloud-based REMI and hybrid workflows, with the trade-offs that actually matter.

If you’re weighing up how to produce your next season, or your next ten, the choice between REMI, cloud production and a hybrid of the two is one of the more consequential decisions you’ll make. Get it right and you free up budget, scale up your output, and move faster than your competitors. Get it wrong and you either buy hardware you regret, or you push a workflow into the cloud before your contribution network or your team is ready for it.

This piece isn’t a pitch for one approach over the others. It’s a framework for choosing between them honestly, based on what your operation actually needs to do.

A quick recap of the three workflows

We’ve covered the definitions in detail in our guide to cloud video production, but the headline distinctions are these:

• REMI (remote integration): cameras stay at the venue, the production team works from a central location. Traditionally this central location is a fixed broadcast gallery with dedicated hardware, often fed by bonded uplink units sending the signals back from site.
• Cloud-based REMI: the same remote model, but the central production runs as software in the cloud rather than on dedicated hardware in a fixed gallery. The team works from anywhere via a browser.
• Hybrid: a combination of the two. Some productions stay on the existing hardware estate; others run in the cloud. Often this is a deliberate transition stage rather than a permanent destination.

Traditional on-site / OB production sits outside this comparison. It’s the model all three are designed to replace or augment for the events where flying the truck no longer makes sense.

The honest decision framework: which workflow when

Three questions tend to settle the choice: how variable is your production volume, how much hardware do you already own, and how many platforms does your output need to land on?

When traditional REMI (hardware gallery) still wins

If you produce a high, predictable volume of the same kind of show from the same gallery every week, and you’ve already paid for the hardware, the economics of ripping it out aren’t obvious. Traditional REMI is also the safer bet when you have a deeply experienced engineering team built around physical kit, or where regulatory or contractual obligations specifically require it. The downside is the one it’s always had: you’re paying for peak capacity year-round, and adding output formats or destinations means more boxes.

When cloud-based REMI wins

Cloud-based REMI is the right answer when any of three pressures are real: your production volume is variable (so you’re paying for hardware that sits idle), you need to publish to multiple platforms simultaneously (broadcast plus OTT plus social, often in different aspect ratios), or you want to widen the talent pool by letting operators work from anywhere. It’s also the only realistic way to produce tiers of sport, news or live content that were never economical on a hardware budget, because the marginal cost of an extra production is a configuration, not a capex line.

When a hybrid workflow makes sense

Hybrid is rarely the destination, but it’s often the right path. The pattern that works: keep the existing hardware running for the productions it’s already amortising, and put new output (second-tier matches, vertical alt-casts, multi-platform feeds, ad-hoc events) in the cloud. Over a couple of seasons the cloud share grows naturally as the hardware reaches end of life, without writing off a working investment overnight. Treat hybrid as a managed transition, not a hedged permanent state.

REMI vs cloud-based REMI vs hybrid: a side-by-side

The differences that matter most when you’re actually making the call:

	Traditional REMI	Cloud-based REMI	Hybrid
Cost model	Capex-heavy; pay for peak capacity year-round.	Opex; pay for capacity on demand.	Mix of both; depreciating hardware plus cloud opex.
Scaling	Limited by installed hardware in the gallery.	Elastic: spin productions up and down per event.	Cloud handles spikes; hardware handles the baseline.
Team location	Centralised in a fixed gallery.	Anywhere with a browser.	Gallery for some shows, distributed for others.
Hardware investment	Significant up front and on refresh.	None for production; contribution kit only.	Existing estate retained; no new gallery hardware.
Multi-platform output	Possible but adds hardware per format/destination.	Native: multiple outputs from the same sources.	Easier than pure hardware; depends on what runs where.
Sustainability	Trucks gone, but hardware estate remains.	Lowest: no trucks, no on-site galleries.	Improves as the cloud share grows.
Best fit	High, stable volume from a single gallery.	Variable volume, multi-platform output, distributed teams.	Broadcasters mid-transition or running tiered output.

The questions to ask before you commit

Whichever way you’re leaning, these are the things worth pressing any vendor on before you sign. They’re the practical details that decide whether a workflow holds up under live conditions.

Contribution: how does the signal get there?

Every cloud or REMI workflow depends on getting reliable, low-latency feeds from venue to gallery or to the cloud. That means bonded cellular or fibre uplink at the venue, and transport protocols built for unmanaged networks (SRT, RIST, Zixi). If a vendor’s strength is the encoder on the truck but the production side is comparatively thin, you may be solving one half of the problem and leaving the other half unaddressed. Make sure the workflow is strong end to end.

Latency: is it low enough for what you do?

End-to-end latency matters differently for a live sports broadcast, a betting feed, and a near-live highlights workflow. Ask for the actual figure end to end, from camera at the venue to viewer on the platform, not just the production element, and pressure-test it against your use case.

Frame accuracy and multi-format output

Broadcast-grade production needs frame-accurate switching and synced audio, not a best-effort approximation. It also needs to produce more than one output shape from the same sources, 16:9 for broadcast, 9:16 vertical for social, often a square or 4:5 for in-feed. Ask whether multi-format is genuinely simultaneous from one production, or whether it’s a second workflow bolted on.

Cloud-native vs cloud-hosted

Not every cloud product is built the same way. Some are genuinely cloud-native, designed from the ground up to run as software, scale on demand and be operated from a browser. Others are existing hardware products hosted on a cloud VM, which can leave you with the constraints of the hardware without the elasticity of the cloud. The difference shows up in scaling, pricing and how easily you can spin productions up and down.

Redundancy, support and ad insertion

For premium live, you need clear answers on failover, on the support model during an event, and on how server-side ad insertion is handled, because the monetisation layer is rarely an afterthought you can solve later.

The vendor landscape, briefly

The market has broadly split into three groups. There are established broadcast vendors moving from hardware to software at various speeds. There are contribution-first vendors whose strength is the encoder and the bonded uplink getting the signal off the venue, the production layer on top is comparatively newer. And there are cloud-native production platforms built specifically for the model from the start. None is automatically the right answer; what matters is matching the vendor’s real strength to the part of the workflow you most need to solve.

Frequently asked questions

Take a look at our related blogs: