Facts, prices and regulatory dates in this article are as of 24 September 2026. INVISOM has no commercial relationship with any vendor named here, and nothing here is legal advice.
Lock-in is a price, not a principle
Every enterprise technology decision creates some dependence. The question is whether you knew its price when you signed.
In 2024, AT&T sued Broadcom in New York after Broadcom, which had acquired VMware, declined to extend support for AT&T's perpetual VMware licences on the terms AT&T believed it was owed. An email AT&T filed as evidence described Broadcom's proposal as a 1,050% annual price increase. AT&T said about 75,000 virtual machines depended on that support. In November 2024 the parties told the court they had reached a settlement in principle. Whatever the merits, the case shows the mechanism exactly: once a product is deeply embedded and the alternative is a multi-year migration, the vendor's pricing power is set by your exit cost, not by the market.
Regulators have reached the same conclusion about cloud. The UK Competition and Markets Authority's market investigation, which issued its final decision on 31 July 2025, found that competition in cloud services was not working well, and identified egress fees and software licensing practices among the barriers to switching and multi-cloud use. The EU Data Act goes further: from 12 January 2027, cloud providers serving EU customers may no longer charge for switching, including data egress for a switch.
Our thesis is that a vendor-neutral selection is one in which exit cost is measured, scored and contracted before the decision, with the same rigour as features and price. It does not mean refusing to commit to a platform, and it rarely means running two of everything. The method below is designed to make that measurable.
The method in seven steps
Most selection failures come from the order of work, not the scoring arithmetic. Teams watch demos before writing requirements, compare list prices before modelling usage, and negotiate contracts after the decision is effectively made.
Figure 1
Most selection failures come from the order of work
Seven steps, each with the output it must produce and the trap it avoids
- 1Requirements by capabilityOutput: Mandatory and scored requirementsTrap: Copying a vendor datasheet
- 2Long list from the capability mapOutput: Candidates incl. open source and regionalTrap: Shortlist set by who called first
- 3Weighted scorecard with evidenceOutput: Weights fixed before vendors are seenTrap: Scores based on demos alone
- 4Proof of concept on own dataOutput: Pass and fail results, cost meter, exit testTrap: Vendor-run tests on clean samples
- 5TCO with every invoiceOutput: Three-to-five-year cost under growthTrap: Comparing one invoice with another
- 6Price the exitOutput: Time and cost to leave in year threeTrap: Counting data volume only
- 7Contract terms and referencesOutput: Scored term sheet; independent referencesTrap: Negotiating after the decision
- Write requirements by capability, not by product. Describe what the business must be able to do ("serve governed metrics to BI and AI agents", "retain audit logs for seven years in-country") rather than features from a vendor's datasheet. Mark each as mandatory, important or nice to have.
- Build the long list from the capability map, including open source and regional providers, so the shortlist is not set by whoever called first.
- Score with a weighted scorecard and record the evidence for every score. A score backed only by a vendor claim should count for less than one demonstrated on your data.
- Run a proof of concept on your own data, designed to test the risky requirements, not the easy ones.
- Model total cost of ownership with every invoice, over at least three years, under realistic growth.
- Price the exit: what it would cost, in time and money, to leave in year three.
- Negotiate contract terms as scored criteria, then check references the vendor did not choose.
Weighted scorecards that resist the demo
A weighted scorecard is only as good as the evidence behind each number. INVISOM's practice is to grade evidence alongside the score: claimed (vendor statement), demonstrated (vendor demo or reference), or proven (shown on your data in the proof of concept). Claimed scores are capped, or discounted, until they are proven.
Figure 2Illustrative
The demo winner is often not the evidence winner
Worked example: weighted scores out of 5, with the evidence grade behind each score
- Capability fitWeight 25%Vendor A5DemonstratedVendor B4Demonstrated
- Performance on own dataWeight 20%Vendor A3ProvenVendor B4Proven
- Three-year TCO, all invoicesWeight 20%Vendor A2ProvenVendor B4Proven
- Exit cost and portabilityWeight 15%Vendor A2ProvenVendor B4Proven
- Security and residencyWeight 10%Vendor A4DemonstratedVendor B4Demonstrated
- Contract termsWeight 10%Vendor A3ClaimedVendor B3Claimed
After the demo
After own-data PoC, full TCO and exit cost
The illustrative example above shows the effect. Vendor A wins the demo with the strongest capability story. Once performance is measured on your workload, three-year cost includes every invoice, and exit cost is scored, Vendor B is ahead. This pattern is common, because demos are designed to show capability breadth, while cost and exit only become visible later.
Two rules keep scorecards honest. Fix the weights before you see any vendor, and record who set them. And separate mandatory requirements from scored ones: a vendor that fails a mandatory requirement, such as in-country hosting for regulated data, is out, regardless of its total.
Proof of concept on your own data
Vendor benchmarks are poor evidence for a specific decision. When Databricks and Snowflake disputed a TPC-DS result in November 2021, the two vendors published materially different numbers for the same benchmark within two weeks, as we describe in our Snowflake and Databricks analysis. The only reliable benchmark is your own workload.
A useful proof of concept has five properties:
- Your data, at realistic volume and messiness, including the awkward sources and access rules, not a cleaned sample.
- Pass and fail criteria written in advance, tied to the mandatory requirements and the highest-weighted scored ones.
- The same tests for every finalist, run by your team with vendor support, not by the vendor alone.
- A cost meter running throughout, so you see consumption, not just speed.
- An exit test: export the data, definitions and policies you created during the trial, and load them somewhere else. If that is hard after four weeks, it will be much harder after four years.
Total cost with every invoice
Most total cost of ownership comparisons are wrong because they compare one invoice with another, when each option produces several. A platform priced in credits or units may also generate a cloud provider bill for compute and storage, network charges, separate fees for AI features, and a marketplace commitment.
| Cost line | What to include | Commonly missed |
|---|---|---|
| Licence or subscription | List price, discounts, committed-spend terms | Price after the initial term |
| Consumption | Compute, storage, AI tokens or units at forecast growth | Idle and overprovisioned capacity |
| Underlying cloud | Infrastructure billed by the cloud provider, not the vendor | A second invoice under a separate commitment |
| Network | Cross-region and internet egress, private connectivity | Egress for analytics and AI traffic, not just migration |
| People | Platform engineers, administrators, training, hiring premiums | Upgrade and on-call effort |
| Migration in | Data, logic, testing, parallel running | Rebuilding security policies |
| Exit | Export, rebuild, dual running, retraining | Logic and policies, not just data |
The EU Data Act's switching rules and the major clouds' free egress for departing customers lower one exit line, but not most of them. AWS, for example, waives data transfer charges for customers moving off its platform, but customers must ask AWS Support and the waiver applies to data being moved out, not day-to-day traffic. The larger cost of leaving is rebuilding what sits on top of the data.
Exit cost and portability, layer by layer
Portability is not one property. It differs by layer, and the open standards that matter are different at each.
Figure 3
Data moves easily. Logic and policy are the real exit cost.
Portability by layer, the open standard that applies, and the question to ask each vendor
- Table dataPortableApache Iceberg, Parquet, open REST catalogsCan another engine read and write it today?
- AI tool and data integrationsPartly portableModel Context Protocol (Agentic AI Foundation)Are integrations built to MCP or a proprietary plug-in model?
- Metrics and semanticsPartly portableOpen Semantic Interchange (v1, January 2026)Can definitions be exported in an open specification?
- Pipelines and codePartly portableSQL, Spark, containersHow much is written in proprietary functions or services?
- Business logicHard to moveNo complete cross-engine standardHow many views, functions and procedures would need rewriting?
- Row and column security, auditHard to moveNo standard for consistent cross-engine enforcementWho rebuilds and re-certifies policies on exit?
Data is the most portable layer if it is stored in open formats. Apache Iceberg tables can now be read and written by multiple engines through open REST catalogs. Business logic and policies are the least portable. Snowflake's own engineers wrote in July 2026 that views, functions, metric definitions and row and column security have no complete, widely adopted cross-engine standard; the Open Semantic Interchange specification, finalized in January 2026, is an early attempt to address metrics. AI integrations are becoming more portable: the Model Context Protocol, which Anthropic donated to the Linux Foundation's new Agentic AI Foundation in December 2025 with OpenAI and Block as co-founders, gives a common way for agents to connect to tools and data. Integrations written to MCP are easier to move between AI vendors than integrations written to one vendor's proprietary plug-in model. Our architecture comparison covers the data layer in more depth.
Open source changes the exit calculation, but it does not remove it. Two recent cases show both sides:
- Foundation governance protects the project. In July 2026 Nscale agreed to acquire Anyscale, the company behind the Ray compute framework. Ray itself was not part of the deal, because Anyscale had moved it to the PyTorch Foundation in October 2025. Customers of the commercial service face a change of owner; users of the open project do not.
- Popularity does not guarantee maintenance. Ingress NGINX, one of the most widely used Kubernetes components, was retired in March 2026 because only one or two people were doing development work in their spare time. An open component without a healthy maintainer base carries its own exit cost.
So the useful question for any component, open or proprietary, is: who controls its roadmap and licence, how many organizations maintain it, and what would it cost to replace?
Contract terms are selection criteria
Contract terms are usually negotiated after the technical choice, when leverage is lowest. They belong in the scorecard.
Figure 4
Contract terms belong in the scorecard
Weak and strong positions on the clauses that decide future leverage
- Model trainingWeak: Policy page says customer data may improve the service; opt out on requestStrong: Contract bars training on inputs, outputs, telemetry and feedback; survives termination
- Price protectionWeak: Published rates may change on 30 days' noticeStrong: Rates fixed for the term; renewal increase capped; right to cut commitment if product changes
- Data exportWeak: Export available through support, format unspecifiedStrong: Self-service export of data, metadata and policies in open formats at no charge
- Exit assistanceWeak: Account closed at term endStrong: Defined assistance period with read-only access and parallel running
- Change of controlWeak: SilentStrong: Support and pricing terms continue; termination right if product is discontinued
- ResidencyWeak: Platform hosted in-regionStrong: Every feature, including AI processing, listed with its processing location
Data rights and model training. In May 2024, Slack faced public criticism when customers found that its privacy principles allowed customer data to be used to develop its own machine learning models unless a workspace owner opted out by emailing Slack. Slack said the models were not generative and that customer data was not used to train third-party large language models, and it clarified the wording. Some AI vendors now state the opposite default in their contracts: Anthropic's published commercial terms, for example, say it may not train models on customer content from its services. Whatever a vendor's policy page says, get the training restriction, its scope (inputs, outputs, telemetry, feedback) and its survival after termination written into the contract.
Price protection. Published terms often allow price changes on short notice. Anthropic's commercial terms, for example, allow published rates to change on 30 days' notice. That is normal for usage-priced services, which is why enterprises should negotiate caps on renewal increases, committed rates for the contract term, and the right to reduce commitments if a product is materially changed.
Exit assistance and change of control. Ask for data export in open formats at no charge, a defined exit-assistance period, and continuation of support terms if the vendor or product changes ownership. The AT&T dispute turned on exactly such support-renewal rights.
The Gulf view: residency and local content are mandatory filters
For buyers in Saudi Arabia and the UAE, two criteria are usually mandatory rather than scored.
Residency is decided per feature, not per platform. A platform may be available in a UAE or Saudi cloud region while some of its AI features process data in another region. Our NDMO implementation guide covers the data classification that drives this. With Microsoft's Saudi Arabia East region due in November 2026 and an AWS Saudi region announced for December 2026, region availability will change during 2027, so contracts should allow migration between regions without penalty.
Local content can change the arithmetic. Saudi government buyers apply Local Content and Government Procurement Authority (LCGPA) mechanisms, which include price preferences for national products and a mandatory list of national products in government contracts. Where these apply, build them into the scorecard from the start rather than adjusting the result afterwards.
What to do in the next 90 days
- Write the capability map for the decision in front of you, with mandatory and scored requirements, before any vendor meetings.
- Fix and sign off the scorecard weights, including an explicit weight for exit cost and for contract terms.
- Design a four-to-six-week proof of concept on your own data, with written pass and fail criteria and an exit test.
- Rebuild TCO with every invoice over three to five years, including the underlying cloud bill, egress, people and exit.
- Inventory your logic and policies on current platforms; that count, not data volume, is your real switching cost.
- Prepare a contract term sheet covering training restrictions, price caps, export, exit assistance and change of control, and score vendors on their responses.
- Call two references the vendor did not offer, ideally customers who have renewed or tried to leave.
Frequently asked questions
What does vendor-neutral technology selection mean?
It means choosing technology on evidence about your own requirements, data and costs, without a commercial interest in the outcome, and measuring exit cost before you commit. It does not mean avoiding commitment to a vendor or always running multiple clouds.
How should exit cost be estimated?
Estimate the effort to move data, rebuild business logic, security policies and integrations, run old and new platforms in parallel, and retrain staff. Data movement is usually the smallest part; logic and policies are the largest. Test exports during the proof of concept.
Do open standards like Apache Iceberg and MCP eliminate lock-in?
No, but they reduce it at specific layers. Iceberg makes table data readable by multiple engines, and the Model Context Protocol standardizes how AI agents connect to tools. Business logic, fine-grained security policies and audit still lack complete cross-engine standards.
Which contract terms matter most for AI and data platforms?
Restrictions on training models with your data, caps on renewal price increases, free export in open formats, defined exit assistance, and protection if the vendor changes ownership. Score these during selection rather than negotiating them after the decision.
Sources and further reading
- AT&T claims VMware offered it a 1,050 percent price rise, The Register, 1 October 2024; Broadcom, AT&T reach settlement in VMware legal dispute, CIO Dive, 22 November 2024.
- Cloud services market investigation, UK Competition and Markets Authority, final decision 31 July 2025.
- Data Act explained, European Commission.
- Free data transfer out to internet when moving out of AWS, AWS, 5 March 2024.
- Users upset by Slack using customer data in model training, The Register, 20 May 2024.
- Commercial Terms of Service, Anthropic, accessed 24 September 2026.
- Donating the Model Context Protocol and establishing the Agentic AI Foundation, Anthropic, 9 December 2025.
- Multi-engine lakehouse interoperability, Snowflake Engineering, 28 July 2026; Open Semantic Interchange specifications finalized, Snowflake, 27 January 2026.
- Nscale acquires Anyscale, Nscale, 30 July 2026; PyTorch Foundation welcomes Ray, Linux Foundation, 22 October 2025.
- Ingress NGINX retirement, Kubernetes, 12 November 2025.
- Industry benchmarks and competing with integrity, Snowflake, 12 November 2021.
- Saudi LCGPA launches additional price preference for local products, Asharq Al-Awsat, 22 September 2020.
- Microsoft Saudi Arabia East region announcement, Microsoft, 31 August 2026; AWS Saudi region announcement, Saudi Press Agency, September 2026.