We spend a tremendous amount of time talking about vendor lock-in.
We ask whether a platform is too proprietary. We debate whether a tool will limit our options three or five years from now. We introduce abstractions, alternate technologies, and architectural complexity in an attempt to preserve optionality.
Yet in trying so hard to avoid vendor lock-in, we may be creating a different kind of lock-in—one built from our own complexity.
After more than three decades working in technology, infrastructure, and operations, I have come to believe that we often address vendor lock-in at the wrong layer. We focus on the vendor instead of strengthening our own foundations.
We Need a Better Definition of Lock-In
Vendor lock-in should not simply mean that a vendor provides something unique. Almost every useful technology creates some degree of dependency.
When we adopt a database, cloud platform, infrastructure framework, CI/CD system, observability platform, or software-as-a-service product, we make a choice. Every meaningful choice carries some switching cost.
The more useful question is:
What would it cost us—in time, money, risk, lost functionality, retraining, and organizational effort—to change that choice?
That question is much closer to how the industry treats portability. NIST has long identified interoperability and portability as important cloud considerations. AWS similarly describes vendor lock-in in terms of switching costs that make leaving prohibitively difficult or risky.
The goal should not be zero vendor dependency. That is unrealistic and often counterproductive.
The goal should be intentional dependency with a manageable exit cost.
Terraform Shows the Difference
Terraform is a useful example.
Terraform has created significant value by giving organizations a consistent infrastructure-as-code model. Standardizing on Terraform is not inherently a problem. In fact, standardization can dramatically improve reliability, repeatability, governance, and speed.
The problem begins when organizational knowledge becomes inseparable from the implementation.
There is an important difference between these two statements:
- Terraform implements our infrastructure standards.
and
- Our Terraform implementation is our infrastructure standard.
They sound similar, but architecturally they are very different.
If the authoritative definition of our policies, configurations, security controls, service requirements, tagging rules, network requirements, and deployment patterns exists primarily inside Terraform modules, HCL, workspace configuration, and platform-specific policy implementations, Terraform is no longer simply executing our standards.
It has become the place where our standards live.
That increases our switching cost because replacing the execution platform now requires us to rediscover and extract our own organizational intent.
Policy provides another example. HCP Terraform can use Sentinel and Open Policy Agent, or OPA, to evaluate Terraform plans and enforce organizational controls. Sentinel is valuable, but if enterprise policy exists only as Sentinel code, changing platforms means doing more than replacing an execution engine. We must also recover and reinterpret the intent embedded in that platform.
OPA offers a more portable model. It was designed as a general-purpose policy engine that separates policy decisions from enforcement and evaluates structured data supplied by different systems. It is also a graduated Cloud Native Computing Foundation project.
That does not make every OPA policy instantly portable. Platforms expose different resources, data structures, lifecycle stages, and enforcement points. Translation will still be required.
But the organizational intent has moved one layer away from the vendor. That is the important architectural improvement.
Instead of thinking only in terms of:
Enterprise policy → Vendor-specific policy → Terraform
we can begin designing for:
Enterprise policy → Portable policy definition → Terraform today
and, if circumstances change:
Enterprise policy → The same governing intent → Another platform tomorrow
Portability Is an Architectural Property
Portability is not created merely by having two vendors. It is created by separating enterprise intent from vendor implementation.
We need an architecture in which our standards survive the replacement of the tool implementing them. I think of that architecture in four layers.
1. Enterprise Intent
First, define what the organization actually requires.
What must every production service include? What networking requirements apply? What metadata and ownership information are required? What security controls must exist? What configurations are permitted? What environments do we support? What makes a service production-ready?
Those requirements should exist independently of Terraform, GitHub, Azure, AWS, Google Cloud, Kubernetes, or any other product.
2. Structured Sources of Truth
Next, make those requirements machine-readable.
They cannot live only in PowerPoint presentations, wiki pages, old tickets, or tribal knowledge. They also should not be scattered across thousands of lines of infrastructure code.
Standards, schemas, policies, service metadata, ownership, classifications, control definitions, and architectural requirements should increasingly exist as version-controlled structured data.
Where appropriate, we need configuration as code, policy as code, standards as code, and controls as code.
Humans should be able to read them. Software should be able to consume them. Automation should be able to validate them. AI should be able to reason over them.
3. Translation and Enforcement
Only then should we translate enterprise intent into a specific implementation.
Terraform may be one implementation. A source-control platform, CI/CD system, cloud provider, security platform, or automation platform may be another.
This is where adapters, providers, modules, APIs, generators, pipelines, and integration code belong. They translate organizational requirements into the constructs a particular product understands.
4. Execution Platforms
Finally, vendors execute.
We should take advantage of vendor capabilities when they create meaningful value. Portability does not require reducing every platform to the lowest common denominator.
If a proprietary capability creates measurable business value, use it, but understand where it sits in the architecture and deliberately accept the associated exit cost.
That makes lock-in intentional instead of accidental.
The Industry Has Already Warned Us
Terraform itself demonstrates why this matters.
In August 2023, HashiCorp changed the license for future releases of Terraform and several other products from the Mozilla Public License to the Business Source License. The decision contributed to the creation of OpenTofu, a community-driven Terraform fork. OpenTofu was accepted into the CNCF Sandbox in April 2025 and continues to emphasize compatibility with the Terraform ecosystem.
The lesson is not that Terraform was the wrong decision. The lesson is that external conditions can change even when our internal architecture does not.
Ownership changes. Licensing changes. Pricing changes. Companies are acquired. Product strategies shift. Capabilities are deprecated. Better technologies emerge.
Our responsibility is not to predict every future event. Our responsibility is to ensure that those events do not force us to rediscover our own requirements before we can respond.
Complexity Can Become Its Own Lock-In
This is why I believe the priority should be less about chasing every hypothetical vendor decision and more about getting the fundamentals right.
We need consistent service definitions, formal configuration standards, defined infrastructure patterns, policy as code, controls as code, schemas, contracts, authoritative service metadata, versioning, testing, ownership, and traceability between a requirement and the technical control enforcing it.
Most organizations already have pieces of these things. What they often lack is a consistent system connecting them.
Without that foundation, every new platform becomes another place for organizational knowledge to accumulate. Every automation adds another implementation. Every team solves the same problem slightly differently.
Eventually, the complexity itself becomes the lock-in.
It may not be vendor lock-in. It may be something even more difficult to unwind: operational lock-in.
We become trapped by undocumented assumptions, team knowledge, scripts, pipelines, modules, configuration files, exceptions, and historical decisions that nobody can safely change.
That can be a greater risk than any individual vendor.
AI Makes the Foundation More Urgent
AI and agent-based automation make this foundational work more important, not less.
An AI agent can generate Terraform, write a pipeline, create a configuration, call APIs, or remediate infrastructure. But before we ask an agent to do any of those things, the organization must be able to answer:
- What should it build?
- What is allowed?
- What is required?
- Which standard should it follow?
- Where is the authoritative configuration?
- How will it determine whether a proposed change complies with policy?
If the answers live primarily in tribal knowledge, old documentation, support tickets, individual repositories, and vendor-specific implementations, AI does not solve the problem.
It accelerates the inconsistency.
A structured source of truth changes that. Once standards, configurations, policies, service definitions, and controls are machine-readable, traditional automation and AI-driven automation can operate from the same authoritative foundation.
That is how AI becomes an accelerant instead of another source of technical debt.
Ask Better Architecture Questions
Our architectural objective should not be, “Avoid vendor lock-in.”
It should be:
Maintain control of our enterprise intent and keep the cost of changing implementations within acceptable bounds.
That changes the questions we ask.
Instead of asking, “Can another vendor do this?” ask, “What organizational knowledge would we lose if this vendor disappeared tomorrow?”
Instead of asking, “Is this proprietary?” ask, “Which parts are proprietary, and are we deliberately accepting that dependency?”
Instead of asking, “Can we run two platforms?” ask, “Are our standards and policies independent enough for another platform to implement them?”
Instead of asking, “How do we avoid committing to this technology?” ask, “How do we commit to this technology without giving it ownership of our architecture?”
That is a more useful and achievable goal.
Build the Foundation First
The next phase of platform strategy should be about foundations.
Not another abstraction layer created solely to protect us from the tool beneath it. Not another product introduced to solve the complexity created by the last product. And not an architecture built primarily around hypothetical migrations.
We need canonical definitions of how our environments operate.
- Our standards should belong to us.
- Our policies should belong to us.
- Our configurations should belong to us.
- Our service definitions should belong to us.
- Our vendors should implement those things, not define them for us.
Changing vendors will never be free, nor should we expect it to be. There will always be migration work, retraining, integration changes, capability differences, and implementation-specific engineering.
But if we control our enterprise intent, we will not have to reverse-engineer years of organizational knowledge from the product we are leaving. We will already know what the next platform must implement.
Migration then becomes primarily an engineering problem. We modify the translation layer, test the new implementation against the same standards, validate it against the same policies, connect it to the same sources of truth, and change the execution platform beneath it.
That is not zero lock-in.
It is something far more valuable: controlled dependency, deliberate architecture, and a credible ability to exit.
Scripture gives us an appropriate final reminder about building deliberately and understanding cost before we commit:
“For which of you, intending to build a tower, sitteth not down first, and counteth the cost, whether he have sufficient to finish it?”
— Luke 14:28, KJV
The strongest technology strategy is not the one that refuses to commit. It is the one that understands the cost, owns its foundations, and commits with its eyes open.
