Lock-in is not a single decision you make once. It accumulates quietly, one convenient managed feature at a time, until moving would take a quarter of engineering effort nobody can spare. The goal is not zero lock-in, which is unrealistic and often wasteful. The goal is to know where you are locked in, and to have chosen it deliberately.

Lock-In Is a Spectrum, Not a Switch

Some dependence is perfectly reasonable. If a managed service saves your team months of work and you accept that moving later will cost something, that is a sound trade. Problems arise when dependence is invisible, when it spreads into places where an alternative would have cost little, or when nobody can say what leaving would involve.

A useful mental split is between cheap-to-move layers and expensive-to-move layers:

• Cheap: stateless code in containers, model files in open formats, configuration kept in version control.
• Moderate: orchestration definitions, CI/CD pipelines, monitoring dashboards.
• Expensive: large datasets, proprietary feature stores, identity and permissions models, and anything written against a provider-specific API.

Spend your portability effort on the expensive layers first, since the cheap ones mostly take care of themselves.

Where Lock-In Hides in AI Stacks

Data. Large datasets are heavy to move, and transfer charges can add up. This is the most common and most durable form of lock-in, and it is rarely about contracts. It is about physics and bandwidth.

Proprietary training and serving APIs. If your training scripts call a provider-specific SDK throughout, or your serving layer depends on a particular endpoint format, those calls become migration work later.

Orchestration and pipelines. Pipeline definitions written in a provider’s own workflow language do not transfer to another environment.

Identity and networking. Permission models, private networking, and service accounts are deeply provider-specific, and they are often the slowest part of a migration because they touch everything.

Accelerator-specific optimization. Code tuned heavily for one vendor’s hardware or compiler stack may need real rework elsewhere. Check each vendor’s current documentation before assuming a workload runs unchanged on a different accelerator family.

The Portability Checklist

Work through this table with your team and mark each row as done, partial, or consciously accepted. The “accepted” category matters: it records a decision rather than a gap.

Area	Portable habit	Status question
Code packaging	Training and serving run from standard container images	Can any engineer rebuild and run the image elsewhere?
Model artifacts	Stored in documented, open or widely supported formats	Can models load without the original platform’s tooling?
Data	Raw and curated data have a documented export path	Do you know the time and transfer cost to copy it out?
Orchestration	Pipelines use an open workflow tool or thin wrappers	Is business logic separate from scheduler-specific syntax?
Infrastructure	Defined as code with provider details isolated in modules	Could a second environment be described by changing modules?
Secrets and identity	Accessed through an internal abstraction	Is provider-specific auth confined to a few files?
Observability	Metrics and logs use open conventions	Can dashboards be rebuilt without starting from zero?

Isolate, Don’t Abstract Everything

Teams sometimes respond to lock-in fear by building a giant internal abstraction layer that hides every provider detail. This usually backfires: the abstraction becomes lowest-common-denominator, slows development, and itself becomes something to maintain.

A better approach is isolation. Let provider-specific code exist, but keep it in a small number of well-named modules. Your training logic should not know whether it runs on one cloud or another; only a handful of adapter files should. When a migration comes, you rewrite the adapters rather than hunting through the whole codebase.

Rehearse the Exit

You do not need to migrate to test portability. Run lightweight rehearsals:

1. Pick one non-critical model and try to build and run its container somewhere else, even on a laptop or a small test cluster.
2. Estimate, using the provider’s current published terms, what exporting your largest dataset would involve in time and transfer charges.
3. List every provider-specific service you depend on and ask what the replacement would be.

These exercises take a few days and expose assumptions that remain invisible until you are forced to move. Record the findings in a short document that new engineers can read.

A Hypothetical Example

Consider a team that built a recommendation model on a single provider’s managed training service. Their training script imported the provider’s SDK in forty places, their pipeline used the provider’s workflow language, and their features lived in a managed store with no export routine.

When leadership asked what a move would cost, the honest answer was “months.” Over the following quarter the team refactored: the SDK calls moved behind two adapter modules, the pipeline logic was extracted into plain Python functions with thin scheduler wrappers, and a nightly job began exporting feature tables to open file formats in object storage. They did not leave the provider. But the next time a capacity shortage threatened a launch, they could credibly test a second environment within days, which changed both their risk and their negotiating position.

When Lock-In Is the Right Choice

Do not treat every managed service as a mistake. If your team is small, the managed service removes a real operational burden, and switching is unlikely to matter within your planning horizon, depending on it is rational. The discipline is to write down the decision: what you depend on, why, and what would make you revisit it. A recorded decision is a very different thing from drift.

Frequently Asked Questions

Is vendor lock-in always bad? No. Some dependence buys real speed and lower operational load. It becomes a problem when it is unexamined or when switching costs surprise you at a bad moment.

Does using Kubernetes guarantee portability? It helps with workload packaging and scheduling, but it does not remove dependence on provider-specific storage, networking, identity, or accelerator configuration. Treat it as one piece of the answer.

Should we go multi-cloud to avoid lock-in? Running actively on several clouds adds substantial complexity. Most teams are better served by keeping the ability to move than by exercising it constantly.

What is the single highest-value portability habit? Packaging training and serving in standard containers while keeping data exportable. Together these cover the two layers that cost the most to move.

How do we handle proprietary model-serving features? Use them where they pay off, but keep inference logic and model files separate from the serving wrapper so the wrapper can be replaced.

Next Step

Copy the checklist table into a shared document, assign one engineer to fill in the status column in an hour, and mark each gap as “fix,” “accept,” or “revisit later.” That single page will make your next platform conversation far more grounded.