UniFi Protect ONVIF Cameras for MSPs: Keep Them or Replace Them?
UniFi Protect ONVIF camera support sounds like a gift for MSPs.
A client has a building full of working cameras. They want the cleaner UniFi Protect interface, maybe a new NVR, maybe Site Manager visibility, and definitely a smaller bill than a full rip-and-replace. Ubiquiti now talks more openly about expanded third-party camera support, including ONVIF audio and motion detection in Protect 7.1. Ubiquiti, Welcome to Protect 7.1
Great. Keep the cameras if they are worth keeping.
But do not confuse adoption with support ownership. UniFi Protect can make an existing-camera migration look easy enough to underquote. The MSP still has to verify firmware, PoE, credentials, streams, motion events, retention, bandwidth, client-owned access, and what happens when one old camera behaves like it was assembled during a thunderstorm.
For MSPs, the question is not, "Can UniFi Protect see the camera?" The question is, "Can we support this camera without donating labor for the next three years?"
Quick answer
UniFi Protect ONVIF cameras can be a good MSP migration path when existing third-party cameras are healthy, documented, and good enough for the client's actual security needs. They become a support trap when the client expects UniFi-native behavior from old cameras with messy credentials, weak firmware, bad streams, missing motion events, unclear retention, or no support owner.
Use ONVIF support to reduce waste. Do not use it to hide a weak scope.
What changed for UniFi Protect and third-party cameras
Ubiquiti's Protect 7.1 announcement says the release expands ONVIF support, including audio and motion detection, and frames the change around larger camera migrations. That matters because older Protect discussions often treated third-party cameras as a compromise: useful for basic video, weaker for everything that makes a modern camera system pleasant to operate.
The new direction is more MSP-friendly. A client can phase into Protect without replacing every working camera on day one. That can protect budget, reduce waste, and make the first project easier to approve.
It also creates a new sales problem.
A client hears "third-party camera support" and translates it into "all my cameras will work like UniFi cameras." Sometimes they will not. Some will stream fine but fail motion tests. Some will need vendor-specific settings. Some will work until someone changes a stream profile. Some will keep video but lose the features the client actually cares about, like clean event search or reliable audio.
That is not a reason to avoid ONVIF. It is a reason to scope it.
If the same client is also standardizing on UniFi Network, use the Meraki vs UniFi MSP decision guide to keep support ownership and five-year cost in the same conversation. If Site Manager is part of the operating model, keep the UniFi Fabrics guide for MSPs nearby. Better visibility does not make support free.
ONVIF support is compatibility, not a support promise
ONVIF is useful because it gives devices and video systems a shared language. It is not a warranty that every feature will behave the same in every recorder.
ONVIF says profiles make it easier to recognize how conformant devices and clients are compatible with one another. It also says conformance to profiles is the only way to ensure compatibility between ONVIF conformant products, and only registered products with profile conformance are considered ONVIF conformant. ONVIF Profiles
That line belongs in MSP discovery.
If a camera says "ONVIF" in a dusty admin page, verify what profile it supports and whether the product is actually registered. Profile S is the older basic video streaming profile. ONVIF describes it as covering video streaming and configuration, plus ONVIF specifications for PTZ control, audio in, multicasting, and relay outputs when conformant devices and clients support those features. ONVIF also notes that Profile S deprecation is in process, with the last date for product conformance submissions set for March 31, 2027. ONVIF Profile S
Profile T is the more relevant check for modern video features. ONVIF says Profile T supports H.264 and H.265 video, imaging settings, motion and tampering events, metadata streaming, PTZ control, HTTPS streaming, motion region configuration, relay outputs, and bidirectional audio where supported. ONVIF Profile T
That does not mean every Profile T camera will give Protect the exact same user experience as a UniFi camera. It means you have a better starting point for discovery.
The MSP should still test the actual model, firmware, stream, and feature set before promising a client-facing outcome.
The discovery checklist before you promise anything
Do not start with the NVR quote. Start with the camera inventory.
A clean UniFi Protect ONVIF migration assessment should capture:
- Camera model and firmware. Brand, model, current firmware, release age, known support status, and whether updates are still available.
- ONVIF profile and registration. Confirm Profile S, Profile T, or another relevant profile. If possible, check the product against ONVIF's conformant product directory.
- PoE and switch path. Current switch model, PoE budget, cable condition, VLAN, uplink, and whether the camera is on a network the NVR can reach.
- Credentials and owner. Admin account, ONVIF user, password owner, MFA or management portal rules, and who can approve a reset.
- Stream configuration. Resolution, frame rate, codec, primary stream, secondary stream, RTSP settings, and whether changes require removal and re-adoption in Protect.
- Motion and audio behavior. Whether the camera sends motion detections to Protect, whether audio works, and whether the client expects AI events.
- Retention and bandwidth. Days of recording required, recording mode, camera count, bitrate, uplink capacity, storage sizing, and WAN impact for remote review.
- Physical condition. Lens condition, mounting, focus, field of view, weather exposure, IR quality, and whether the camera still sees what the client thinks it sees.
- Support boundary. What the MSP will support after migration, what is billable, and when replacement becomes the recommendation.
That is not overkill. That is the difference between "we migrated your cameras" and "we inherited every weird camera problem from the last installer."
Keep, replace, or phase the camera estate
A third-party camera can be worth keeping. It can also be an anchor tied to your support desk.
Use a simple decision table before the client sees the quote.
| Camera condition | Recommendation | Why |
|---|---|---|
| Current firmware, Profile T, clean streams, working motion events, good image | Keep for phase one | The camera meets the job and avoids waste |
| Good image, basic stream works, weak events or no audio | Keep with documented limits | Fine for continuous recording, weaker for event workflow |
| Old firmware, unknown credentials, poor night image, bad mounting | Replace | The MSP will spend more supporting it than replacing it |
| Client-owned camera with vendor lock-in or unclear admin rights | Pause until ownership is fixed | You cannot support what nobody can administer |
| Critical entrance, cash area, loading dock, or compliance-sensitive zone | Test harder or replace | The risk is too high for "probably works" |
| Large camera estate with mixed models | Phase by site, risk, and budget | Replacing everything may be wasteful, but keeping everything may be worse |
The client-friendly version is simple: some cameras are assets, some are liabilities, and the MSP should not price them the same.
The gotchas that turn ONVIF into unpaid labor
The annoying parts are not theoretical. They show up in adoption, testing, and the first support month.
Motion events are not magic
Ubiquiti's third-party camera help article says motion detections must be configured on the camera and sent to Protect. That is the correct warning. It means the MSP cannot just adopt the camera and assume the event timeline will behave like a UniFi-native deployment. Ubiquiti Help Center, Third-Party Cameras in UniFi Protect
Test motion by camera model. Test after firmware updates. Test after stream changes. Test after the client asks why nothing was captured when a person walked across the lobby.
Also separate motion detection from AI detection. A camera sending motion events is not the same as Protect getting UniFi-native smart detections for people, vehicles, license plates, or package events. If the client expects AI-assisted search, say which cameras will and will not support that workflow.
Audio may work, but it is still a scope item
Protect 7.1 mentions expanded ONVIF support including audio. ONVIF Profile T covers bidirectional audio for conformant devices and clients that support it.
That phrase matters: where supported.
Audio can create legal, privacy, and client-policy questions. Some clients should not record it. Some cameras will only provide limited audio. Some sites need signage or policy review. Do not hide that inside "camera migration."
Stream changes can require rework
Ubiquiti's third-party camera guidance says streams are configured in the camera's own setup tool, and if streams are adjusted after adoption, the camera must be removed and re-added to Protect for the updates to appear.
That is not a tiny note. It changes support behavior.
If an MSP tunes resolution, codec, bitrate, or frame rate later, that may not be a live tweak inside Protect. It may be a remove-and-readd operation with downtime, validation, and client communication. Price that into post-migration tuning.
Credentials are usually worse than the camera
Camera credentials are where old sites go to embarrass everyone.
The password might be in a spreadsheet. It might belong to the client's former security vendor. It might be the default password from 2018. It might be tied to a personal email account nobody can access. It might work for web login but not ONVIF.
Ubiquiti's guidance calls out checking that ONVIF is enabled and the credentials are correct. It also calls out date and time settings as an adoption check. That is practical because camera auth, clock drift, and vendor-specific ONVIF settings can waste hours.
Put credential cleanup in the quote. If the client cannot produce admin access, the project is not ready.
Retention is not just disk size
A Protect migration can change recording expectations.
A client may currently retain seven days on a weak old NVR because nobody ever checked. After the migration, they may ask for 30 days, higher resolution, more cameras, remote viewing, and event review from multiple locations.
That changes storage and network math. Camera count, bitrate, recording mode, frame rate, retention target, and remote viewing all matter. So does whether the client wants continuous recording, motion-based recording, or a mix by camera.
If you are already quoting UniFi storage or backup-adjacent hardware for the same account, read the UniFi Drive vs Synology MSP guide. Cheap storage still needs a restore and retention conversation.
Thumbnails and event search shape the user experience
A camera can record video and still feel bad to use.
Event thumbnails, scrub speed, motion regions, audio playback, and search quality affect whether the client thinks the migration succeeded. MSPs should test the exact user workflow, not just the feed.
Ask the client what they actually do with the system:
- Do they review every morning's motion events?
- Do they search for vehicles or people?
- Do managers check cameras from phones?
- Do they export clips for insurance, HR, police, or operations?
- Do they need audio, or should audio be disabled?
A warehouse camera and a front-desk camera do not need the same feature set.
How MSPs should quote a UniFi Protect ONVIF migration
Quote the migration as a decision tree, not a camera count.
At minimum, separate these line items:
| Quote area | What it covers |
|---|---|
| Camera inventory | Model, firmware, ONVIF profile, admin access, physical condition, and current recording path |
| Network readiness | PoE budget, switch ports, VLANs, NVR reachability, uplinks, and remote access path |
| Test adoption | Pilot cameras by model group, verify stream, motion, audio, thumbnails, and user workflow |
| Retention design | Camera count, bitrate, recording mode, storage sizing, and retention target |
| Credential cleanup | Admin reset, ONVIF user creation, password storage, client approval, and offboarding notes |
| Replacement plan | Which cameras stay, which cameras go, which cameras wait for a later phase |
| Support handoff | What is included monthly, what becomes billable tuning, and when the answer is replacement |
This belongs in the scope of work, not in a private engineer note. If the project includes a broader network refresh, tie it into the MSP project scoping process so cabling, PoE, VLANs, firewall rules, and remote access are not discovered during cutover.
This is also where Scopable fits. Scopable helps MSPs turn camera findings into a client roadmap, budget, quote, approval trail, and project handoff. If one site has 18 cameras worth keeping and 9 that should be replaced, that should not live in a spreadsheet named final-final-camera-plan.xlsx.
Client language MSPs can use
Use plain language. The client does not need an ONVIF lecture.
For cameras worth keeping:
These cameras are healthy enough to keep in the first phase. We tested the stream and basic event workflow. They will not behave exactly like UniFi cameras, so the quote includes documented limits and a support boundary.
For cameras that need replacement:
These cameras may produce video, but they are not good support candidates. The firmware, image quality, credentials, or event behavior will cost more to support than replacement. We recommend replacing them during the migration.
For mixed sites:
We do not need to rip out every working camera. We do need to decide which cameras are worth supporting, which should be replaced now, and which should go into a later roadmap phase.
For clients focused only on price:
Keeping existing cameras can reduce project cost. It does not remove discovery, testing, retention design, credential cleanup, or support ownership.
That last sentence is the money.
When keeping third-party cameras is the right call
Keep the existing cameras when the client has a lot of good hardware, the current image quality is acceptable, the ONVIF profile is clear, credentials are documented, and the client understands the feature limits.
This is especially reasonable for lower-risk views: parking lot coverage, general hallways, storage areas, secondary entrances, or sites where continuous recording matters more than event intelligence.
It is also reasonable when budget is tight and the client accepts a phased roadmap. Replace critical cameras first. Keep acceptable cameras temporarily. Review the next phase during the QBR.
The key word is temporarily. Some retained cameras should have a retirement date.
When replacement is the better answer
Replace the camera when support risk beats hardware savings.
Common replacement triggers:
- No admin access or no clean way to reset ownership.
- Firmware is old, unsupported, or unsafe to leave exposed.
- The stream works only after vendor-specific fiddling.
- Motion events fail or cannot be tuned well enough.
- The camera's night image is bad.
- The camera is covering a high-risk area.
- The client expects AI search or clean event review.
- Cabling, PoE, mounting, or physical condition is suspect.
- The MSP team does not want to support that brand or model.
That last one is valid. MSP standards exist for a reason.
If you support every random camera forever, you do not have a standard. You have a museum with tickets.
The support owner needs a name
The most important line in the quote is not the NVR model. It is the support owner.
Who owns the camera after migration?
- The MSP?
- The client?
- The old security vendor?
- A manufacturer support desk?
- Nobody, until something breaks?
If the MSP owns it, price that ownership. Include monitoring expectations, firmware policy, password storage, event troubleshooting, stream tuning, replacement recommendations, and client user support.
If the client owns it, write that down. If an old security vendor owns it, get that in writing too. If nobody owns it, replace the camera or exclude it from the support promise.
This is the part clients miss because the camera still shows video. Video is not the same as a managed service.
Bottom line
UniFi Protect ONVIF camera support gives MSPs a practical middle path. You do not have to rip and replace every working camera just to move a client into Protect.
But the middle path needs adult supervision.
Inventory the cameras. Verify ONVIF profile and firmware. Test streams, motion, audio, thumbnails, retention, bandwidth, and the client review workflow. Name the support owner. Put replacement candidates into the roadmap. Price the work you actually own.
The bad quote says, "We can adopt your existing cameras."
The useful quote says, "Here are the cameras worth keeping, here are the ones that will become support debt, and here is what each choice costs."
If you want a cleaner way to turn discovery into budgets, approvals, quotes, and project handoff, get early access to Scopable. Camera migrations are exactly the kind of work that should not live in someone's memory.
