The demo is always greenfield. Clean cameras, a clean cloud account, a live feed in a browser tab inside five minutes. And the demo is honest about the destination — that is genuinely where surveillance is going: live view on any device, from anywhere, nothing installed. But no customer you will ever sell into is greenfield. Every real deployment already has a recorder in a closet, cameras mounted years ago, an operations team trained on a particular VMS, and retention rules configured to satisfy a regulator. So adding cloud video surveillance is never a build. It is an integration on top of an incumbent that already owns the camera streams — and that single fact quietly reshapes the cost of the whole project.

The incumbent in the closet

Walk into any existing site and inventory what is already there. Cameras — often dozens to hundreds, bought over several years, each representing real capital. A network video recorder (NVR), or an older DVR, sitting on the local network, recording every camera around the clock. A video management system (VMS) the operators know by muscle memory. Retention configured to a mandate — 30, 90, sometimes 180 days. And an operational routine built around all of it.

None of that is free to discard. A mid-size estate of 200 cameras is tens of thousands of dollars in sunk hardware before you count the NVRs, the switches, and the labour that installed them. More importantly, the recorder already holds the camera streams and the compliance posture is already signed off. When a vendor's pitch quietly assumes you will throw that out to "go cloud," they are asking you to write off working capital and reset a regulator-approved process — and they rarely put that on the quote. So the real question is not "cloud or not." It is what you do with the recorder that is already there.

There are only three honest answers, and they have three very different cost shapes.

Three ways to add live video — three cost shapes

Every approach to putting existing CCTV in a browser reduces to one of three, and the difference between them is measured in disruption, not features.

Approach

What you do

Cost & disruption

Right when

Rip & replace

Retire NVRs, move to full cloud VSaaS

Highest — writes off sunk hardware, retrains ops, resets retention

The estate is end-of-life, or the incumbent vendor is a dead end

Augment

Keep NVRs recording; add a live layer that taps existing streams

Lowest — preserves CapEx and workflows; adds an integration + egress line

You need live/browser/mobile view without disrupting recording

Hybrid / phased

Augment now; migrate cameras to cloud-native as they age out

Spread over time — pay migration only as hardware retires

A large estate you want to modernise without a forklift

Rip-and-replace is clean on the whiteboard and brutal on the balance sheet: it writes off sunk hardware, retrains an ops team, and resets a compliance configuration that was working. It is the right call in exactly one situation — when the estate is genuinely end-of-life, or the incumbent NVR/VMS vendor has become a dead end you cannot integrate with. Augmenting keeps the recorder doing what it already does well and adds a thin live-video layer beside it. Hybrid is augmenting with a migration plan attached. Most sane deployments land on augment, then hybrid — and that is where a hidden constraint sets the real cost.

Because "just also pull the stream" sounds free, and it isn't.

Why "just also pull the stream" isn't free

The instinct when augmenting is simple: the camera is already producing a stream, so point the live-video layer at the same camera and pull it too. The problem is that a camera is not an unlimited source. Its main stream typically supports only a handful of simultaneous connections — often single digits — before the encoder or the camera's little onboard CPU runs out of headroom. And one of those connections is already spoken for: the NVR is holding it, continuously, to record.

So a second pull straight off the camera competes with the recorder for a scarce resource, and at any real viewer count you run out. The practical fixes — pulling the live feed from the NVR's re-stream instead of the camera, or using the camera's low-resolution sub-stream for live view while the main stream keeps recording — are exactly the kind of decision that looks like a technical detail but lands as a business one. It determines whether you need extra recorder licensing, whether you can serve the viewer counts you promised, and what the per-site build actually costs. (The companion technical piece walks where to tap the stream and why; the business point is only that the tap is a constraint with a price, not a given.)

And wherever you tap it, the stream still has to leave the building — which is the cost line nobody puts on a cloud quote.

The cost cloud hides: getting video out of the site

"Cloud means no hardware" is the most expensive half-truth in surveillance. The NVR sits behind the site's firewall on a private network; the cloud cannot simply reach in and pull from it. So every cloud surveillance deployment installs something on-site to push the video out — a bridge or connector appliance — and every camera-hour you actually watch remotely burns egress bandwidth. You did not remove hardware; you swapped a recorder you own for a connector box you rent, plus a monthly data bill.

The size of that bill turns entirely on one decision: do you stream continuously to the cloud, or only on demand? The math is unforgiving. A single 1080p camera at roughly 2 Mbps, streamed continuously, moves about 648 GB per month; at commodity cloud egress near $0.09 per GB, that is around $58 per camera every month — before storage, before viewing. Multiply by 200 cameras and continuous cloud streaming is a five-figure monthly line by itself. This is precisely why serious designs record locally and stream live only when a human is actually watching: the same camera viewed for an hour a day, on its low-bitrate sub-stream, costs a small fraction of that. On-demand viewing is not a feature; it is the difference between a viable unit economic and an absurd one.

Put the sunk stack, the tap constraint, and the egress reality together, and the decision stops being a religious "cloud versus on-prem" argument and becomes a portfolio call.

Making the call: augment first, migrate deliberately

For the large majority of real estates, the rational path is to augment first: leave the NVRs recording, add a live-video layer that taps the existing streams sensibly, keep viewing on-demand to control egress, and preserve the CapEx and the compliance posture you already paid for. Then migrate deliberately — as cameras age out and are replaced, buy cloud-native or standardise them, so the estate modernises over years without a forklift and without a write-off.

Rip-and-replace earns its cost in the narrow cases where the estate is truly end-of-life, where a regulator's residency demand cannot be met by the current setup, or where the incumbent vendor's lock-in has become more expensive than the replacement. Outside those, replacing a working recorder to add a browser tab is solving a small problem with a large invoice. Name which situation you are actually in, and the spend picks itself.

How you source the cloud video surveillance layer

Once you have decided to augment, the live layer itself is build, buy, or deploy — and the choice mirrors the same ownership question.

Build on open source. Media servers that ingest RTSP and convert it for the browser get you a working live view for no license fee. You own the operational reality: NAT traversal out of each site, scaling, the recorder-coexistence logic, and the on-call. Right when live video is core to your product and you have the engineers.

Buy a cloud VSaaS. Fastest to live, least to operate — but your feeds route through a third party's cloud, you inherit their egress and per-stream pricing, and residency is theirs to define. Right when speed outweighs owning the path.

Deploy a platform you run. The live-video stack delivered as something you run on your own infrastructure or a managed cloud deployment, under a flat license, so the feeds and the egress stay inside infrastructure you control. Samvyo is one such option — based on SFU architecture, deployed on-premise or on your chosen cloud, embeddable under your own brand. It fits when data residency or flat, predictable cost at scale matters. Where it does not: a handful of cameras with no residency pressure, where a media server or a hosted relay is simpler and cheaper.

Three sourcing paths, one axis — how much of the live-video layer you want to own versus rent.

The Bottom Line

You are never greenfield. The recorder in the closet, the sunk camera CapEx, the regulator-approved retention, the trained operators — all of it is already there, and the cost that decides your project is not the cloud subscription. It is the integration on top of the incumbent and the egress of getting video out of the site. Augmenting an existing NVR estate almost always beats replacing it, because it preserves the capital and the compliance you already own and adds only the thin live layer you were missing. Cloud video surveillance done well is not a rip-out. It is a layer — priced honestly, tapped carefully, and viewed on demand.

What's Next?

Want the engineering-level version — exactly where to tap the stream, how to coexist with a recorder that already holds the camera, and the connection limits that shape it? The companion technical deep-dive walks the coexistence architecture for the team that has to build it: link to technical companion

Frequently Asked Questions

Do I have to replace my NVR to get cloud or browser-based live view?

No. In most deployments the right move is to augment — leave the NVR recording and add a live-video layer that taps the existing camera or NVR streams. Replacing the recorder writes off working hardware and resets a compliance setup that was already signed off; it is justified only when the estate is end-of-life or the incumbent vendor can't be integrated with.

What does it actually cost to add cloud video to existing CCTV?

The subscription is rarely the main cost. The real lines are the on-site bridge or connector hardware per location, the egress bandwidth of streaming video out of each site, and the integration work of coexisting with the recorder that already holds the camera. Priced honestly, those three — not the cloud licence — decide the project.

Is cloud CCTV cheaper than an on-premise NVR?

It depends on how you view. Streamed continuously to the cloud, a single 1080p camera can run tens of dollars a month in egress alone, so at scale continuous cloud streaming is more expensive than local recording. Recording locally and streaming live only on demand — the sensible pattern — keeps cloud costs low. The cost model, not the word "cloud," decides which is cheaper.

Can I keep my existing cameras when moving to cloud video?

Almost always, yes. A well-designed live-video layer works on top of the ONVIF/RTSP cameras and recorders you already run, so you rarely need to replace hardware to add live browser or mobile view. Replacing cameras is a gradual, age-out decision — not a prerequisite for going live.

What's the difference between rip-and-replace and augmenting a surveillance system?

Rip-and-replace retires the NVRs and moves everything to a new (usually cloud) platform — clean architecture, high cost and disruption. Augmenting keeps the recorders doing their job and adds a live-video layer beside them — lower cost, preserves CapEx and compliance. Augmenting is the default; replacement is for end-of-life estates or dead-end vendors.

Can a platform like Samvyo coexist with an existing NVR estate?

That is the augment case it is built for. Based on SFU architecture and deployed on-premise or as a managed cloud deployment, a platform like Samvyo can add the live browser/mobile layer on top of existing ONVIF/RTSP cameras and recorders, keeping feeds and egress inside infrastructure you control under a flat license. For a small, residency-free deployment it may be more than you need; for a large estate where control and predictable cost matter, it fits the coexistence model rather than forcing a rip-out.