OpenTofu vs Terraform: quando migrar sem quebrar a infraestrutura

Não é mais a mesma ferramenta com outro nome#

Durante quase uma década, "infraestrutura como código" e "Terraform" foram praticamente sinônimos. Essa época acabou. Hoje existem duas ferramentas que nasceram do mesmo código: o Terraform, que desde 2025 pertence à IBM, e o OpenTofu, um fork comunitário sob a Linux Foundation.

A pergunta que chega aos buscadores já não é "qual é melhor?", e sim algo muito mais prático: vale a pena mudar, e o que eu arrisco se fizer isso?

A resposta curta: depende de três coisas, e nenhuma é estritamente técnica. Importa se o projeto é novo, se você depende de peças comerciais da HashiCorp e se a licença do Terraform representa um risco jurídico para a sua organização. Neste guia, vemos como chegamos até aqui, o que diverge entre os dois motores, uma árvore de decisão e o procedimento de migração seguro recomendado pela própria documentação do OpenTofu.

Para se aprofundar: Como separar ambientes (dev, staging e produção) na AWS

Documentação: Linux Foundation · Lançamento do OpenTofu (2023) ↗ · HashiCorp · Licença do Terraform (BUSL 1.1) no GitHub ↗

Como chegamos aqui: licença, fork e aquisição#

Em agosto de 2023, a HashiCorp mudou a licença do Terraform da Mozilla Public License 2.0 (MPL 2.0), que é open source, para a Business Source License 1.1 (BSL ou BUSL). A BSL permite usar o software, mas restringe oferecê-lo em produtos que concorram com os da HashiCorp. O arquivo LICENSE do repositório do Terraform reflete hoje essa licença.

A resposta da comunidade foi rápida. Um grupo de empresas e desenvolvedores fez um fork da última versão com licença MPL, primeiro com o nome OpenTF, e em 20 de setembro de 2023 a Linux Foundation anunciou o OpenTofu como alternativa open source com governança neutra.

Depois veio a aquisição. A IBM anunciou em abril de 2024 a compra da HashiCorp por um valor empresarial de US$ 6,4 bilhões e a concluiu em fevereiro de 2025. A licença não mudou com a aquisição, mas reacendeu uma dúvida legítima: a direção comercial do Terraform agora depende de um único grande fornecedor.

Três anos depois, a pergunta sobre se o OpenTofu sobreviveria já tem resposta. A CNCF aceitou o OpenTofu em 23 de abril de 2025 como projeto de nível Sandbox, e plataformas como o GitLab documentam hoje sua integração de infraestrutura como código em torno do OpenTofu. A melhor pergunta já não é se você deve considerar o OpenTofu, mas quando a diferença de licença e governança realmente importa para o seu time.

Documentação: HashiCorp · Licença do Terraform (BUSL 1.1) no GitHub ↗ · Linux Foundation · Lançamento do OpenTofu (2023) ↗ · IBM · Anúncio da compra da HashiCorp (2024) ↗ · IBM · Conclusão da compra da HashiCorp (2025) ↗ · CNCF · Ficha do projeto OpenTofu ↗ · GitLab Docs · Infrastructure as Code com OpenTofu ↗

O que realmente mudou: já não são o mesmo fork#

No primeiro ano, o OpenTofu era praticamente um clone com outro nome. Isso já não é verdade: os dois produtos divergiram e cada um tem funcionalidades que o outro não tem.

O OpenTofu se concentrou em funcionalidades para quem escreve o código:

• Criptografia nativa de state e plan (desde a 1.7), seu diferencial mais citado.
• Avaliação antecipada de variáveis e locals (desde a 1.8): você pode usá-las em blocos backend, na origem de módulos e na configuração de criptografia.
• Iteração de providers com for_each (desde a 1.9), útil para deploys multirregião sem duplicar blocos.
• A flag -exclude (desde a 1.9) para planejar deixando certos recursos de fora.

Um detalhe que muitas comparações omitem: as funções definidas por provider chegaram ao OpenTofu na 1.7, mas o Terraform também as suporta desde a 1.8, então elas já não são um diferencial.

O Terraform, por sua vez, investiu na sua plataforma comercial: Stacks para orquestrar várias configurações como uma unidade, Sentinel para policy as code e HCP Terraform como plataforma gerenciada de execução, state, permissões e auditoria.

terraform {
  encryption {
    key_provider "pbkdf2" "main" {
      passphrase = var.state_passphrase # mínimo de 16 caracteres; em produção, prefira um KMS
    }

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

    # Só durante a migração: permite ler o state ainda sem criptografia.
    method "unencrypted" "migration" {}

    state {
      method = method.aes_gcm.main
      fallback {
        method = method.unencrypted.migration
      }
    }
  }
}

A boa notícia para quem está em dúvida é que o núcleo continua compatível: a mesma linguagem HCL, o mesmo modelo de providers e o mesmo formato de state. Por isso, migrar não reescreve a sua infraestrutura; na prática, muda o binário que a executa.

Documentação: OpenTofu · Novidades da 1.7 ↗ · OpenTofu · Novidades da 1.8 ↗ · OpenTofu · Novidades da 1.9 ↗ · HashiCorp · Provider-defined functions (Terraform 1.8+) ↗ · HashiCorp · Terraform Stacks ↗ · HashiCorp · Sentinel ↗ · HashiCorp · HCP Terraform ↗ · OpenTofu · Criptografia de state e plan ↗

A árvore de decisão: três perguntas, em ordem#

Em vez de um veredito "X é melhor que Y", responda três perguntas em ordem. A primeira que der um destino claro vence.

Pergunta 1: é um projeto novo, sem investimento prévio em Terraform? Se você está começando do zero, o OpenTofu é uma opção padrão razoável: mesma sintaxe, mesmo ecossistema de providers, criptografia de state e nenhuma ambiguidade de licença. Enquanto você não ativar funcionalidades exclusivas, voltar para o Terraform continua viável.

Pergunta 2: você depende do HCP Terraform, de Stacks ou do Sentinel, ou a sua área de compras exige HashiCorp/IBM como fornecedor com suporte? Então fique no Terraform, ou migre apenas os workspaces que não dependem dessas peças. O OpenTofu não oferece equivalentes diretos desses produtos comerciais; existem plataformas de terceiros que os cobrem parcialmente, mas isso é outra avaliação.

Pergunta 3: a BSL representa um risco jurídico para você? Isso se aplica se você vende um serviço ou constrói um produto em torno de infraestrutura como código, ou se o seu time jurídico ou de compliance aponta a BSL como risco. Nesse caso, migre para o OpenTofu, que mantém a licença MPL 2.0 sob a Linux Foundation. Peça sempre a interpretação do seu time jurídico: este guia não é assessoria jurídica.

Respondeu "não" às três? Então migrar é opcional. Para uso interno sem preocupação com licença, você pode ficar no Terraform sem problema, embora valha avaliar o OpenTofu pelas funcionalidades e para não ficar preso a um único fornecedor.

Documentação: HashiCorp · Licença do Terraform (BUSL 1.1) no GitHub ↗ · HashiCorp · HCP Terraform ↗ · HashiCorp · Terraform Stacks ↗ · HashiCorp · Sentinel ↗

Como migrar sem quebrar nada#

Se você decidir mudar, a mecânica é propositalmente entediante, e isso é bom. O padrão seguro não é um big bang, e sim workspace por workspace, como descreve o guia oficial:

• Faça backup do state e do código. Com backend remoto, use o mecanismo do próprio backend (por exemplo, versionamento do bucket S3) e trabalhe em uma branch de migração.
• Instale o binário tofu ao lado do terraform. Eles podem conviver na mesma máquina e no mesmo pipeline.
• Execute tofu init e depois tofu plan contra um workspace. O resultado esperado é "No changes" ou o mesmo plan que você veria com o Terraform. Se aparecerem mudanças inesperadas, não aplique: investigue.
• Execute tofu apply mesmo sem mudanças, para que o OpenTofu atualize o formato do state se necessário.
• Faça uma mudança pequena e não crítica, como adicionar uma tag, e aplique com tofu para confirmar que ele consegue gerenciar a infraestrutura.

# 1. Backup (backend local; no remoto, use versionamento ou snapshots)
cp terraform.tfstate terraform.tfstate.pre-tofu

# 2. Verificar o binário
tofu --version

# 3. Inicializar: baixa os providers do registry do OpenTofu
tofu init

# 4. O plan deve sair vazio ou idêntico ao do Terraform
tofu plan -detailed-exitcode
# exit 0 = sem mudanças, 2 = há mudanças (revisar antes de aplicar), 1 = erro

# 5. Rollback se algo der errado
terraform init && terraform plan

Dois alertas que evitam dor de cabeça. Primeiro: o state é compatível nos dois sentidos, então você pode voltar para o Terraform, exceto se ativar a criptografia de state do OpenTofu, que deixa esses arquivos ilegíveis para o Terraform. Ativar a criptografia é, na prática, uma decisão sem volta.

Segundo: a sintaxe começou a divergir. Há construções que só existem em um deles, como variáveis em blocos backend no OpenTofu ou os arquivos de Stacks no Terraform, e que falham no outro. Se o seu sistema usa várias configurações ligadas com terraform_remote_state, a documentação do OpenTofu pede cuidado adicional com a ordem de migração.

Documentação: OpenTofu · Guia de migração a partir do Terraform ↗ · OpenTofu · Instalação ↗ · OpenTofu · Criptografia de state e plan ↗ · OpenTofu · Novidades da 1.8 ↗

Antes da produção: compare os plans em staging#

O erro mais frequente é assumir compatibilidade total porque a linguagem é a mesma. A regra prática é simples: não migre um workspace de produção sem antes comparar os plans em um ambiente isolado.

• Clone o código em um ambiente de staging e execute tofu init para confirmar que todos os providers e módulos são resolvidos pelo registry do OpenTofu.
• Execute terraform plan e tofu plan sobre o mesmo state e compare os recursos planejados. Qualquer diferença é um ponto de atrito que você precisa entender.
• Valide o backend de state (S3, GCS, Azure Blob ou outro) e o tratamento de secrets com o binário tofu.
• Atualize o pipeline de CI/CD trocando o binário sem mudar a lógica, e opere em staging por um tempo razoável antes de mexer na produção.

terraform plan -out=tf.plan
tofu plan -out=tofu.plan

terraform show -json tf.plan | jq -S '[.resource_changes[] | {address, actions: .change.actions}]' > tf.json
tofu show -json tofu.plan    | jq -S '[.resource_changes[] | {address, actions: .change.actions}]' > tofu.json

diff tf.json tofu.json && echo "Plans equivalentes"

Se você usa o Terraform CLI sem Sentinel, sem Stacks e sem serviços gerenciados da HashiCorp, o risco técnico de migrar costuma ser baixo e, na maioria dos casos, não exige mudar o HCL. Mas baixo não é zero: um provider com comportamento diferente ou uma versão não publicada no registry do OpenTofu pode travar a migração. Valide antes, migre depois.

Documentação: HashiCorp · terraform plan ↗ · OpenTofu · Guia de migração a partir do Terraform ↗

Quando não migrar#

Sejamos justos: o Terraform não quebrou e tem vantagens que importam para certos times. O HCP Terraform é uma plataforma gerenciada madura, com execução remota, gerenciamento de state, permissões e políticas, que o ecossistema OpenTofu não replica ponto a ponto como produto pronto para uso. O suporte comercial da HashiCorp e da IBM e a documentação acumulada ao longo dos anos são motivos legítimos para ficar.

A conclusão sensata não é que todo mundo deva padronizar em um único motor amanhã. É que o OpenTofu já tem impulso próprio suficiente para que suas vantagens de licença e governança não venham com um custo técnico relevante. Para times que não estão presos a fluxos específicos do HCP Terraform, o OpenTofu é cada vez mais uma opção padrão razoável.

Seja qual for a sua decisão, documente-a: quais workspaces usam cada motor, qual versão você fixa no CI e se a criptografia de state está ativa. Essa clareza evita o pior cenário, que é ter dois motores em paralelo sem que ninguém saiba qual governa cada peça.

Documentação: HashiCorp · HCP Terraform ↗ · CNCF · Ficha do projeto OpenTofu ↗