Show Notes
Why Vendor Lock-In Starts at Procurement
In this episode of Built, Wired & Secured, Alex Morgan and Michael Harrington break down a problem that usually does not show up until it is expensive: buying building technology that looks functional on day one but becomes difficult, costly, or operationally risky to exit later. The episode opens with a familiar scenario: a report export button lights up, but nothing happens. The vendor can help, but only with more time, more budget, and more downtime. That moment sets the tone for a practical conversation about portability, ownership, and operational resilience.
The central idea is simple: procurement decisions create long-term operating conditions. If portability is not part of the buying criteria, organizations can end up trapped in proprietary systems that make reporting, troubleshooting, analytics changes, and future migrations harder than they should be. For property teams and operators, that does not stay abstract for long. It turns into tenant complaints, billing delays, emergency consulting costs, and budget pressure.
The Real-World Cost of Poor Portability
Michael frames the issue through operations rather than theory. His first question is, “What breaks if this goes down?” That one question helps expose the difference between a convenient software feature and a business-critical dependency.
- If telemetry and tenant billing live inside a locked platform, you may lose fast access to your own historical data.
- If reporting becomes dependent on custom vendor work, invoicing and troubleshooting both slow down.
- If engineering and support teams have to create workarounds, labor costs rise fast.
- If tenant-facing services are affected, complaints and credit requests can follow.
The episode makes the point clearly: vendor lock-in is not just an IT inconvenience. It can become a cascading operational problem across finance, facilities, engineering, and tenant experience.
Procurement Signals That Reveal Portability Risk
The first major segment focuses on procurement signals listeners can use before they sign. Rather than turning the discussion into vendor bashing or legal drafting, the conversation stays focused on practical questions that expose risk early.
One of the first red flags is vague data ownership and handback language. If a proposal says exports are available “upon request” but does not explain format, timing, or process, that ambiguity should be treated as risk. The better question is specific: what export formats are supported, and how quickly can a full data snapshot be provided?
The episode also highlights API access as a major differentiator. If an API is described as “coming soon,” “partner only,” or undocumented, that is a warning sign. Listeners are encouraged to ask for a sample API endpoint that returns a device list or a sample response during the proposal phase. The point is not to demand everything. It is to verify that a usable interface actually exists.
Other procurement signals include:
- Whether the system has clear on-premises or offline behavior when cloud connectivity is lost
- Whether the vendor can explain what stays local versus what depends on the cloud
- Whether service boundaries are clearly documented, including what the vendor maintains and what the owner must support
- Whether a contingency runbook or high-level failure flow is available during procurement
These are practical, operations-friendly questions that can be used in RFPs, proposal reviews, and acceptance planning.
Acceptance Tests You Can Actually Run
A strong part of the episode is its focus on acceptance tests that are simple, repeatable, and easy to understand in a meeting. Michael shares several checks that have saved time in the field.
The first is straightforward: export a 30-day snapshot to CSV or JSON during acceptance, then import it into a neutral tool such as a spreadsheet or open-source viewer. If key fields like device IDs, timestamps, and event types do not carry over cleanly, the export may not be operationally useful.
The second test is to verify that a documented API endpoint returns a device list and schema. Instead of relying on a demo inside an admin interface, the vendor should be able to show a live call and expose stable identifiers and metadata.
The third is to require a documented handback format that explains fields, units, time zones, and any transformation rules. The episode stresses that this can be handled as a technical appendix rather than legal language.
One especially useful test is a simulated cloud-loss exercise. Listeners are encouraged to ask what happens when vendor connectivity is unavailable for an hour. What data buffers locally? What functionality continues? How is buffered data recovered? If the vendor cannot demonstrate this, hidden operational risk may still exist.
Staged Exit Planning and Budgeted Optionality
The episode does not stop at procurement. It also lays out a staged migration and rollback approach that can reduce future disruption. The recommended workflow begins with a baseline snapshot stored in an immutable archive with version information. From there, teams can run a new system in parallel, watch for schema drift and timestamp mismatches, and use the baseline to reconcile or roll back if needed.
That parallel window matters. Michael argues that budgeting for optionality upfront is cheaper than emergency rip-and-replace later. The key is to keep that optionality modular and time-boxed. Instead of paying indefinitely for a vague premium portability package, organizations can require concrete deliverables at milestone gates, including exports, API samples, and handback documentation.
Examples That Bring the Lesson Home
The episode closes the loop with two anonymized examples. In one lighting-controls rollout, the presence of CSV exports and a public API made a later analytics migration relatively simple. Consistent device IDs and timestamps reduced the work to a few days of mapping and avoided downtime.
In a harder case, a proprietary access-control system used identifiers only the vendor could interpret. Exports existed, but the data was unreadable without vendor tooling, and every export carried a charge. What should have been a normal migration became a rushed forensic project with extra rework.
The lesson is clear: readable exports and documented schemas are not nice-to-haves. They directly affect time, cost, and operational control later.
Three Immediate Actions
Before signing anything, this episode recommends three immediate moves:
- Add export and API acceptance tests to the RFP or purchase order and require a live demo.
- Require a documented handback appendix as an acceptance deliverable.
- Budget and schedule both a parallel run and a failover simulation during commissioning.
It all comes back to one grounding question: what breaks if this goes down? Asked early enough, that question can keep procurement focused on tenant impact, business continuity, and long-term flexibility instead of feature lists alone.
The episode also points listeners to a downloadable Vendor Exit Checklist at builtwiredsecured.com/exit-checklist.
Buying for the Exit Starts Long Before the Exit
Most organizations do not realize they have bought into vendor lock-in until they need something simple and cannot get it without delay, cost, or disruption. In this episode of Built, Wired & Secured, Alex Morgan and Michael Harrington take that problem out of the abstract and put it where it belongs: inside day-to-day operations. The conversation starts with a tense but familiar moment. A user clicks an export button, sees it respond, and still gets nowhere. Reports are needed. Tenants are waiting. The vendor can help, but only through a custom effort measured in months, budget, and downtime.
That scenario captures the core message of the episode. Procurement decisions are not just purchasing events. They shape how flexible, portable, and supportable a system will be over its full life cycle. If organizations buy only for installation and initial functionality, they can create long-term constraints that become expensive to unwind.
This matters especially in building technology, where systems often touch reporting, telemetry, billing, tenant experience, local operations, and cloud services all at once. When portability is weak, the result is not just technical inconvenience. It is operational drag.
What Vendor Lock-In Looks Like in Practice
Michael Harrington brings the issue down to a practical level with one question: what breaks if this goes down? That framing matters because it moves the conversation away from feature comparisons and toward business continuity.
When historical building data is trapped in a proprietary workflow, several things can break at once. Billing can slow down because teams cannot access the records they need. Trend analysis becomes harder because historical context is delayed or incomplete. Engineering and support teams end up doing manual work to bridge the gaps. That extra effort creates cost internally before anyone even sees an invoice from the vendor. Then tenant complaints begin, credit requests follow, and emergency budgets appear to fund consultants or workaround projects.
The episode repeatedly returns to the idea of a cascade. A locked system does not usually fail in a single dramatic way. It creates a chain reaction across operations, finance, and service delivery.
Procurement Signals That Should Trigger More Questions
One of the strongest parts of the episode is how clearly it explains what to ask before a deal is signed. Instead of relying on broad warnings, Alex and Michael focus on procurement signals that reveal portability risk early.
The first signal is vague handback language. If a proposal says exports are available “upon request” but does not define format, timeline, or scope, that is not reassurance. It is ambiguity. The right follow-up is specific: what export formats are supported, and how quickly can the organization receive a full data snapshot?
That specificity matters. CSV, JSON, or another documented schema can be evaluated. A vague promise cannot. Operations teams need to know whether they can get data in a readable form and whether the turnaround is measured in hours, days, or custom project timelines.
The next signal is API accessibility. If a platform depends on an API that is undocumented, restricted to partners, or always described as “coming soon,” the organization may be buying into a closed environment. The episode suggests an excellent test during procurement: ask for a sample documented API endpoint that returns a device list or sample response. That request is not invasive, and it is easy for a vendor with a mature platform to satisfy.
Cloud dependence is another key area. If a solution is cloud only, buyers need to understand what happens locally when connectivity is interrupted. What functions continue? What data buffers? How is recovery handled? In building operations, survivability cannot be treated as an afterthought.
Finally, the episode emphasizes service boundaries. If responsibility is unclear, assumptions will be made later, often at the customer’s expense. Teams should ask exactly what the vendor supports and what the owner is expected to maintain.
Acceptance Tests That Translate Well From Paper to Reality
Many procurement conversations sound good until acceptance time. That is why the episode spends so much time on demonstrable tests. These are not theoretical controls. They are practical checks listeners can run or request during implementation.
The first recommended test is to export a 30-day snapshot of production data into CSV or JSON and import it into a neutral tool. That could be an open-source viewer or even a spreadsheet. The goal is to confirm that key fields survive the trip intact, including device identifiers, timestamps, and event types. If the data only becomes meaningful inside the vendor’s own viewer, portability is already compromised.
The second test is API validation. Instead of trusting screenshots or administration panels, the vendor should be able to make a live call and show the response structure. Stable identifiers and useful metadata should be present. If the only path to basic data visibility is a graphical interface controlled by the vendor, the organization has less freedom than it may realize.
The third test is documentation of the handback itself. The episode recommends a technical appendix that spells out fields, units, time zones, and transformation logic. That is not legal drafting. It is operational clarity.
Perhaps the most valuable test is the simulated loss of vendor cloud connectivity. Buyers should ask vendors to show what happens when the cloud is unreachable for a period of time. What continues to function? What stops? What is buffered? How is data recovered afterward? A demonstration here can reveal whether the system is resilient or brittle.
Why Staged Migration Beats Emergency Replacement
The conversation then moves from procurement into life-cycle planning. Planning for exit does not mean planning for failure. It means recognizing that systems change, vendors change, analytics tools change, and ownership requirements change.
The staged approach outlined in the episode is practical. Start with a baseline snapshot and store it in an immutable archive with version information. Then run the new environment in parallel for a period. During that time, teams can watch for schema drift, timestamp mismatches, or identifier changes. If problems appear, the baseline makes rollback and reconciliation possible.
This approach costs something upfront, but the episode argues persuasively that it is far cheaper than a rushed migration or rip-and-replace project later. Budgeted optionality is the phrase that matters here. Organizations do not need to overbuy premium flexibility forever. They do need to secure concrete exit-enabling deliverables at the right milestones.
That includes export capability, API visibility, and documented handback formats as acceptance deliverables. If deeper portability work is needed later, it can be procured when the need is real.
Ownership After Go-Live Depends on Documentation
Another important takeaway is that system ownership does not happen automatically at handover. Michael argues for documentation that is versioned and searchable rather than buried in a single large PDF. Useful handover material should include configuration exports, API examples, runbooks for common tasks, and clear ownership mapping. He also recommends knowledge transfer sessions with recordings so the day-to-day team can actually operate the environment.
This is where vendor lock-in often quietly persists. Even if exports exist and APIs are documented, poor handover can leave the customer dependent on the vendor in practice. Real ownership requires usable operational knowledge, not just access rights.
Two Examples That Show the Difference
The episode gives two anonymized examples that make the stakes tangible. In one case, a lighting-controls deployment included CSV exports and a public API from the beginning. When it was time to switch analytics vendors six months later, the transition mainly involved mapping consistent device IDs and timestamps. The migration took days, not weeks, and did not create downtime for tenants.
In the other example, a proprietary access-control system relied on identifiers that only the vendor could interpret. Exporting was technically possible, but the data was unreadable without vendor tooling, and each export carried a cost. What should have been a manageable migration became a rushed forensic effort with rework and avoidable expense.
The contrast is sharp. Readable data and documented schemas create options. Opaque exports and undocumented identifiers create dependence.
Three Immediate Actions to Take Before Signing
The episode ends with three direct actions listeners can apply right away:
- Add export and API acceptance tests to the RFP or purchase order, and require a live demonstration.
- Require a documented handback appendix as an acceptance deliverable.
- Budget and schedule both a parallel run and a failover simulation during commissioning.
There is also a practical, contract-neutral acceptance criterion shared in the episode: require a documented data handback specification, a reproducible export of 30 days of production data in JSON or CSV within five business days of request, a sample API endpoint that returns device identifiers and metadata during acceptance, and a demonstration of offline behavior under simulated cloud loss.
That phrasing stands out because it is measurable. It avoids abstract promises and focuses on deliverables that can be demonstrated and verified.
The Bigger Lesson
The most useful question in the episode is also the simplest: what breaks if this goes down? Asked early, it keeps the conversation tied to tenant impact, operational continuity, and future flexibility. Asked too late, it becomes a budget problem.
Buying for the exit does not mean assuming a system will fail. It means making sure the organization can retain control of its data, preserve continuity, and change tools without starting from scratch. That is a more durable way to buy technology, and it is one of the clearest themes in this episode.
To hear the full discussion and download the Vendor Exit Checklist mentioned in the episode, listen at Built, Wired & Secured and visit builtwiredsecured.com/exit-checklist.