OpenTofu in Production: Migrating from Terraform (2026)

You wrote terraform apply ten thousand times and it never once asked what license you were on. Then, in August 2023, HashiCorp re-licensed Terraform under the Business Source License, and the question stopped being academic. Two years on, OpenTofu — the Linux Foundation fork that grew out of that moment — is no longer a protest project. It is a stable, drop-in, permissively-licensed engine that thousands of teams run in production, with capabilities Terraform’s open editions never shipped: native state encryption, early variable evaluation, and provider-defined functions, all in the open-source binary.

An OpenTofu Terraform migration is, for most stacks, surprisingly boring — and that is the highest praise you can give an infrastructure change. The hard part is not the swap itself. It is proving the swap changed nothing, wiring it through CI without a failed apply, and deciding what to do with the new capabilities once you have them. If you run hundreds of modules across a dozen accounts, that proof matters: a botched init against shared remote state can corrupt the one file that maps your code to your real cloud resources.

What this post covers: the license history in plain terms, the compatibility model and how to prove a zero-diff plan, a full step-by-step cutover, OpenTofu-only features worth adopting, multi-account fan-out, a worked example, rollback, and the gotchas nobody warns you about.

Context: why the fork happened and why it matters now

OpenTofu exists because Terraform stopped being open source. In August 2023, HashiCorp changed Terraform’s license from the permissive Mozilla Public License (MPL 2.0) to the Business Source License (BSL 1.1), a source-available license that restricts commercial use which “competes” with HashiCorp’s products. A coalition of vendors and users forked the last MPL-licensed code, donated it to the Linux Foundation, and the project became OpenTofu — community-governed, permissively licensed, and explicitly committed to staying open.

For an individual engineer, the Terraform license change rarely bites: you can still run Terraform’s free Community Edition internally. But for teams building products around IaC — CI platforms, self-service portals, managed-infra vendors — the BSL introduces legal ambiguity that legal departments hate. It bars offering the software in a way that competes with HashiCorp, and only converts to a permissive license after a multi-year delay per release. Regulated enterprises with strict open-source policies feel the same friction. OpenTofu removes that ambiguity entirely.

The deeper point is governance. OpenTofu sits under a Linux Foundation steering committee, is developed in the open, and its roadmap is decided by RFCs anyone can read. No single vendor controls it. That governance model is the real product here — you are buying predictability, not just code. The early releases were deliberately conservative drop-ins: same HCL, same state format, same provider protocol, which is exactly what makes a low-drama migration possible today.

The practical question in 2026 is no longer “is OpenTofu real?” It is. Linux Foundation backing, a broad provider and module ecosystem, and a steady release cadence have settled that. The real question is whether the migration is worth the disruption to your pipelines, your state files, and your team’s muscle memory. For most organizations the honest answer is: the migration cost is low and front-loaded, the licensing risk it removes is permanent, and the new features pay for the effort on their own. If you are still weighing engines more broadly, our Terraform vs Pulumi vs Crossplane IaC comparison frames where each tool fits before you commit. You can read the project’s own framing in the OpenTofu documentation. The rest of this guide assumes you have already decided OpenTofu is your target, and focuses on getting there safely.

The compatibility model: how to prove a zero-diff plan

OpenTofu forked from the Terraform 1.5.x line, so the HCL language, the state file format, the provider protocol, and the module ecosystem share a common lineage. In practice this means a clean OpenTofu run against your existing state should produce no changes. The migration is “safe” precisely when you can prove that — a tofu plan that reports zero resources to add, change, or destroy. The entire risk surface of the engine swap collapses to that single question: does tofu plan produce an empty diff?

Figure 1: OpenTofu and Terraform share HCL, state format, and the provider protocol, then diverge into engine-specific features above the common base.

Why compatibility holds (and where it doesn’t)

The two engines read the same *.tf files, write the same JSON state schema, and speak the same gRPC provider protocol. A provider built for Terraform works in OpenTofu and vice versa, because providers are independent binaries distributed separately from the engine. AWS, Google, Azure, Kubernetes, and Helm all work unchanged. The same is true for modules: a module resolves identically as long as its source address points somewhere both engines can reach.

The divergence sits at two layers. First, registries: OpenTofu has its own public registry at registry.opentofu.org, and tofu resolves bare provider names (like hashicorp/aws) through it by default. The provider artifacts are the same, but the resolution endpoint differs — which matters for air-gapped or mirror-based setups. Second, engine features: OpenTofu ships state encryption, early evaluation, and provider-defined functions in the open-source binary, and its version numbering does not track Terraform’s one-for-one. Some features that landed in newer Terraform releases were independently re-implemented in OpenTofu, sometimes with different syntax. Treat the two as cousins, not twins. Code that uses an OpenTofu-only feature is no longer portable back to Terraform — a one-way door you should walk through deliberately.

The zero-diff proof, step by step

The whole migration rests on one verifiable claim: switching binaries does not change your infrastructure. You prove it by capturing a Terraform plan, then an OpenTofu plan against the same state, and diffing the two. Do this in a non-production workspace first — never run your first tofu init against shared production state from a laptop.

# 1. Baseline: capture the current Terraform plan
terraform init
terraform plan -out=tf.plan -no-color > terraform-plan.txt 2>&1

# 2. Install OpenTofu alongside (does not touch Terraform),
#    then re-init the SAME directory with tofu
tofu init
tofu plan -no-color > tofu-plan.txt 2>&1

# 3. Diff the human-readable plans — you want NO resource changes
diff <(grep -E '^\s+[#~+-]' terraform-plan.txt) \
     <(grep -E '^\s+[#~+-]' tofu-plan.txt)

If the diff is empty and both plans say “No changes,” you have your proof. Small cosmetic differences in plan output formatting are expected and harmless; what must match is the set of resource actions. If OpenTofu proposes to change or recreate a resource that Terraform leaves alone, stop — that is a real signal (almost always a provider version pin or a registry-resolution mismatch), and you fix it before going further. To make this enforceable in automation, use the -detailed-exitcode flag, which returns 0 for no changes, 2 for changes present, and 1 for an error. That lets CI fail a migration build automatically whenever a plan is not clean.

Pin everything before you touch a binary

Reproducibility is the difference between a controlled migration and a 2 a.m. incident. Before installing anything, pin your Terraform version (via your version manager or CI image), and pin every provider with an exact version = constraint in required_providers. A floating constraint like ~> 5.0 invites a provider upgrade to sneak in during the migration, and then you cannot tell whether a diff came from OpenTofu or from a new provider release. Lock the lockfile too: commit .terraform.lock.hcl and treat it as the source of truth. OpenTofu honors the same lockfile format, so it carries over without conversion.

# Pin precisely before migrating — the only moving part should be the binary.
terraform {
  required_version = "= 1.5.7"          # last shared-lineage line, pin exactly
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "= 5.94.1"               # exact pin — adjust to your current stable
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "= 2.36.0"               # pin every provider, not just AWS
    }
  }
}

Step-by-step: migrating a production stack to OpenTofu

A production migrate to OpenTofu project has seven phases: audit, pin, install, init against existing remote state, fix registry and module sources, swap CI/CD, and verify. Done in order, each phase is independently revertible, and you never have a window where infrastructure is unmanaged. The sequence below assumes remote state in S3, GCS, or HCP Terraform / Terraform Cloud.

Figure 2: The seven-phase migration sequence — each phase is independently revertible, with explicit verification gates before the CI swap.

Phase 1 — Audit your stack

Inventory what you actually run. List every root module, every backend type, every provider and its version, and any Terraform Cloud / Enterprise features you depend on — run tasks, policy sets, the private module registry, Sentinel policies. The compatibility risk lives in the unusual corners, not the common path. Flag anything that uses HCP Terraform’s proprietary features, because those are the parts of the journey that need a project plan rather than a single command. Also audit your wrapper tooling here: Terragrunt, Atlantis, Spacelift, tfsec/Trivy, Checkov, and Infracost, plus any homegrown Makefile or script that hardcodes the terraform binary name.

# Quick inventory across a monorepo of stacks
find . -name 'backend.tf' -o -name '*.tf' -path '*backend*' | sort
grep -rhoP 'source\s*=\s*"\K[^"]+' --include='*.tf' . | sort -u   # module sources
grep -rA3 'required_providers' --include='*.tf' . | grep -E 'version|source'
grep -rl 'terraform ' --include='Makefile' --include='*.sh' .     # wrapper hardcoding

Phase 2 — Pin versions and lock providers

As covered above: set an exact Terraform version, exact provider versions, and commit the lockfile. This phase produces no behavioral change — it just freezes the world so the migration is the only moving part. Skipping it is the single most common reason a “clean” migration produces a confusing plan diff.

Phase 3 — Install OpenTofu

Install tofu on your workstation and, separately, into your CI image. The binaries coexist; installing OpenTofu does not remove or shadow Terraform, which is exactly what lets you run both during the transition. Use the official installer or your package manager, and pin the OpenTofu version the same way you pin everything else. Throughout this guide we say “current stable” rather than naming a patch version — check tofu version against the official OpenTofu install docs and pin whatever the latest stable line is at your migration date. Never use latest in CI; a surprise release can change a plan under you.

# Example: standalone install (review the script before piping to sh in CI)
curl --proto '=https' --tlsv1.2 -fsSL \
  https://get.opentofu.org/install-opentofu.sh -o install-opentofu.sh
chmod +x install-opentofu.sh
./install-opentofu.sh --install-method standalone
tofu version    # confirm the current stable line is installed

Phase 4 — Init against your existing remote state

This is the moment people fear, and it is anticlimactic. OpenTofu reads the same backend configuration and the same state file. You do not migrate state into a new format — there is no new format. You simply run tofu init in the directory whose backend already points at your S3 bucket, GCS bucket, or HCP Terraform workspace. Before that first init, pull an out-of-band backup of remote state so you always have a restore point.

# Back up the remote state out-of-band BEFORE anything else.
terraform state pull > state-backup-$(date +%Y%m%d).json

# Same backend block, new binary. No state copy, no import.
tofu init -input=false
tofu plan -detailed-exitcode    # expect exit 0: No changes. Infra matches config.

Backend-by-backend considerations:

• S3 backend: unchanged. Same bucket, same key, same DynamoDB lock table (or S3-native locking if you have adopted it). OpenTofu writes the same state schema, so a Terraform run and a tofu run can read each other’s state during the transition — which is precisely what makes a phased cutover and a fast rollback possible.
• GCS backend: unchanged. Same bucket and prefix; GCS object-based locking works identically.
• HCP Terraform / Terraform Cloud: more nuanced. OpenTofu can use the cloud block to talk to a workspace for state storage, but remote execution and proprietary features (Sentinel, run tasks, the private registry as Terraform implements it) are HashiCorp’s. If you depend on remote runs, plan to move execution into your own CI (next phase) and keep TFC for state only, or migrate state to S3/GCS. That backend move is a separate, larger project from the engine swap — do not conflate the two.

Phase 5 — Fix registry and module sources

Most module sources need no change. Git sources (git::https://...), local paths, and S3/GCS sources resolve identically. Provider sources resolve through OpenTofu’s registry by default; the artifacts are the same, but if you run a provider mirror or operate air-gapped, point your mirror at OpenTofu’s registry or pre-populate it. For the rare module that lived only in HCP Terraform’s private registry, mirror it to a Git repo or your own registry. Use explicit source addresses in required_providers so resolution is deterministic, and set installation policy in CLI config so it applies uniformly across CI.

# .terraformrc / tofu CLI config: pin registry + filesystem mirror for air-gapped CI
provider_installation {
  filesystem_mirror {
    path    = "/opt/tofu/providers"
    include = ["registry.opentofu.org/*/*"]
  }
  direct {
    exclude = ["registry.opentofu.org/*/*"]
  }
}

Phase 6 — Swap CI/CD

The riskiest phase is the pipeline, because that is where automation runs unattended. Change the binary, keep everything else. Below is a before/after for a typical GitHub Actions plan-and-apply job. The shape is identical; only the setup action and the command name change — checkout, plan, apply, and approvals are untouched.

Before (Terraform):

jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: "1.5.7"
      - run: terraform init -input=false
      - run: terraform plan -input=false -out=tf.plan

After (OpenTofu):

jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: opentofu/setup-opentofu@v1       # was hashicorp/setup-terraform
        with:
          tofu_version: "current-stable"        # pin a real line, never "latest"
      - run: tofu init -input=false
      - run: tofu plan -input=false -detailed-exitcode -out=tofu.plan

If your pipeline shells out to terraform from a wrapper (Atlantis, Terragrunt, a homegrown Makefile), update the wrapper’s binary target. Terragrunt supports a configurable IaC binary; Atlantis supports OpenTofu as a first-class engine. For a release or two, run both binaries in parallel: have CI run tofu plan and a shadow terraform plan, compare, and fail the build only if they disagree. That gives you continuous zero-diff proof until you trust the swap.

Phase 7 — Verify and retire the old binary

After CI has applied with OpenTofu successfully across all environments, remove the shadow Terraform step, delete setup-terraform from your workflows, and update local dev docs. Keep the pinned terraform available on workstations for one cycle as an escape hatch, then retire it. The migration is done when no pipeline and no runbook references terraform by name.

OpenTofu-specific features worth adopting

OpenTofu’s open binary ships three capabilities that change how you operate: client-side OpenTofu state encryption, early/variable evaluation in backend and module blocks, and provider-defined functions. None are required by the migration, but each removes a workaround you have probably been living with. State encryption alone justifies the switch for security-conscious teams.

Figure 3: State encryption sits between the engine and the backend, encrypting state and plan files with a pluggable key provider before anything touches remote storage.

State encryption with pluggable key providers

Terraform state has always been a security liability: it holds resource attributes, generated passwords, private keys, and connection strings in plaintext. The standard advice is “encrypt the bucket and lock down access.” OpenTofu goes further — it can encrypt the state file itself, client-side, before it ever reaches the backend. You configure an encryption block with a key provider (AWS KMS, GCP KMS, OpenBao/Vault, or a PBKDF2 passphrase) and a method (AES-GCM). The remote backend then stores ciphertext, not plaintext, and the data is in the clear only in memory during a run.

# encryption.tf — client-side state encryption with AWS KMS as the key provider
terraform {
  encryption {
    key_provider "aws_kms" "primary" {
      kms_key_id = "arn:aws:kms:us-east-1:111122223333:key/abcd-1234"
      region     = "us-east-1"
      key_spec   = "AES_256"
    }
    method "aes_gcm" "default" {
      keys = key_provider.aws_kms.primary
    }
    state {
      method   = method.aes_gcm.default
      enforced = true          # refuse to write unencrypted state
    }
    plan {
      method = method.aes_gcm.default   # encrypt plan files too
    }
  }
}

Two operational notes. First, roll encryption out in two phases. Start without enforced = true so OpenTofu can read your existing unencrypted state and write it back encrypted; once every workspace has migrated, flip enforced on. The fallback mechanism similarly lets you read with the old method while writing with the new one, then drop the fallback. Plan files (-out) are sensitive too — the plan block above encrypts those, which matters because CI artifacts often get retained longer than they should. Second, once state is encrypted you must never lose the key; treat the KMS key like a production secret with its own backup and access policy, because losing it makes the state unreadable. For background on the cryptographic mode, AES-GCM is specified in NIST SP 800-38D.

Early and variable evaluation

Terraform famously refused to let you use variables in backend blocks or in module source addresses. OpenTofu relaxed this with early evaluation: you can parameterize a backend’s bucket or key, or compute a module source, from variables and locals knowable before the main graph runs. This kills a whole category of wrapper scripts and templating that existed only to inject backend config per environment. Use it judiciously — over-dynamic configuration is hard to reason about, the same caution you would apply when a GitOps engine’s dynamism can outrun reviewability, as we discuss in our Argo CD vs Flux decision record.

variable "env" { type = string }

terraform {
  backend "s3" {
    bucket = "acme-tfstate-${var.env}"     # early eval: variable in backend
    key    = "platform/${var.env}/terraform.tfstate"
    region = "us-east-1"
  }
}

Provider-defined functions

Providers can now expose their own functions, callable directly in HCL — for example a provider shipping a function to build an ARN, parse a resource ID, or render a templated policy. Previously this logic lived in brittle locals with string interpolation or in external data sources. Provider-defined functions are typed, documented, and versioned with the provider, so they are far more robust than hand-rolled string surgery, and they keep configuration declarative instead of pushing you toward external programs.

Multi-account, multi-workspace fan-out

For platform teams, the migration is not one stack — it is dozens of root modules across many accounts and environments. The safe pattern is a fan-out where a single pinned OpenTofu version and a single CLI config flow out to every workspace, and each account’s state stays isolated in its own backend. You migrate in waves, never a flag day.

Figure 4: A single OpenTofu version and CLI config fan out from one CI control plane to isolated per-account state backends, each migrated and verified independently.

The mechanics: bake one canonical OpenTofu version and one CLI/registry config into the CI image, then iterate accounts in waves. Migrate non-production accounts first, run the shadow-plan comparison, and promote a wave to production only after every workspace in it reports zero diff. Because OpenTofu and Terraform read each other’s state, you can migrate account-by-account without a flag day — some accounts run tofu while others still run terraform, and nothing breaks as long as a single account is not driven by both engines simultaneously. Use a CI matrix to parallelize, and gate promotion on the aggregate result of the whole wave, not on individual stacks. This wave model is the same discipline you would apply to any fleet-wide change — the GitOps controllers in our Argo CD vs Flux decision record deploy with an equivalent progressive-rollout posture.

One subtle rule governs the fan-out: never let two engines manage the same workspace concurrently. They are state-compatible for sequential reads, but a concurrent terraform apply and tofu apply against one state file will fight over the lock and can corrupt state. One workspace, one engine at a time — enforce it with a CI mutex, with environment ownership, or by simply not having both jobs target the same backend. Mixed teams where some engineers run terraform locally while CI runs tofu are the classic source of subtle plan differences, so standardize the local toolchain fast.

A worked example: migrating a small networking stack

Consider a concrete, small stack: a VPC, two subnets, a security group, and an S3 bucket for app artifacts, with state in S3 and locking via DynamoDB. This is representative of the “leaf” stacks you will migrate by the hundred, so it is worth walking end to end.

# main.tf (existing, Terraform-authored)
terraform {
  required_version = "= 1.5.7"
  required_providers {
    aws = { source = "hashicorp/aws", version = "= 5.94.1" }
  }
  backend "s3" {
    bucket         = "acme-tfstate-prod"
    key            = "network/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "acme-tf-locks"
    encrypt        = true
  }
}

resource "aws_vpc" "main" {
  cidr_block = "10.20.0.0/16"
  tags       = { Name = "platform-vpc" }
}
# ... subnets, security group, and S3 bucket omitted for brevity

The migration of this stack is five commands, run in a feature branch:

# 1. Prove the baseline (Terraform sees no changes)
terraform init && terraform plan          # -> No changes.

# 2. Back up remote state out-of-band, then init the SAME dir with OpenTofu
terraform state pull > state-backup.json
tofu init                                 # reads the same S3 backend + lock table

# 3. Prove zero diff
tofu plan -detailed-exitcode              # -> exit 0: infrastructure matches config

# 4. Apply a trivial, reversible change to confirm OpenTofu can write state
#    (e.g., add tag managed_by=opentofu), then revert it
tofu apply -auto-approve

# 5. Verify the state round-trips: Terraform can still read it
terraform plan                            # -> No changes (state remains compatible)

Step 5 is the confidence-builder: after OpenTofu has written the state, the old Terraform binary still reads it cleanly. That proves the cutover is reversible at the state layer. Once you trust it for this stack, fold it into the CI fan-out and let automation carry the rest. As a bonus, this leaf stack is the perfect place to pilot state encryption — add the encryption block from earlier (unenforced first), apply, and confirm the S3 object is now ciphertext while plans still work, before you enforce it estate-wide.

If your stacks provision Kubernetes node infrastructure, the same migration discipline applies to the IaC that stands up autoscalers and node pools — sequence the engine migration so it is stable before you stress the data plane, and see how that infrastructure behaves under load in our Karpenter node autoscaling deep dive.

Rollback and cutover plan

Because OpenTofu and Terraform share the state format, rollback is genuinely simple — which is rare for an infrastructure migration and worth designing around explicitly rather than hoping you never need it. Your rollback is a binary swap, not a state restore.

Figure 5: The cutover gate runs a shadow plan; a clean diff promotes the engine, a mismatch triggers an immediate, low-risk revert to the previous binary.

If a stack misbehaves under OpenTofu, you revert the CI step to setup-terraform with the same pinned version, re-run, and you are back where you started — because the state file the OpenTofu run left behind is still a valid Terraform state. The exceptions are the one-way doors: any stack where you have applied an OpenTofu-only feature (state encryption, an early-evaluated backend, a provider-defined function) can no longer be read by Terraform. So sequence adoption deliberately: complete the engine cutover and let it bake before you turn on the OpenTofu-only features. Keep the “plain migration” reversible, and treat feature adoption as a separate, later project with its own gate.

Concretely, your cutover plan should include: an out-of-band state snapshot taken before the first apply in each account (S3 bucket versioning is enough); a pinned previous-Terraform escape hatch retained for one release cycle; a shadow-plan job that runs both engines and alerts on disagreement; a documented revert procedure (swap the setup action, re-run, re-pin Terraform); and a freeze on OpenTofu-only features until the base migration is signed off across all environments. With those in place, even a worst-case mistake has a restore point measured in minutes, not hours.

Team and process considerations

The technical migration is days; the human migration is weeks. Update your golden-path docs, your onboarding, and your local-dev setup scripts so new engineers install tofu, not terraform. Rename internal aliases and Makefile targets. Decide on a house style for whether you keep saying “terraform” colloquially — most teams do — while the binary is tofu. Communicate the why: the licensing rationale and the new features, so the change reads as an upgrade rather than churn.

The biggest soft risk is a long tail of forgotten automation: a cron job, a one-off bastion script, a colleague’s local wrapper that still calls terraform. Grep your whole org for the binary name and chase down every hit. Pair the rollout with a short enablement session so the team understands the zero-diff discipline and the one-way-door rule around OpenTofu-only features — those two concepts prevent the majority of self-inflicted incidents.

Trade-offs, gotchas, and what goes wrong

OpenTofu is low-risk, not zero-risk. The failure modes cluster around registries, ecosystem tooling, proprietary HashiCorp features, and the irreversibility of OpenTofu-only features — and every one of them is avoidable if you know it is coming.

The most common surprise is registry resolution. OpenTofu resolves providers through registry.opentofu.org; if your network allowlists only registry.terraform.io, or you run a mirror configured for the HashiCorp endpoint, tofu init fails to fetch providers. Fix it before migration by adding the OpenTofu registry to your allowlist or repointing your mirror. Second, the not-clean first plan — almost always a provider version that floated. Pin every provider and re-run before blaming OpenTofu; nine times out of ten the diff disappears.

Third, HCP Terraform / Enterprise features — Sentinel, run tasks, the private registry, remote execution — do not come with OpenTofu. If you rely on them, you are not doing a binary swap; you are re-platforming those capabilities (OpenBao for secrets, OPA/Conftest for policy, your own CI for execution). Scope that work separately and do not let it block the engine migration. Fourth, ecosystem tooling lag: most tools (Terragrunt, Atlantis, tfsec/Trivy, Infracost, Checkov) support OpenTofu, but a niche tool or an internal wrapper may hardcode the terraform binary or parse Terraform-specific output. Audit your toolchain in Phase 1. Fifth, the one-way door: once you use state encryption, early evaluation, or provider-defined functions, that configuration cannot be processed by Terraform — fine, it is why you migrated, but it removes your binary-swap rollback for those stacks, so adopt features after the base migration is stable. Finally, concurrent engines on one state will corrupt it; enforce one-engine-per-workspace. None of these is a dealbreaker, but each has burned someone who skipped the audit.

Practical recommendations

• Pin first. Exact Terraform version, exact provider versions, committed lockfile — before you install anything.
• Back up state out-of-band with state pull before any init.
• Prove zero diff. Capture a Terraform plan and an OpenTofu plan against the same state; gate promotion on a clean -detailed-exitcode.
• Migrate state in place. Same backend, same file. Run tofu init — never copy or import state.
• Shadow both engines in CI for a release or two, failing the build only on disagreement.
• Roll out state encryption in two phases — unenforced first so existing state migrates, then enforced = true.
• Wave the fan-out: non-prod first, promote per wave only on aggregate zero-diff, one engine per workspace.
• Defer OpenTofu-only features (state encryption, early eval, provider functions) until the base migration is signed off — they are a one-way door.
• Keep a Terraform escape hatch for one cycle, then retire it.
• Grep your whole org for the terraform binary name and update every wrapper, cron, and doc.

Frequently asked questions

Is OpenTofu a drop-in replacement for Terraform?

For the vast majority of stacks targeting the Terraform 1.5-era feature set, yes. OpenTofu reads the same HCL, the same state format, and the same provider protocol, so tofu init && tofu plan against existing remote state typically reports no changes. The practical test is a no-op plan, not a compatibility table. The exceptions are HashiCorp’s proprietary HCP Terraform features (Sentinel, run tasks, remote execution) and registry-resolution differences, which you handle in the audit phase before cutover.

Do I need to migrate or convert my Terraform state file?

No. There is no separate OpenTofu state format — the schema is shared. You point OpenTofu at the same backend (S3, GCS, or HCP Terraform for state storage) and run tofu init. The same state file is read and written by both engines, which is exactly what makes account-by-account migration and binary-swap rollback safe. Still, always pull an out-of-band backup with terraform state pull before your first init, as a restore point.

Is the OpenTofu Terraform migration reversible?

The base engine swap is reversible: revert your CI step to Terraform with the same pinned version and re-run, because OpenTofu leaves behind a valid Terraform state. The one-way exception is OpenTofu-only features — once you apply state encryption, early evaluation, or provider-defined functions, Terraform can no longer process that configuration. Adopt those features only after the base migration is stable, so the binary-swap rollback stays available throughout the risky part.

What is OpenTofu state encryption and why use it?

OpenTofu state encryption encrypts the state and plan files client-side, before they reach the backend, using a pluggable key provider (AWS KMS, GCP KMS, OpenBao, or a passphrase) and AES-GCM. Terraform state holds secrets in plaintext, so this protects them at rest beyond bucket-level encryption. Roll it out unenforced first so existing state migrates, then set enforced = true. Guard the key like a production secret — losing it makes the state unrecoverable.

Will my providers and modules still work after I migrate to OpenTofu?

Almost always. Providers are the same artifacts, distributed as independent binaries and resolved through OpenTofu’s registry instead of HashiCorp’s; Git, local, and object-storage module sources resolve identically. Use explicit source addresses and pinned versions to keep resolution deterministic. The only sources that need attention are providers behind a mirror configured for the HashiCorp endpoint and modules that lived solely in HCP Terraform’s private registry, which you mirror to Git or your own registry.

How does the Terraform license change affect me?

If you run Terraform internally for your own infrastructure, the BSL rarely restricts you — its main constraint is offering Terraform as a competing commercial product. The license change bites teams building products around IaC, managed-service vendors, and organizations with strict open-source policies, where “competing use” is ambiguous and legal teams want certainty. OpenTofu’s Linux Foundation governance and permissive license remove that ambiguity entirely, which is the durable reason most organizations migrate even when day-to-day usage would have been fine under the BSL.

Further reading

• Terraform vs Pulumi vs Crossplane: an IaC comparison for 2026 — decide which engine fits before you commit to a migration path.
• Argo CD vs Flux: a GitOps decision record — the progressive-rollout posture that mirrors a safe IaC fan-out.
• Karpenter node autoscaling in production: a deep dive — the Kubernetes node infrastructure your migrated stacks provision.
• OpenTofu documentation — the project’s own migration, state-encryption, and feature guides.
• NIST SP 800-38D (AES-GCM) — the cryptographic mode behind OpenTofu state encryption.

By Riju — about.