Twitter
Google plus
Facebook
Vimeo
Pinterest

Q & A: A vendor upgrade broke our core integration. What now?

The question, from a security director at a multi-site utility:

“We funnel everything into our access-control platform to keep audit scope minimal. The integration that pushes video events from our VMS into that platform broke after we took the latest recommended upgrade. We’ve been without it for almost a year. The vendor says the integration is coming back. What do we do in the meantime, and what would you have done differently in the first place?”

The honest framing.

This isn’t a story about bad vendors. It’s a story of aggressively coupled integrations. Your video-to-access-control link was a single, tightly bound path: one VMS, one access platform, one integration that assumed both sides would move in lockstep. When the upstream vendor shipped an upgrade, it shifted the API underneath, and the partner who maintained the link couldn’t turn a working version around in advance because there was no warning. Because that one path was load-bearing for your system, a routine upgrade disabled a compliance-critical function for 12 months. The failure wasn’t the upgrade. It was that nothing stood between the upgrade and you.

The answer.

First, keep the audit trail alive while you wait. The video evidence still exists in the VMS, but it’s just not landing where your operators and auditors look. Bridge it by hand if you have to: scheduled video-event exports attached to the incident record, a thin integration layer that reads both APIs and writes events into the access platform in a format the audit accepts. Ugly, but defensible. And document the gap as a self-reported finding. Auditors can forgive “the vendor broke it on a recommended upgrade.” They won’t forgive “we didn’t notice for six months.”

Then the real fix, and it’s the answer to “what would you have done differently”: decouple. Route your events through a coordination layer instead of wiring the VMS directly to the access platform. When one side of the system changes, you reconfigure a single connector rather than lose all functionality.

Be realistic about what that means. Decoupling doesn’t make you immune. The upstream API is still changing; something on your side still needs to be updated. What changes is the potential damage to your system and the resulting cost. Instead of a potentially 12-month outage waiting on someone else, you get a discrete reconfiguration job. You’ll be updating one connector on your timeline. Decoupling contains the risk and caps the cost of fixing it. It does not erase the dependency, and anyone who tells you it does is selling something.

The Teldio angle.

Teldio Fabric is built to be that layer. It sits alongside your vendor-native integrations rather than replacing them, so when a native path breaks, the same VMS and access platform remain connected. That’s not a fix for the underlying integration. It’s the thing that turns “down for a year” into “reconfigured by Thursday.”