You have probably felt the pull of vendor lock-in even though you did not have a word for it at that time. As you write infrastructure as code (IaC), you pick a tool, you build hundreds of things on top of it, and then one day someone changes the license, raises the price, or gets acquired. The thing that made your life easy is now the thing holding you hostage.
Terraform decided in 2023 to change its license to BSL, which led to significant changes, including the rise of OpenTofu and IBM’s acquisition of HashiCorp. All of these changes led to questions like “how locked in am I?”.
In this article, we will explore what vendor lock-in really means, which types of vendor lock-in you need to consider when using Terraform, and the practical steps you can take to keep your options open.
What we’ll cover:
What is vendor lock-in?
Vendor lock-in is the situation in which you want to move away from a product, service, or provider that costs you a lot, but you cannot afford to leave. You are free to go, but the financial and operational costs may make it impractical.
If you can leave easily, the vendor has to keep earning your business through good pricing, support, and features. The opposite happens when you cannot leave easily: the vendors can raise prices, change licensing terms, deprecate the feature you depend on, or get acquired by a company with a very different roadmap, and your only choices are to accept it or go through a difficult and expensive migration process.
Lock-in is not always intentional, and it often emerges when a tool delivers significant value and becomes deeply embedded in your process. Your objective is not to eliminate every dependency; you need to recognize which ones are difficult and expensive to unwind and choose them consciously instead of by default.
Types of vendor lock-in to consider when using Terraform
Terraform has several types of vendor lock-in that operate at different layers of your stack. Let’s explore them in detail.
1. HashiCorp/tooling lock-in
In August 2003, everyone started worrying when HashiCorp announced it was moving Terraform from the open-source MPL license to the Business Source License (BSL). The BSL is not open-source and also restricts certain commercial uses.
In situations like teams running Terraform internally against their own cloud accounts, day-to-day usage didn’t change much, but the license’s wording wasn’t entirely clear. The real issue was that a single vendor controls the tool and can change the rules whenever they choose.
IBM’s $6.4 billion acquisition of HashiCorp at the beginning of 2025 has added another flavor to vendor lock-in. Now the entity controlling Terraform’s roadmap, licensing, and registry is an IBM subsidiary.
In this case, this is a tooling lock-in. So, you build your entire infrastructure around a tool whose direction you do not control, and your leverage is basically zero. The community’s answer was OpenTofu, a fully open-source fork under the Linux Foundation and CNCF, governed by a multi-vendor steering committee in which no single company holds a majority of votes. It uses the same HCL syntax and state file structure, and works with the same providers.
2. HCP Terraform and Terraform Enterprise platform lock-in
The tool and the platform you run are different, but together, HCP Terraform (formerly Terraform Cloud) and Terraform Enterprise (the self-hosted version) add a layer of proprietary features on top of the CLI, such as managed state, Sentinel policy enforcement, run tasks, SSO, etc.
Adopting these features reveals their practical value. Once your team relies on Sentinel policies and HCP-managed state and tasks, leaving means rebuilding everything elsewhere, or migrating to a different provider if that provider offers a migration kit you can easily use.
Platform lock-in is more subtle than tool lock-in because it develops features gradually. Locking into HCP Terraform happens slowly as you keep adopting convenient features.
3. Cloud provider lock-in
Cloud provider lock-in occurs when your infrastructure is so deeply tied to AWS, Azure, or Google Cloud that moving to a different cloud provider requires re-architecting large chunks of your stack.
There are situations when you are using managed services like DynamoDB or BigQuery, and they do not have an exact equivalent elsewhere, and that’s a deliberate trade-off. The real problem is when you couple yourself too closely to a provider-specific pattern, far beyond what the actual benefit justifies.
4. State backend lock-in
Terraform state is the source of truth for your infrastructure, and lives in your backend: S3, Azure Blob Storage, GCS, HCP, Terraform’s managed state, or a third-party platform.
In this case, state backend lock-in occurs when your backend choice ties you to a specific provider’s locking mechanism, encryption setup, or access model in a way that’s not easily replicated elsewhere.
For example, if your entire state strategy assumes an HCP-managed state with HCP locking, moving to a self-managed S3 state might mean rethinking locking, encryption, and access.
5. Module and registry lock-in
Modules help you keep things manageable at scale and are shared across registries. Most teams are using the HashiCorp-hosted Terraform Registry without considering alternatives.
So, module and registry lock-in can be caused by depending heavily on private modules hosted in a specific registry with a specific authentication model, or by writing modules with provider-specific assumptions baked in everywhere; the modules themselves become a lock-in vector.
Because of this, Opentofu added OCI registry support, so you can host modules and providers in any OCI-compatible registry instead of being tied to one vendor’s registry.
How Terraform helps avoid cloud provider lock-in
Terraform is one of the best defenses against cloud-provider lock-in, even though it can introduce other forms of lock-in, which surprises many people.
The fact that Terraform provides a single, consistent language and workflow across all providers eliminates the need to learn CloudFormation for AWS, ARM/Bicep for Azure, and Deployment Manager for GCP. You only need to write HCL once and use provider plugins to talk to each cloud.
If you want to adopt a second cloud or migrate from one to another, it is dramatically easier than with cloud-native tooling. In this case, you will not be throwing away your entire IaC investment and starting over; you are writing new provider blocks and new resources in the same language and the same pipelines you already know.
Terraform helps teams manage multi-cloud architectures effectively. You can have resources across AWS, Azure, and GCP in a single configuration, wire them together with data sources and outputs, and manage the whole thing through a single workflow. That portability of skills and workflow is the real anti-lock-in benefit, even when individual resources stay cloud-specific.
Terraform vs other IaC tools: Lock-in-trade-offs
Every IaC tool makes different trade-offs regarding vendor lock-in, so it is important to understand where Terraform fits.
| Tool | License | Cloud lock-in | Tooling/vendor lock-in |
| Terraform | BSL 1.1 | Low (multi-cloud) | Moderate (single vendor, now IBM/HashiCorp) |
| OpenTofu | MPL 2.0 (open source) | Low (multi-cloud) | Low (Linux Foundation, multi-vendor governance) |
| CloudFormation | Proprietary (AWS) | High (AWS only) | High (fully AWS-controlled) |
| Pulumi | Apache 2.0 (open source) | Low (multi-cloud) | Low to Moderate (If you are using Pulumi Cloud, this can be even high) |
| Azure Bicep/ARM | Open source | High (Azure only) | Moderate (Microsoft-controlled) |
OpenTofu was created specifically to address tooling lock-in. It has the same syntax, the same providers, the same state structure, but with open governance and an MPL 2.0 license that can’t be unilaterally changed by any one company. If one of your main concerns is that a vendor changes the rules again, OpenTofu is the most direct answer.
CloudFormation and Bicep give you the deepest first-party integration with their respective clouds, but you pay for it with total cloud lock-in. Also, they only work with one provider by design. On the other hand, Pulumi gives you real programming languages instead of HCL, but if you are leveraging Pulumi Cloud, you can still introduce platform lock-in.
The best practice is not to eliminate lock-in entirely; you only need to identify which types of lock-in are acceptable for your organization.
Best practices to avoid vendor lock-in with Terraform
You should consider that every dependency you take on has a different “cost of leave” and those costs range from trivial to catastrophic. You cannot eliminate lock-in, but its most expensive forms can be minimized. Here’s what is effective in practice:
- Keep your modules clean and provider-aware – You should write your modules with clear interfaces and avoid scattering provider-specific logic everywhere. It will be much easier to swap or extend your cloud-specific resources in the future if they are isolated behind well-defined module boundaries.
- Keep your state portable – Use a backend you control, such as S3 with native locking or Azure Blob Storage. If you are using a managed platform, make sure you know exactly where and how your state is hosted.
- Don’t over-adopt proprietary platform features – Every proprietary feature you build a workflow around is a future migration cost. You should adopt these features deliberately and choose open standards, such as OPA for policy-as-code, whenever they adequately address your needs.
- Stay compatible with OpenTofu – Even though you have no plans to migrate today, you should write configs that work with both Terraform and OpenTofu to keep your exit door open at basically zero cost. The best practice here is to pin your versions and avoid relying on features that only exist in one fork.
- Pin versions and audit dependencies – You need to know exactly what you depend on, so pin your Terraform/OpenTofu, provider, and module versions.
How managed platforms like Spacelift help reduce lock-in
Managed platforms that support multiple infrastructure-as-code tools help you reduce lock-in. Apart from Terraform, Spacelift supports OpenTofu, CloudFormation, Pulumi, Terragrunt, Ansible, and Kubernetes, making it easy to switch the infrastructure-as-code tool you are already using.
With Spacelift, you get policy as code through Open Policy Agent, and you can control what kind of resources your engineers can create, what parameters these resources have, how many approvals you need for a run, where to send notifications, and what happens when a pull request is open or merged.
In addition, Spacelift supports creating dependencies between your configurations, regardless of the tool you use, and sharing outputs via a feature called stack dependencies. These dependencies form a directed acyclic graph (DAG) and can extend to as many nested levels as you want.
Spacelift also supports self-service infrastructure creation through Blueprints and Templates and integrates natively with Backstage and ServiceNow to meet your developers where they are.
When it comes to AI, Spacelift has two powerful features: Intent and Intelligence. With Spacelift Intent, you can manage infrastructure resources with AI without needing to write any Terraform code, and these resources also have state to make the process easier. There is an open-source version of Intent available as well; you can try it here.
Intelligence is an AI assistant that lives directly in your Spacelift account and explains everything that you have in your platform, and it can also mutate resources if you use the agent mode.
Spacelift was the most cost-effective and flexible option, supporting multiple frameworks including OpenTofu and Pulumi — not just Terraform. This flexibility mitigated the risk of vendor lock-in and sprawl as Orbica’s tech stack expanded. The integrated Terraform registry also made it easier to manage a catalog of infrastructure modules to construct better abstractions and further improve the DX.
Key points
Vendor lock-in never meant that you can’t leave, but it’s about how much leaving a vendor will cost you. With Terraform, lock-in shows up in several layers: Terraform itself (IBM/HashiCorp owns it under BSL), the platform (HCP features like Sentinel), the module registry you have in HCP, and others as well.
The irony is that Terraform is both a lock-in risk and your strongest defense against cloud provider lock-in, since you can use HCL across all providers. OpenTofu directly addresses the tooling lock-in problem and uses the same syntax and providers as Terraform, but offers open governance from CNCF.
Spacelift helps you avoid vendor lock-in by supporting numerous IaC tools, policy-as-code via OPA, and self-service across any tool you use.
If you want to learn more about Spacelift, book a demo with one of our engineers.
Manage Terraform better with Spacelift
Orchestrate Terraform workflows with policy as code, programmatic configuration, context sharing, drift detection, resource visualization, and more.
