Most discussion of AI lock-in assumes the problem is wanting to leave and being unable to. For a Canadian mid-market firm the more likely problem is different and arrives without any decision at all: the system you tuned your work around changes, and you incur the cost of a migration you did not authorise, to a destination you did not select.
Key Takeaway
One source draws the distinction that organises this article: vendor lock-in is a commercial condition of one supplier, weak alternatives and painful switching terms, while model dependency is narrower and sharper, because a firm can be perfectly happy with its vendor and still be trapped by a specific model version, since its prompts, thresholds, output parsers and quality expectations were all tuned against that exact set of weights. Lock-in accretes rather than being chosen: teams move fastest at first, and over time provider details leak into prompts, tools, logging and cost controls until exit becomes expensive. The hidden dependency is usually the prompt layer, which adapts to one model family while the application looks provider-agnostic. And the cost is not only at exit: blocked cost optimisation and outage exposure are running costs. Technical portability without contractual data return, deletion, egress and migration rights is described as worthless.
Lock-In Is Not Dependency
The distinction that most treatments of this topic collapse, and which changes what a firm should worry about.
One source states it precisely: vendor lock-in is a commercial condition, meaning one supplier, weak alternatives and painful switching terms, while model dependency is narrower and sharper, because you can be perfectly happy with your vendor and still be trapped by a specific model version, since your prompts, thresholds, output parsers and quality expectations were all tuned against that exact set of weights[1].
The same source frames the objective usefully: an exit strategy is not a plan to leave a provider, but the set of properties that let you leave if you need to, priced and rehearsed in advance, so that the decision stays a business decision rather than a technical impossibility[1].
A finance reader will recognise that as optionality, and the framing is exactly right. What is being purchased by the work described below is not an exit; it is the ability to choose, which has a price and which is worth something even if never exercised.
The distinction matters for a Canadian mid-market firm because the commercial condition is often tolerable while the model dependency is not. A firm may have no complaint about its provider, no intention of leaving, and a workflow whose behaviour is tied to a specific version of something it does not own.
The Migration You Did Not Choose
The consequence of that distinction when combined with a finding from earlier in this series. This section is our own analysis.
The drift article in this series established that providers ship silent updates, that model weights do not drift on their own but the model answering in one month may not be the one that answered previously, and that the change passes through none of the customer's change management.
Now place that beside the dependency finding. A firm's prompts, thresholds and output parsers are tuned against a specific set of weights[1]. If those weights change, the tuning is against something that no longer exists.
The result is that a silent provider update imposes the cost of a migration without granting the choice of one.
Consider what is lost in that arrangement compared with a deliberate switch. A firm choosing to move selects the timing, selects the destination, tests before cutover, and has negotiating leverage with both the incumbent and the alternative. A firm absorbing an update has none of those: no timing control, no destination choice, no pre-cutover test, and no leverage.
It gets the re-tuning bill, the quality regression risk and the revalidation work, which are precisely the costs a migration incurs, with none of the benefits a migration is undertaken to obtain.
That reframes the investment case for everything in this article. The abstraction layer, the evaluation set and the shadow testing are not primarily insurance against a decision to leave. They are the apparatus for surviving changes made by someone else, which are considerably more likely.
It Accretes, It Is Not Chosen
The mechanism, described well by one source and important because it means nobody is at fault.
One source describes the trajectory: you move fastest at first, and over time provider details leak everywhere, into prompts, tools, logging and cost controls, and the exit becomes expensive[2].
Another frames the response for engineering leadership as not avoiding vendor relationships, which it describes as not operationally realistic, but building with architectural awareness of the exit cost and making deliberate tradeoffs rather than accidental ones[3].
The phrase deliberate rather than accidental is the whole argument in four words.
No Canadian firm decides to become locked in. It decides, reasonably, to ship something quickly, and every subsequent reasonable decision adds a small piece of provider-specific detail. The model name appears in three places rather than one. A prompt is tuned to a particular style. An output parser is written against a particular format. None of these is wrong, and their sum is a dependency nobody approved.
One source gives the corresponding discipline in a sentence: choose the model in one place, in settings, not scattered across code[2].
That is a small architectural rule with a large effect, and it is close to free at the outset and expensive to impose later, which is the same retrofit asymmetry this publication has described for logging, lineage and approval gates.
Where It Forms
The taxonomy, which is useful for locating a firm's own exposure.
One source identifies four forms and argues that for AI, lock-in is more subtle and more dangerous than in traditional software. API dependency means the architecture bends around a single vendor's design choices. Agent framework capture means that where agentic workflows are built on a vendor's proprietary orchestration layer, switching costs compound rapidly. Data gravity means the more context, fine-tuning and institutional knowledge invested in a platform, the harder exit becomes. Ecosystem entanglement means that when a vendor's AI is deeply integrated with their cloud, their productivity suite and their data platform, the AI decision becomes inseparable from a much larger infrastructure commitment[4].
Another source describes binding at four layers simultaneously: model, data, API and infrastructure[5].
The fourth form in the first list is the one this publication's readers should look at first, and we return to it below. For most Canadian mid-market businesses, AI did not arrive through a procurement decision about a model. It arrived as a feature inside an accounting platform, a productivity suite or a practice management system they already used.
The same source makes a governance point worth quoting for anyone facing an internal argument about this: using different vendors for different use cases, maintaining architectural separation between the orchestration layer and model API calls, and investing in abstraction layers that reduce switching costs are signs of mature governance rather than signs of indecision[4].
The Prompt Layer Is The Hidden One
The dependency that forms invisibly and that most portability planning misses.
One source explains it well: prompts are not always portable, since a prompt that works well with one model may produce weaker or less reliable answers with another, because teams tune instructions around a provider's style and reasoning behaviour. It observes that the application looks provider-agnostic on the outside while its prompt layer has actually adapted to one model family, creating a hidden dependency, so moving would require prompt rewriting and quality review[6].
The word hidden is accurate. An architecture diagram showing a clean interface between application and provider is a true picture of the code and a false picture of the dependency, because the dependency lives in text that the diagram does not represent.
This is worse than it appears for two reasons, and this is our own analysis.
The tuning is usually undocumented. Prompts reach their final form through iteration, and the reasons for particular phrasings are rarely recorded, so a firm migrating does not know which elements were necessary and which were incidental.
And the tuning is often performed by whoever was closest to the work, which the drift article noted means prompts frequently sit outside version control entirely. A dependency that is undocumented and unversioned cannot be assessed, only rediscovered.
The mitigation is the one that article recommended for a different reason: put prompts under version control with the model version they were tuned against recorded alongside. That single record converts a hidden dependency into a documented one.
Embeddings And The Index Rebuild
The data-side dependency, which is the expensive one for professional firms.
One source notes that if a retrieval system relies on one embedding model, changing that model may require rebuilding indexes and retesting retrieval quality, describing this as an expensive and disruptive migration for large knowledge bases[6]. Another warns that embedding choices can force re-embedding and reindexing during migrations, and recommends planning for dual indexing and keeping raw content portable so vectors can be rebuilt when needed[2].
The same source gives the durable principle: keep raw documents and chunk metadata as the source of truth, and version the embedding pipeline[2]. A third lists reproducible embeddings among its portability requirements and warns that failing to keep them reproducible turns data into a trap[5].
The principle translates directly for a Canadian professional firm and is worth stating plainly. The vectors are derived data. The documents are the asset.
A firm whose knowledge base exists only as embeddings in a vendor's system has converted its own documents into a form it cannot use elsewhere. A firm that retains the source documents, the chunking rules and the pipeline configuration can rebuild in a new system, paying compute rather than starting over.
That is a records management decision more than a technical one, and it is the sort of decision a professional firm is well equipped to make once it is framed as one.
Fine-Tuning Is The Strongest Form
The dependency to be most cautious about entering.
One source states that fine-tuning creates stronger lock-in because the customised model typically stays inside the provider's environment, and that if the weights and training data cannot be exported cleanly, a firm might need to retrain from scratch elsewhere[6].
The asymmetry is that the investment is portable in principle and not in practice. The training data is the firm's own, and the resulting artefact frequently is not.
For a Canadian mid-market firm the practical guidance is that fine-tuning is a commitment of a different order from prompting or retrieval, and should be evaluated as such. Two questions settle most of it: can the resulting weights be exported, and is the training dataset retained by the firm in a form that would allow retraining elsewhere.
If the answer to the first is no, then the investment is recoverable only by repeating it, and the exit cost includes the entire fine-tuning programme rather than a migration of configuration.
We would add that for most professional services use cases the accuracy gain from fine-tuning over well-constructed retrieval is frequently not established for that firm's own tasks, which returns to the evaluation set argument below.
Lock-In Has A Running Cost
The reframing that makes the abstraction layer pay for itself, and it follows from a source observation plus our own analysis.
One source states that the real cost of lock-in is not the API price but the migration tax, blocked cost optimisation and outage exposure that hit when a firm cannot easily test alternatives or shift traffic[6].
Blocked cost optimisation is the term worth extracting, because it converts lock-in from a contingent liability into a current expense.
The previous articles in this series established that model pricing spans roughly three orders of magnitude, that quality does not scale linearly with price, and that complexity-based routing across model tiers reportedly reduces average cost per request substantially.
A firm that cannot route cannot capture any of that. It pays its single provider's price on every request, including the large majority of requests that a cheaper model would have handled adequately, and it pays that premium every day rather than once at exit.
So the business case for an abstraction layer should not be built on the probability of a migration. It should be built on the routing savings available immediately, with the migration optionality as a second benefit.
That is a materially easier case to make internally, because it is a current-period return rather than insurance against an event nobody expects.
The Abstraction Layer
The canonical pattern, described best by one source.
One source sets it out: a stable internal interface that expresses the organisation's AI capability needs, phrased as the tasks it wants performed, independently of the provider that fulfils them. Underneath the abstraction the firm wires to a specific provider, and when it wants to evaluate an alternative or execute a migration, it changes the wire rather than the interface[3].
Another describes the same thing as a vendor-neutral model router placed in front of every application, so that switching becomes configuration rather than a code project[5]. A third describes a control plane that owns which model runs and what sources it may use[2].
On effort, one source states that an abstraction layer is typically two to four engineer-weeks for a single-layer implementation[1].
We report that figure as stated and note it comes from a firm that performs such work.
The design insight in the first formulation is the one to carry. The interface should express what the firm needs done, in the firm's own terms, rather than what the model does. An interface named for a business task survives a provider change; an interface named after a provider's API shape does not.
For a Canadian firm buying rather than building, the equivalent question to a vendor is whether the model is selectable in configuration and whether alternatives are supported, which is a procurement question rather than an engineering one.
The Gateway Tradeoff
The honest counterweight, which most of this literature states only briefly.
One source notes that gateways can reduce application-layer coupling by standardising requests and routing across providers, and that the tradeoff is introducing another layer you must operate and evaluate[2].
That deserves more weight than it usually receives, and this is our own analysis.
A gateway is itself a vendor. Routing every request through a third party to avoid dependency on a first party creates a dependency on the third party, which now sits on the critical path of every workflow, sees every prompt and every response, and has its own availability, pricing and continuity risk.
The lineage article in this series noted that a firm's institutional memory can end up residing in a system it does not control. A gateway adds a second such system.
For a large enterprise routing across many providers the tradeoff usually favours the gateway. For a Canadian mid-market firm using one or two models, a thin internal abstraction, being a single place in configuration where the model is named, captures most of the benefit without adding an operational dependency.
We would also note that gateway vendors are the authors of much of the material recommending gateways, which is the same structural bias this publication flagged in the preceding article.
The Transferability Gradient
A finding that should determine migration sequencing, and one of the most useful things in this material.
One source states it directly: narrow, well-specified tasks transfer between models easily, while open-ended and multi-step work transfers badly, so migration should be sequenced accordingly and agentic workloads should be expected to need the most re-tuning[1].
The gradient is intuitive once stated. A task with a tight specification and a checkable output has little room for a different model to behave differently in ways that matter. A multi-step agentic workflow has many points at which behaviour can diverge, and the divergences compound.
Two consequences for a Canadian firm.
Sequencing a migration from narrow to broad means the early phases are cheap and produce learning that improves the later ones, which is the same phasing logic the total cost article recommended.
And the gradient is also a design signal, not only a migration signal. A workflow specified narrowly enough to transfer easily between models is a workflow whose output is checkable, which is the property the control articles in this series argued for on entirely separate grounds. Portability and verifiability turn out to be the same property viewed from different angles.
Shadow Mode
The testing method, which is the highest-value practice here.
One source describes running an alternative model against live traffic in parallel with the incumbent, calling it the highest-quality evidence available short of a real cutover, notes that the abstraction layer makes it nearly free to build, and recommends running it long enough to cover a full business cycle including month-end and any seasonal peak, observing that a week of shadow traffic routinely surfaces failure modes no offline set contained[1].
Two elements of that are worth emphasising for a Canadian professional firm.
The business cycle point is not generic advice. A practice whose work concentrates around filing deadlines has a population of tasks in that period that looks nothing like its ordinary month, and a model evaluated in a quiet period has been evaluated on the easy population, which is the same sampling error the productivity and exception articles identified.
And the observation that live traffic surfaces failure modes no offline set contained is a genuine limitation of the private evaluation set this publication has recommended repeatedly. An evaluation set is built from cases someone thought of. Live traffic contains the cases nobody did.
The two are complements rather than substitutes. The evaluation set gives a repeatable measure across time, which is what drift detection requires. Shadow mode gives coverage of the real distribution, which is what a switch decision requires.
Without Exit Clauses, Portability Is Worthless
The layer most technical guidance omits, and the one a Canadian business is best placed to act on.
One source states it bluntly among its common errors: forgetting exit clauses, because without contractual data return, technical portability is worthless. Its recommendation is to write exit clauses into every contract covering data return, deletion, egress, retention and migration rights[5]. It notes that this extends the usual best-practice checklists with the contractual and open-weight layers that most guides leave out[5].
Another lists negotiating exit clauses and ensuring data portability in all contracts among its recommendations[7].
This is the part of the problem that does not require engineering capability, and it is therefore the part most accessible to a mid-sized Canadian firm.
The questions to put into a contract are straightforward: what data will be returned on termination, in what format, within what period, at what cost; what is deleted and on what evidence; what happens to derived artefacts such as embeddings and fine-tuned weights; and what notice is given of material changes to the service, which returns to the silent update problem.
The last of those is the one this publication would press hardest, because it is the only contractual remedy for the migration-you-did-not-choose problem. A right to notice of model changes converts a silent update into a scheduled event, which is the difference between absorbing a change and managing one.
When The Vendor Ceases To Exist
The form of lock-in that is existential rather than expensive.
One source cites the collapse of a well-funded AI company, describing businesses suddenly finding themselves stranded and unable to access critical systems or data, and characterising this as a wake-up call that lock-in in the AI era carries existential risk[7].
We report the account as stated and have not verified the details independently.
The reason to include it is that it identifies the risk profile most relevant to a Canadian mid-market buyer, and this is our own analysis. A large firm's lock-in exposure is switching cost. A smaller firm buying from a venture-funded startup has a different exposure, which is that the supplier may not exist in two years.
That exposure is not addressed by an abstraction layer, because there is no orderly migration when a service stops. It is addressed contractually and operationally: data export on a schedule rather than on request, retention of source material outside the vendor's system, and knowing in advance what the workflow degrades to if the service disappears tomorrow.
The practical test is simple and worth running. If this supplier ceased operating on Friday, what could the firm still do on Monday, and what would it have lost permanently. If the answer to the second is anything material, the arrangement needs changing regardless of how good the product is.
A Number Worth Questioning
A note on one source's figures, flagged because this publication checks what it repeats.
One source states that AI vendor lock-in costs 19 to 34 percent in switching, that migration costs average 315,000 dollars per project, that 67 percent of organisations are actively working to avoid single-provider dependency, and that multi-cloud adoption has reached 93 percent of enterprises[7].
The same source then describes a named manufacturing company spending 315,000 dollars migrating forty AI workflows after the vendor collapse mentioned above[7].
The average migration cost and the single case study are the same number. That may be coincidence, and it may be that one case has been presented as an average, which would make the figure a sample of one rather than a benchmark.
We have no way to establish which, and we report the figures only to characterise what is circulating rather than as a planning basis. None of the four figures carries a citation in the source.
The general caution is the one from the preceding article: this literature is written by parties selling the remedy, and its numbers are frequently unsourced and occasionally internally inconsistent. The structural findings are more reliable than the magnitudes.
The Canadian SMB Reality
Adjusting all of the above for this publication's actual readership, offered as our own analysis.
Most of this material addresses organisations that selected a foundation model and built on it. That describes very few Canadian mid-market businesses.
The typical position is ecosystem entanglement[4] arrived at without a decision: AI features appeared inside an accounting platform, a document system or a productivity suite already in use. No model was procured, no provider was chosen, and no abstraction layer is possible because the firm does not control the integration.
For that firm, most of the advice in this article is aimed at someone else. Multi-model strategies, routers and open-weight fallbacks are not available options.
What remains available is the part that matters most and costs least. Keep source documents outside the vendor's system in a form that is usable elsewhere. Secure contractual data return, deletion and export rights. Ask what notice is given of material changes. Know what the workflow degrades to if the feature is withdrawn or changed. And record which vendor features the firm has become dependent on, so that a renewal conversation is informed.
The one architectural discipline that is available even here is to avoid building processes that only work with the feature. A workflow that can be performed manually at reduced speed is in a different position from one that cannot be performed at all.
The Evaluation Set, Fourth Use
A compounding argument this series has now built across four articles.
The benchmark contamination article argued that a firm needs a private evaluation set built from its own closed files, because published scores are contaminated evidence and cannot support procurement decisions.
The drift article showed that the same set, re-run on a schedule, is the only instrument that detects a provider changing behaviour underneath a validated workflow.
The inference economics article showed that the same set is what establishes which model tier is sufficient for which task class, which is the precondition for routing and therefore for the largest available cost saving.
This article adds the fourth use. A migration decision requires knowing whether an alternative performs adequately on the firm's own work, and one source describes the abstraction layer plus testing as what makes a switch a business decision rather than a technical impossibility[1].
Four independent problems, one asset. We would put it plainly: for a Canadian firm doing anything serious with AI, the private evaluation set is the highest-return artefact available, and it is built from material the firm already has.
A Worked Case: The Update Nobody Approved
A Canadian firm running a document classification workflow. The reconstruction illustrates the mechanism rather than reporting a specific engagement.
The workflow was built quickly and works well. The model is named in several places in the configuration, the prompt was tuned by iteration until output was reliable, and the retrieval index was built with the provider's embedding model.
The firm has no complaint about its vendor and no intention of leaving, so on the commercial definition it is not locked in. On the narrower definition it is dependent on a specific model version[1].
The provider updates the model. Output quality shifts, not dramatically, in the direction the drift article described as quiet degradation. The prompt tuned to the previous behaviour is now tuned to something that no longer exists.
The firm incurs re-tuning effort, quality regression risk and revalidation work: the costs of a migration, without having chosen the timing, the destination or having tested first.
It also cannot easily evaluate an alternative, because the model name is scattered rather than held in one place[2], the prompt has adapted to one model family[6], and the index would require rebuilding with a different embedding model[6].
Every one of those was avoidable at build time at negligible cost, and none is cheap to fix afterwards.
What To Do
Name the model in one place. Configuration, not scattered through the workflow. Close to free at the outset and expensive to impose later.
Version prompts, and record which model version each was tuned against. This converts the hidden dependency into a documented one.
Keep source documents as the asset and treat vectors as derived. Retain the documents, chunking rules and pipeline configuration so an index can be rebuilt rather than recreated.
Build the case for abstraction on routing savings, not on migration insurance. Blocked cost optimisation is a current expense, which is a much easier internal argument.
Be cautious with fine-tuning. Establish first whether weights can be exported and whether you retain the training data in usable form.
Write exit clauses. Data return, format, timing, cost, deletion, derived artefacts, and notice of material service changes. Technical portability without them is described as worthless.
Ask for notice of model changes specifically. It is the only contractual remedy for the migration you did not choose.
Run the Friday test. If the supplier stopped operating today, what could you still do tomorrow and what would be permanently lost.
Sequence any migration from narrow tasks to open-ended ones. The gradient is real and the early phases fund the learning for the later ones.
Shadow test across a full business cycle. Including your seasonal peak, because a quiet-period evaluation samples the easy population.
The Limits Of This Analysis
Several caveats matter, and the first is the same structural one as the preceding article: every source here is a vendor or consultancy selling abstraction layers, gateways, migration services or advisory work, so each recommends a remedy it supplies. Figures are frequently unsourced, and one source presents an average migration cost identical to its single case study, which we have flagged rather than repeated as a benchmark. The two-to-four engineer-week estimate for an abstraction layer comes from a firm performing such work. The vendor collapse account is reported as stated and not independently verified. Named products, standards and companies appearing in sources are reported without endorsement or verification. The synthesis that a silent provider update imposes migration costs without migration choice, the observation that portability and verifiability are the same property, the gateway-as-new-dependency argument, the Friday test, the Canadian SMB adjustment and the worked case are our own analysis rather than findings in the cited material. Nothing here addresses contract drafting in detail, and exit provisions should be prepared with legal advice; this article does not address competition law, procurement regulation, cross-border data transfer, or the tax treatment of migration costs. Nothing here is legal advice or a substitute for professional guidance on supplier arrangements in a specific business.
Frequently Asked Questions
What is the difference between lock-in and model dependency?
Why does that matter if we are not planning to switch?
What is the hidden dependency most firms miss?
How do we justify an abstraction layer internally?
Is a gateway always the answer?
What if our AI came bundled with software we already use?
References
- Progressive Robot. (2026, August 9). AI Model Exit Strategy, on the distinction between vendor lock-in as a commercial condition and model dependency as being trapped by a specific model version against which prompts, thresholds, output parsers and quality expectations were tuned; the framing of an exit strategy as properties priced and rehearsed in advance; the transferability gradient in which narrow well-specified tasks transfer easily and open-ended multi-step work transfers badly; shadow mode as the highest-quality evidence short of cutover, run across a full business cycle; and the two to four engineer-week estimate for an abstraction layer. Note: published by a consultancy selling related advisory and migration work. progressiverobot.com/2026/08/09/ai-model-exit-strategy
- CustomGPT.ai. Avoid LLM Vendor Lock-in: A Guide To Portability, on lock-in occurring when switching requires rewriting prompts, tools, retrieval and operations; choosing the model in one place rather than scattered across code; provider details leaking into prompts, tools, logging and cost controls over time; the gateway tradeoff of introducing another layer to operate and evaluate; the migration recipe of a provider-neutral blueprint with verification tests; and keeping raw documents and chunk metadata as the source of truth with dual indexing and a versioned embedding pipeline. Note: published by a platform vendor. customgpt.ai/how-to-avoid-llm-vendor-lock-in
- StepTo. (2026, April 9). The AI Infrastructure Trap, on building with architectural awareness of exit cost and making deliberate rather than accidental tradeoffs, and on the canonical model abstraction layer as a stable internal interface expressing capability needs independently of the provider, where migration means changing the wire rather than the interface. stepto.net/blog/ai-vendor-lock-in-infrastructure-risk-2026
- Waehner, K. (2026). Enterprise Agentic AI Landscape Q2 2026: Trust, Flexibility, and Vendor Lock-in, on lock-in for AI being more subtle and dangerous than in traditional software; the four forms of API dependency, agent framework capture, data gravity and ecosystem entanglement; and the argument that multi-vendor use, architectural separation and abstraction investment are signs of mature governance rather than indecision. Note: an independent analyst blog covering vendors commercially. kai-waehner.de/blog/2026/04/06/enterprise-agentic-ai-landscape-2026
- ADVISORI. (2026, June 14). AI Vendor Lock-In: How to Avoid It, on binding at four layers of model, data, API and infrastructure simultaneously; the exit playbook of abstraction layer, multi-model strategy, open-weight self-hosted backup, data portability and contractual exit clauses; the warning that without contractual data return technical portability is worthless; and that failing to keep embeddings reproducible turns data into a trap. Note: published by a consultancy selling sovereign AI advisory. advisori.de/en/blog/how-to-avoid-ai-vendor-lock-in-enterprise-guide
- Orq.ai. (2026, June 17). LLM Vendor Lock-In: What It Costs and How to Avoid It, on the real cost being migration tax, blocked cost optimisation and outage exposure rather than API price; prompts not being portable and the prompt layer adapting to one model family as a hidden dependency; fine-tuning creating stronger lock-in where weights and training data cannot be exported cleanly; embedding model changes requiring index rebuilds and retrieval retesting; and the gateway benefits of one API, configurable routing, tested fallback paths, portable observability and centralised budgets. Note: published by a gateway vendor. orq.ai/blog/llm-vendor-lock-in
- Swfte AI. AI Vendor Lock-in: How Enterprises Are Breaking Free in 2026, on the cited collapse of a well-funded AI company leaving businesses stranded and unable to access systems or data; the recommendations covering abstraction layers, exit clauses, multi-model architecture, open standards and internal expertise; and the reported figures for switching cost percentage, average migration cost, organisations avoiding single-provider dependency and multi-cloud adoption. Note: published by a vendor selling an orchestration platform; the figures carry no citations and the stated average migration cost is identical to the source's single case study, as discussed in the text. swfte.com/blog/avoid-ai-vendor-lock-in-enterprise-guide
This article discusses supplier dependency and exit planning and is provided for general informational purposes. Every source is a vendor or consultancy selling the remedies it recommends, figures are frequently unsourced and one is internally inconsistent as flagged in the text, and named companies and products are reported without verification or endorsement. Nothing here is legal advice, and exit provisions should be prepared with professional guidance.