A Tier-1 automotive parts supplier running 6 vision-inspected production lines — 11,520 units per day, more than 8,000 active part variants — has more invested in its vision platform than the hardware replacement cost suggests. The inspection configurations covering those 8,000 variants represent significant accumulated engineering work: rules sets, training datasets, boundary sample libraries, and validated acceptance thresholds. When that supplier evaluates moving to a different platform after the first contract term, the cost conversation almost always starts with hardware and licenses, and almost always underestimates recipe migration, training data portability, and the validation downtime required to re-establish inspection confidence on a new system at line speed.
Switching costs are not set at renewal. They are set in the pilot contract. By the time a renewal is underway, the leverage belongs to the incumbent vendor. The engineering work is done, the data is on their infrastructure, the recipes are in their format, and the production team does not want to schedule re-validation downtime. The pilot stage is the only moment when the customer has equal leverage to negotiate the terms that determine future switching cost.
This post covers what switching costs actually include, how they are created contractually, and a checklist of the terms that most buyers fail to negotiate before the cameras arrive.
The four components of vision platform switching cost
Switching costs in production vision deployments come from four sources. Only the first is consistently visible at procurement.
Hardware replacement cost
Many traditional vision platforms bundle cameras, processing units, and software licenses as a single purchase. The camera hardware runs the vendor's firmware. Third-party software cannot access the raw sensor data stream. When the software license is not renewed — or when the customer wants to migrate to a different platform — the existing camera hardware may be unusable for non-proprietary inspection without a firmware modification that voids the warranty. On a 6-line deployment, hardware replacement cost multiplied by line count plus installation downtime is the component buyers price when evaluating a switch. It is the smallest component.
Inspection program portability cost
Vision inspection programs written in a proprietary format cannot be migrated to a different platform without full reconstruction. The engineering time embedded in a complex configuration for a high-variability part — rules sets for dimensional checks, trained models stored in platform-specific containers, spatial logic that took months to calibrate — does not transfer. A rules-set written in a platform-specific scripting language must be rewritten from scratch on any alternative. A trained model stored in a proprietary container may not export in a standard format (ONNX, TensorRT) without vendor permission. Buyers who have invested several engineer-years in program development rarely price this accurately at renewal because the comparison is between a one-time reconstruction cost they know will be disruptive and a renewal fee they have already absorbed into the operating model.
Training data ownership and re-labeling cost
In learning-first platforms, the inspection models are trained on labeled images. Those images were typically labeled using the vendor's annotation tool and stored on the vendor's infrastructure. In contracts that do not specify otherwise, the default position in many vendor agreements is that the trained model weights are the vendor's intellectual property (they ran the training compute) and the annotation data is generated by the vendor's tool (which the customer licensed, not owned). A customer migrating to a new platform may find that their 40,000 labeled training images are exportable only in the vendor's proprietary annotation format, not in COCO or a similarly portable standard. Re-labeling from scratch on a new platform's toolchain is a cost that falls entirely on the customer.
Exit fee and termination liability
Some proprietary vision contracts include per-camera or per-line exit fees triggered by contract termination before the agreed term. Others include provisions for license fees that continue for a specified period post-termination. These provisions are rarely discussed during initial procurement and are most commonly discovered during the first renewal negotiation, when they function as a floor on the renewal price: renew at the vendor's proposed rate or pay the exit fee to leave.
When these costs are determined
The structure of all four switching cost components is established in the pilot contract. This is the critical timing point: once the pilot ends, the cameras are installed, the training data is accumulated on the vendor's infrastructure, and the engineering work has been done in the vendor's format. Every term that governs future switching cost is now a change to an existing contract, which is always harder than negotiating a new one.
At the pilot stage, the vendor needs the pilot to succeed. The cameras are not installed. The training data does not exist. The engineering work has not started. This is the moment when the customer can negotiate:
- Training data export format and ownership
- Model weight portability at contract end
- Camera hardware ownership versus license
- Inspection program format and the customer's right to export and use it
- Exit fee terms, or the explicit absence of them
- Data retention and deletion obligations on vendor infrastructure after contract termination
After go-live, none of these terms are easily renegotiated without triggering the exit provisions the vendor controls. The pilot contract is the exit plan.
The exit checklist: what to negotiate before cameras arrive
This checklist identifies the contractual terms most likely to create switching costs if left unaddressed at the pilot stage. Not every term will be negotiable with every vendor. Understanding which terms are absent from the proposed contract is more useful than reviewing the terms that are present.
Training data and model portability
- All training images are owned by the customer and exportable in a standard format (PNG or JPEG with JSON annotation, COCO format, or equivalent) at any time during and after the contract
- Trained model weights are exportable in a standard format (ONNX, TensorRT, or equivalent) at contract end, without additional license fee
- Annotation work performed by the vendor on customer-provided images produces customer-owned annotation files
- The vendor's labeling tool exports are not restricted to vendor-specific formats
- No vendor intellectual property claim applies to models trained on the customer's part images using the customer's defect definitions
Camera hardware
- Camera hardware is owned by the customer outright, not licensed per-use or per-period
- Camera firmware can be modified or replaced by the customer or a third party at contract end, without vendor authorization required
- Camera hardware supports third-party vision software access via open protocols (GigE Vision, USB3 Vision, ONVIF, or open RTSP stream)
- No hardware deactivation clause tied to software license termination
Inspection program and recipe portability
- Inspection programs, rules sets, or model configurations are documented in a format sufficient for third-party reconstruction, not stored only in a vendor-proprietary container
- The customer has the right to export and retain inspection program documentation at any time during and after the contract
- No vendor intellectual property claim applies to inspection logic developed for the customer's parts using the customer's defect and tolerance specifications
Exit fee and termination terms
- No per-line or per-camera exit fee applies at contract termination
- If exit fees exist: the maximum is disclosed in writing at contract signing and capped as a defined percentage of first-year contract value
- Contract termination does not trigger automatic data deletion before the customer has had adequate opportunity to complete a data export (minimum 30 calendar days)
- Post-termination license fees, if any, are capped in duration and disclosed at signing
Data residency and storage
- All training images, model versions, and inspection logs are stored in a jurisdiction acceptable to the customer (relevant for Malaysia PDPA and Singapore PDPA compliance on cross-border data transfer)
- The customer can request a complete data export at any time, not only at contract end
- The vendor's data retention policy and deletion schedule after contract termination are disclosed and agreed in writing before contract signing
Note on SG/MY data residency: Under Malaysia's Personal Data Protection Act 2010, personal data — which includes images of identifiable workers captured by inspection or safety cameras — may not be transferred outside Malaysia to countries that do not have comparable data protection standards without the data subject's consent or a written transfer agreement. Singapore's PDPA has a parallel cross-border transfer obligation under Part IX. If a vision platform's training images or inspection logs are stored on infrastructure outside the region (common for US and EU-headquartered vendors using global cloud providers), the customer may be in technical breach of PDPA transfer restrictions if those images include identifiable individuals. This is rarely discussed in vision system procurement because the buyer typically focuses on the technical images of parts rather than on incidental worker images captured in the camera field of view — but on a production floor where operators handle parts in frame, the incidental capture is common. Confirming the storage jurisdiction and the vendor's PDPA transfer compliance posture is a due-diligence step, not a theoretical one, for MY and SG customers.
How to use the checklist at the term sheet stage
The checklist is most effective when raised at the term sheet stage, before the pilot contract is finalized. Asking these questions at this stage signals that the customer has evaluated the exit scenario. Vendors who have nothing to hide on these points will answer them directly and quickly; the absence of defensiveness is itself informative.
Terms that a vendor declines to address before cameras are installed are data about the switching cost structure that vendor intends to create. A vendor who says training data ownership is "a legal question for the final contract" at term sheet stage will not become more forthcoming once the training dataset exists on their infrastructure.
Scaling from pilot to fleet: how switching costs compound
A single-line pilot with 3 cameras and a single part family has switching costs that are manageable. The pilot was exploratory; the training data is limited; the engineering investment is small. This is often the scenario when buyers feel comfortable with the contract terms on offer — the cost of being wrong is low.
The cost structure changes significantly when the same contract terms govern a fleet expansion. A Tier-1 supplier expanding from a pilot line to 6 lines carries those contract terms across the expanded deployment. Training data accumulates on the vendor's infrastructure across all 6 lines, across all 8,000+ variants. Inspection configurations become progressively more complex. The engineering investment grows with each month of production. By the time a renewal is under negotiation, the volume of data and configuration work on the vendor's infrastructure makes the exit cost analysis almost always favor renewal, regardless of the renewal price.
The leverage asymmetry between pilot and fleet is the reason the exit checklist belongs in the pilot contract, not in the fleet expansion agreement. The pilot terms set the template. Renegotiating at fleet expansion is possible but harder; renegotiating at renewal is harder still.
For context on how architecture type affects the portability of inspection configurations specifically, the rules-first vs learning-first architecture post covers why certain architecture choices compound migration costs more than others: rules-first programs written in proprietary formats have different portability characteristics than learning-first models stored in open-standard containers. For an overview of HyperQ AI Vision's open-format deployment approach, the product page covers data ownership and export terms.
What a vendor's response to the checklist tells you
Most buyers who have used this checklist report that the vendor's response is itself more informative than the written contract terms. A vendor who receives the checklist at the term sheet stage and responds within a week with clear positions on training data ownership, model portability, and exit fee terms is signaling that their platform is designed for customers who will occasionally leave. A vendor who deflects, routes the questions to a legal review queue, or says these terms are "standard and non-negotiable" before the customer has engaged legal review is signaling the opposite.
This is not about adversarial procurement. It is about information quality. The switching cost terms in a vision platform contract are not complex — they involve maybe eight to twelve specific provisions across the five categories in the checklist above. A vendor with nothing to hide responds to them quickly because the answers are simple. A vendor whose revenue model depends on lock-in takes longer because every clear answer on those terms costs them money at future renewals.
Neither response type is a reason to walk away automatically. There are market-leading platforms with significant switching costs that are still the right choice for specific applications — the performance on the application matters, and the switching costs are a known quantity to be priced into the total cost of ownership calculation. What the response tells you is whether the total cost of ownership calculation you are running reflects the contract terms the vendor is offering, or the terms you assumed they were offering.
The honest case for staying
Not every switching cost analysis should produce a recommendation to switch. There are situations where the cost of migration exceeds the expected benefit of the alternative platform.
Large labeled training datasets. If a vendor holds a substantial labeled image dataset accumulated under the existing contract, and that dataset cannot be exported cleanly in a standard format, the cost of re-labeling from scratch on a new platform is significant. For defect classes with low base rates — where building an adequate training set requires months of production volume — this is a real constraint, not a theoretical one.
Inspection programs with complex spatial logic. If an existing configuration contains multi-step spatial logic, measurement sequences, or decision trees developed over years, and that logic is documented only in the vendor's proprietary format, the migration cost is the cost of reconstructing it from scratch. Engineering time is finite; reconstruction competes with ongoing quality development work.
Stable inspection performance. If the existing platform has reached a stable false-reject rate and escape rate that the production team depends on, the risk of disrupting that stability during a re-validation period is a real switching cost that belongs in the migration analysis. Re-establishing inspection confidence at line speed on a new platform takes time. That time is not free.
The goal of the exit checklist is not to make switching easy — it is to ensure the decision to stay or switch is made on known costs rather than costs the vendor controls the disclosure of. A customer who negotiated good exit terms at the pilot stage can evaluate the renewal honestly. A customer who did not has already paid a switching cost before they decided whether to leave.
For more on defining the acceptance criteria that govern inspection performance claims — the specifications that determine whether "stable false-reject rate" means what you think it means — see the pilot acceptance criteria that survive procurement post.
Send us your current pilot or fleet contract — redacted to remove pricing — and we will return a written assessment of the switching cost terms within two weeks: which clauses create lock-in, which standard terms are absent, and which provisions are negotiable in the current market. No vendor engagement, no contract, and full confidentiality under NDA before we begin.