OpenTofu vs Terraform: cuándo migrar sin romper tu infraestructura

Ya no es la misma herramienta con otro nombre#

Durante casi una década, «infraestructura como código» y «Terraform» fueron casi sinónimos. Esa época terminó. Hoy hay dos herramientas que nacieron del mismo código: Terraform, que desde 2025 pertenece a IBM, y OpenTofu, un fork comunitario bajo la Linux Foundation.

La pregunta que llega a los buscadores ya no es «¿cuál es mejor?», sino algo mucho más práctico: ¿me conviene moverme, y qué arriesgo si lo hago?

La respuesta corta: depende de tres cosas, y ninguna es estrictamente técnica. Importa si el proyecto es nuevo, si dependes de piezas comerciales de HashiCorp y si la licencia de Terraform representa un riesgo legal para tu organización. En esta guía vemos cómo llegamos aquí, qué diverge entre ambos motores, un árbol de decisión y el procedimiento de migración seguro que recomienda la propia documentación de OpenTofu.

Documentación: Linux Foundation · Lanzamiento de OpenTofu (2023) ↗ · HashiCorp · Licencia de Terraform (BUSL 1.1) en GitHub ↗

Cómo llegamos aquí: licencia, fork y compra#

En agosto de 2023, HashiCorp cambió la licencia de Terraform de la Mozilla Public License 2.0 (MPL 2.0), que es open source, a la Business Source License 1.1 (BSL o BUSL). La BSL permite usar el software, pero restringe ofrecerlo en productos que compitan con los de HashiCorp. El archivo LICENSE del repositorio de Terraform refleja hoy esa licencia.

La respuesta de la comunidad fue rápida. Un grupo de empresas y desarrolladores forkeó la última versión con licencia MPL, primero con el nombre OpenTF, y el 20 de septiembre de 2023 la Linux Foundation anunció OpenTofu como alternativa open source con gobernanza neutral.

Después llegó la compra. IBM anunció en abril de 2024 la adquisición de HashiCorp por un valor empresarial de 6.400 millones de dólares y la completó en febrero de 2025. La licencia no cambió con la compra, pero reavivó una duda legítima: la dirección comercial de Terraform depende ahora de un único gran proveedor.

Tres años después, la pregunta de si OpenTofu sobreviviría ya tiene respuesta. La CNCF aceptó a OpenTofu el 23 de abril de 2025 como proyecto de nivel Sandbox, y plataformas como GitLab documentan hoy su integración de infraestructura como código alrededor de OpenTofu. La mejor pregunta ya no es si considerar OpenTofu, sino cuándo la diferencia de licencia y gobernanza importa de verdad para tu equipo.

Documentación: HashiCorp · Licencia de Terraform (BUSL 1.1) en GitHub ↗ · Linux Foundation · Lanzamiento de OpenTofu (2023) ↗ · IBM · Anuncio de compra de HashiCorp (2024) ↗ · IBM · Cierre de la compra de HashiCorp (2025) ↗ · CNCF · Ficha del proyecto OpenTofu ↗ · GitLab Docs · Infrastructure as Code con OpenTofu ↗

Qué cambió de verdad: ya no son el mismo fork#

Durante el primer año, OpenTofu era prácticamente un clon con otro nombre. Eso ya no es cierto: los dos productos divergieron y cada uno tiene funciones que el otro no.

OpenTofu se enfocó en funciones para quien escribe el código:

• Cifrado nativo de state y plan (desde la 1.7), su diferenciador más citado.
• Evaluación temprana de variables y locals (desde la 1.8): puedes usarlas en bloques backend, en el origen de módulos y en la configuración de cifrado.
• Iteración de providers con for_each (desde la 1.9), útil para despliegues multirregión sin duplicar bloques.
• El flag -exclude (desde la 1.9) para planificar dejando fuera ciertos recursos.

Un matiz que muchas comparativas omiten: las funciones definidas por provider llegaron a OpenTofu en la 1.7, pero Terraform también las soporta desde la 1.8, así que ya no son un diferenciador.

Terraform, por su parte, invirtió en su plataforma comercial: Stacks para orquestar varias configuraciones como una unidad, Sentinel para policy as code y HCP Terraform como plataforma gestionada de ejecución, state, permisos y auditoría.

terraform {
  encryption {
    key_provider "pbkdf2" "main" {
      passphrase = var.state_passphrase # mínimo 16 caracteres; mejor un KMS en producción
    }

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

    # Solo durante la migración: permite leer el state aún sin cifrar.
    method "unencrypted" "migration" {}

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

La buena noticia para quien duda es que el núcleo sigue siendo compatible: el mismo lenguaje HCL, el mismo modelo de providers y el mismo formato de state. Por eso migrar no reescribe tu infraestructura; en la práctica, cambia el binario que la ejecuta.

Documentación: OpenTofu · Novedades de la 1.7 ↗ · OpenTofu · Novedades de la 1.8 ↗ · OpenTofu · Novedades de la 1.9 ↗ · HashiCorp · Provider-defined functions (Terraform 1.8+) ↗ · HashiCorp · Terraform Stacks ↗ · HashiCorp · Sentinel ↗ · HashiCorp · HCP Terraform ↗ · OpenTofu · Cifrado de state y plan ↗

El árbol de decisión: tres preguntas en orden#

En lugar de un veredicto «X es mejor que Y», responde tres preguntas en orden. La primera que te dé un destino claro, gana.

Pregunta 1: ¿es un proyecto nuevo, sin inversión previa en Terraform? Si arrancas de cero, OpenTofu es una opción por defecto razonable: misma sintaxis, mismo ecosistema de providers, cifrado de state y sin ambigüedad de licencia. Mientras no actives funciones exclusivas, volver a Terraform sigue siendo viable.

Pregunta 2: ¿dependes de HCP Terraform, Stacks o Sentinel, o tu área de compras exige a HashiCorp/IBM como proveedor con soporte? Entonces quédate en Terraform, o migra solo los workspaces que no dependan de esas piezas. OpenTofu no ofrece equivalentes directos de esos productos comerciales; existen plataformas de terceros que los cubren parcialmente, pero es otra evaluación.

Pregunta 3: ¿la BSL representa un riesgo legal para ti? Aplica si vendes un servicio o construyes un producto alrededor de infraestructura como código, o si tu equipo legal o de cumplimiento marca la BSL como riesgo. En ese caso migra a OpenTofu, que mantiene licencia MPL 2.0 bajo la Linux Foundation. Pide siempre la interpretación de tu equipo legal: esta guía no es asesoría jurídica.

¿Respondiste «no» a las tres? Entonces migrar es opcional. Para uso interno sin preocupación de licencia puedes quedarte en Terraform sin problema, aunque vale la pena evaluar OpenTofu por sus funciones y para no quedar atado a un único proveedor.

Documentación: HashiCorp · Licencia de Terraform (BUSL 1.1) en GitHub ↗ · HashiCorp · HCP Terraform ↗ · HashiCorp · Terraform Stacks ↗ · HashiCorp · Sentinel ↗

Cómo migrar sin romper nada#

Si decides moverte, la mecánica es deliberadamente aburrida, y eso es bueno. El patrón seguro no es un big bang sino workspace por workspace, tal como describe la guía oficial:

• Respalda el state y el código. Con backend remoto, usa el mecanismo del backend (por ejemplo, versionado del bucket S3) y trabaja en una rama de migración.
• Instala el binario tofu junto a terraform. Pueden convivir en la misma máquina y en el mismo pipeline.
• Ejecuta tofu init y luego tofu plan contra un workspace. El resultado esperado es «No changes» o el mismo plan que verías con Terraform. Si aparecen cambios inesperados, no apliques: investiga.
• Ejecuta tofu apply aunque no haya cambios, para que OpenTofu actualice el formato del state si hace falta.
• Haz un cambio pequeño y no crítico, como añadir un tag, y aplícalo con tofu para confirmar que puede gestionar la infraestructura.

# 1. Respaldo (backend local; en remoto usa versionado o snapshots)
cp terraform.tfstate terraform.tfstate.pre-tofu

# 2. Verificar el binario
tofu --version

# 3. Inicializar: descarga providers desde el registro de OpenTofu
tofu init

# 4. El plan debe salir vacío o idéntico al de Terraform
tofu plan -detailed-exitcode
# exit 0 = sin cambios, 2 = hay cambios (revisar antes de aplicar), 1 = error

# 5. Rollback si algo sale mal
terraform init && terraform plan

Dos advertencias que ahorran dolores. Primero: el state es compatible en ambas direcciones, así que puedes volver a Terraform, salvo si activas el cifrado de state de OpenTofu, que deja esos archivos ilegibles para Terraform. Activar cifrado es, en la práctica, una decisión de una sola vía.

Segundo: la sintaxis empezó a divergir. Hay construcciones que solo existen en uno, como variables en bloques backend en OpenTofu o los archivos de Stacks en Terraform, y fallan en el otro. Si tu sistema usa varias configuraciones enlazadas con terraform_remote_state, la documentación de OpenTofu pide cuidado adicional con el orden de migración.

Documentación: OpenTofu · Guía de migración desde Terraform ↗ · OpenTofu · Instalación ↗ · OpenTofu · Cifrado de state y plan ↗ · OpenTofu · Novedades de la 1.8 ↗

Antes de producción: compara planes en staging#

El error más frecuente es asumir compatibilidad total porque el lenguaje es el mismo. La regla práctica es simple: no migres un workspace de producción sin comparar planes antes en un entorno aislado.

• Clona el código en un entorno de staging y ejecuta tofu init para confirmar que todos los providers y módulos se resuelven desde el registro de OpenTofu.
• Ejecuta terraform plan y tofu plan sobre el mismo state y compara los recursos planificados. Cualquier diferencia es un punto de fricción que debes entender.
• Valida el backend de state (S3, GCS, Azure Blob u otro) y el manejo de secretos con el binario tofu.
• Actualiza el pipeline de CI/CD reemplazando el binario sin cambiar la lógica, y opera en staging un tiempo razonable antes de tocar producción.

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 "Planes equivalentes"

Si usas Terraform CLI sin Sentinel, sin Stacks y sin servicios gestionados de HashiCorp, el riesgo técnico de migrar suele ser bajo, y en la mayoría de los casos no requiere cambiar el HCL. Pero bajo no es cero: un provider con un comportamiento distinto o una versión no publicada en el registro de OpenTofu puede frenar la migración. Valida antes, migra después.

Documentación: HashiCorp · terraform plan ↗ · OpenTofu · Guía de migración desde Terraform ↗

Cuándo no migrar#

Para ser justos: Terraform no se rompió y tiene ventajas que importan a ciertos equipos. HCP Terraform es una plataforma gestionada madura, con ejecución remota, gestión de state, permisos y políticas, que el ecosistema OpenTofu no replica punto por punto como producto llave en mano. El soporte comercial de HashiCorp e IBM y la documentación acumulada durante años son razones legítimas para quedarse.

La conclusión sensata no es que todos deban estandarizar en un motor mañana. Es que OpenTofu ya tiene suficiente impulso propio como para que sus ventajas de licencia y gobernanza no vengan con un costo técnico importante. Para equipos que no estén casados con flujos específicos de HCP Terraform, OpenTofu es cada vez más una opción por defecto razonable.

Sea cual sea tu decisión, documéntala: qué workspaces usan cada motor, qué versión fijas en CI y si el cifrado de state está activo. Esa claridad evita el peor escenario, que es tener dos motores en paralelo sin que nadie sepa cuál gobierna cada pieza.

Documentación: HashiCorp · HCP Terraform ↗ · CNCF · Ficha del proyecto OpenTofu ↗