I Switched 100 AWS Accounts to OpenTofu

August 2023. HashiCorp announced they were changing Terraform's license from MPL to BSL.

The community's response was immediate: a fork called OpenTofu, backed by the Linux Foundation.

I watched from the sidelines for a year. Waited for stability. Waited for the dust to settle. Then, in late 2024, I migrated our entire infrastructure—100+ AWS accounts, 50+ Terraform modules, thousands of resources—to OpenTofu.

Here's what happened.

Why the License Change Matters

First, some context. The Business Source License (BSL) isn't "closed source." You can still use Terraform for free. The restriction: you can't use it to build competing products.

For most users, this changes nothing.

For platform teams building internal developer platforms? It gets murky. If your IDP provisions infrastructure, are you competing with Terraform Cloud? Probably not. But "probably" isn't comfortable when your infrastructure depends on it.

The bigger issue: trust. HashiCorp could change the license again. They could add more restrictions. The MPL was a promise. The BSL is a business decision.

OpenTofu, under the Linux Foundation, can't change its license without community approval. That governance model matters when you're betting your infrastructure on a tool.

OpenTofu vs Terraform: The Reality

Let me be clear: for day-to-day usage, they're nearly identical.

bash
# This works in both
terraform init
terraform plan
terraform apply

# This also works in both
tofu init
tofu plan
tofu apply

State files are compatible. Provider plugins are compatible. Module syntax is identical. If you have working Terraform code, it works in OpenTofu with one change: terraform → tofu.

The differences are in the margins:

OpenTofu Advantages

State encryption is built-in. Terraform stores state in plaintext. OpenTofu can encrypt it:

hcl
terraform {
  encryption {
    key_provider "pbkdf2" "main" {
      passphrase = var.state_passphrase
    }

    method "aes_gcm" "main" {
      keys = key_provider.pbkdf2.main
    }

    state {
      method = method.aes_gcm.main
    }
  }
}

This matters if you're storing state in S3 without additional encryption layers.

Early variable evaluation lets you use variables in backend configuration:

hcl
# Doesn't work in Terraform
terraform {
  backend "s3" {
    bucket = var.state_bucket  # Error!
  }
}

# Works in OpenTofu 1.7+
terraform {
  backend "s3" {
    bucket = var.state_bucket  # Valid
  }
}

This simplifies multi-environment setups significantly.

Terraform Advantages

Larger ecosystem. HashiCorp providers are tested against Terraform first. Most work fine with OpenTofu, but edge cases exist.

Commercial support. Terraform Cloud/Enterprise have no OpenTofu equivalent (yet). If you need vendor support, Terraform is still the choice.

Familiarity. Every DevOps engineer knows Terraform. OpenTofu requires explanation.

The Migration Plan

Here's how we approached 100+ accounts:

Phase 1: Assessment (2 weeks)

Audited everything:

bash
# Find all Terraform versions in use
find . -name "*.tf" -exec grep -l "required_version" {} \; | \
  xargs grep "required_version" | sort -u

We were on Terraform 1.5.x across most modules. OpenTofu 1.6+ is compatible with Terraform 1.6 syntax, so we needed to update some modules first.

Also checked:

Phase 2: Tooling Updates (1 week)

Updated CI/CD first. Our GitHub Actions workflow:

yaml
# Before
- name: Setup Terraform
  uses: hashicorp/setup-terraform@v3
  with:
    terraform_version: 1.5.7

# After
- name: Setup OpenTofu
  uses: opentofu/setup-opentofu@v1
  with:
    tofu_version: 1.6.2

Local development switched to tofuenv (drop-in replacement for tfenv):

bash
# Install tofuenv
brew install tofuenv

# Install OpenTofu version
tofuenv install 1.6.2
tofuenv use 1.6.2

# Alias for muscle memory
alias terraform='tofu'

Phase 3: Non-Production First (2 weeks)

Started with sandbox accounts. The process per account:

bash
# 1. Backup state (paranoid but wise)
aws s3 cp s3://state-bucket/terraform.tfstate ./backup/

# 2. Run tofu init (downloads providers, validates config)
tofu init

# 3. Run tofu plan (should show no changes if compatible)
tofu plan

First few accounts: zero issues. Plan showed no changes. State compatible.

Then we hit edge cases.

The Edge Cases

Provider version constraints. Some modules pinned exact provider versions that didn't exist in OpenTofu registry yet:

hcl
# This failed
required_providers {
  aws = {
    source  = "hashicorp/aws"
    version = "5.31.0"  # Not yet mirrored
  }
}

# Fixed by loosening constraint
required_providers {
  aws = {
    source  = "hashicorp/aws"
    version = "~> 5.0"
  }
}

Backend initialization. One legacy module used -backend-config files with Terraform-specific paths. Needed updating.

Lock files. .terraform.lock.hcl files contained Terraform-specific hashes. Regenerated with tofu init -upgrade.

Phase 4: Production Migration (3 weeks)

Production accounts followed the same process, but with more ceremony:

We did 5 accounts per day. Slow and steady.

One Year Later

What we gained:

What we lost:

What we learned:

It's Just Infrastructure as Code

The tool is not the value. Our modules, our patterns, our automation—that's the value. Whether terraform apply or tofu apply runs it is almost irrelevant.

The migration was less about technology and more about governance. We chose open source governance over corporate governance. That's a values decision as much as a technical one.

Community Velocity Is Real

OpenTofu merged state encryption in months. This feature was requested in Terraform for years. The Linux Foundation governance model enables faster community contribution.

We've already contributed two bug fixes upstream. Try doing that with Terraform.

The Ecosystem Will Split

This is my prediction: we'll see OpenTofu-only features and Terraform-only features diverge. Provider authors will have to choose which to support first.

For now, the AWS provider works identically in both. But in 2-3 years? The communities may look very different.

Should You Switch?

Switch if:

Stay on Terraform if:

Wait if:

The Commands You Need

If you decide to try it:

bash
# Install OpenTofu
brew install opentofu

# Check existing Terraform state compatibility
tofu init
tofu plan  # Should show no changes

# If it works, you're done
# Terraform and OpenTofu can coexist

# Alias for convenience
echo 'alias tf="tofu"' >> ~/.zshrc

Test in non-production. Verify plans show no changes. Migrate at your own pace.

The Bigger Picture

The Terraform fork isn't about Terraform. It's about who controls developer infrastructure.

Five years ago, we standardized on Terraform because it was the best open source IaC tool. HashiCorp built a business on that community trust. Then they changed the license.

OpenTofu exists because the community decided: if we're going to depend on a tool, we should control it.

I don't know if OpenTofu will "win." But I know our infrastructure runs on something the community owns. That matters more than the name on the CLI.

The migration took 6 weeks. The decision took a year. Sometimes the hard part isn't the technology—it's committing to change.