Vendor lock-in is the degree to which a system ties you to one supplier, so that switching away becomes costly, slow, or impractical. In surveillance it shows up as cameras that only work fully with one VMS, proprietary recording formats, a closed cloud you cannot extract your data from cleanly, or analytics that exist only inside one vendor's ecosystem. Some lock-in is unavoidable — every choice commits you to something — but its degree is a design decision, not a fact of nature.
It matters because surveillance systems live for many years, and the supplier's future behaviour is part of what you are buying. High lock-in hands the vendor leverage over your pricing, your upgrade timing, and your fate if they discontinue a product or fail; low lock-in keeps your options open to change cameras, move data, or swap platforms. Open standards (ONVIF), documented APIs, and standard export formats are the main tools that reduce it, which is why an open-platform VMS is partly a hedge against lock-in.
The pitfall is buying for today's features and ignoring tomorrow's exit. The deepest, most convenient integration — a vendor's full SDK, an all-in-one cloud platform — is often where lock-in is highest, and a low day-one price can hide expensive switching costs later (proprietary formats you cannot read elsewhere, data you cannot export, retraining and re-cabling to leave). Weigh capability against coupling deliberately, prefer open standards for the interchangeable baseline, reserve deep proprietary integration for where its value is worth the lock-in, and check the exit path — how you would get your cameras and data out — before you commit.
