What is vendor lock-in and how do you measure it before signing?

Vendor lock-in is the cost of leaving a supplier: how much it costs, in time, money and risk, to stop using them and switch to an alternative. It is not a moral failing of the vendor, it is an almost unavoidable consequence of every technology choice: the more a system is woven into business processes, the more it costs to unwind. Its concrete forms are five: data saved in proprietary formats no other system reads without conversion, business logic embedded in non-exportable configurations (workflows, rules, automations built only inside that platform), team skills concentrated on a single tool, multi-year contracts and licenses with exit penalties, and hand-built integrations nobody documented. The operational point is that lock-in is measured before signing, when negotiating leverage is highest, not after, when the vendor knows staying costs less than leaving.

Beyond the cloud: line-of-business software, vertical SaaS and AI models

Italy's public debate on lock-in has focused almost entirely on cloud, pushed by the anti-hyperscaler messaging of European providers selling their own alternative. But the most expensive lock-in for an Italian SME is rarely cloud: it is the business management suite (TeamSystem, Zucchetti, Panthera ERP among the most common in Italy) holding twenty years of records in a format only it exports, the ERP (JD Edwards, SAP S/4HANA, Infor CloudSuite) configured by a consultant who no longer works there, the CRM (Salesforce, Dynamics, Vtenext, Zoho CRM) or vertical SaaS platform (order management, quality control) that promises full integration and asks for exclusivity on operational data in return. It is the same mechanism as cloud repatriation, applied to tools nobody thinks to evaluate with the same rigor because "it has always been that way". The newest form, and the one weighing most on technical decisions in 2026, is lock-in to AI models: prompts optimized for a specific model, fine-tuning done on a single provider's data and infrastructure, agentic workflows calling proprietary APIs with no abstraction layer. Switching models, in these cases, often means rewriting.

Enterprise example and how to reduce it

A typical case: a manufacturing company migrates its ERP and discovers that bills of materials, planning logic and reorder rules live in undocumented custom fields, exportable only in a proprietary format. The migration, estimated at three months, takes twelve. The lock-in was not in the contract, it was in the configuration. Reducing it does not mean avoiding every vendor, sometimes lock-in is an acceptable trade-off for speed: it means designing the exit at the start, not at the end. In practice: prefer open formats and standards where they exist (see open table formats for analytical data), verify data portability with a real export-and-load test before signing, not a vendor promise, document every custom integration and configuration as if another team had to read it in three years, and favor architectures that preserve optionality, such as multi-cloud for infrastructure or a model router for AI. Lock-in is negotiated when you sign, not when you want to leave.