OpenTofu vs Terraform: cómo decidir si debes migrar sin romper tu infraestructura

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, ahora de IBM, y OpenTofu, bajo la Linux Foundation— y la pregunta que llega a Google ya no es "¿cuál es mejor?", sino algo más práctico: ¿me conviene moverme, y qué arriesgo si lo hago?

La respuesta corta es: depende de tres cosas, ninguna de ellas técnica. Vamos por partes.

1. Cómo llegamos aquí

En agosto de 2023, HashiCorp cambió la licencia de Terraform de open source (MPL 2.0) a la Business Source License (BSL), que restringe usar Terraform "de forma competitiva" contra sus propios productos. La comunidad reaccionó en días: un grupo de empresas forkeó la última versión libre y creó OpenTofu, hospedado en la Linux Foundation.

Luego IBM compró HashiCorp por unos 6.400 millones de dólares (anunciado en 2024, cerrado a inicios de 2025). La licencia no cambió, pero la compra reavivó las dudas: ahora un solo gran proveedor controla la dirección comercial de Terraform.

Figura 1 — Lo que empezó como protesta de la comunidad hoy es un proyecto con respaldo de la CNCF y adopción empresarial real.

Tres años después, la pregunta de si OpenTofu sobreviviría ya está respondida. Entró a la CNCF en abril de 2025, organizaciones como Fidelity migraron decenas de miles de archivos de state, y herramientas como GitLab deprecaron sus plantillas de Terraform por motivos de licencia. La mejor pregunta en 2026 no es si considerar OpenTofu, sino cuándo la diferencia de licencia y gobernanza importa de verdad para tu equipo.

2. 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 cosas que el otro no tiene.

OpenTofu se enfocó en features que le importan a quien escribe el código: cifrado de state nativo (su diferenciador más citado), provider for_each y funciones definidas por provider, backends dinámicos y ciclos de release más rápidos. Terraform, por su parte, invirtió en su plataforma comercial: Stacks para orquestar configuraciones, Sentinel para policy-as-code, la plataforma gestionada HCP Terraform y, ya con IBM, la integración con su ecosistema (Project Infragraph, watsonx, OpenShift).

Figura 3 — El núcleo sigue siendo común, así que cambiar no toca tus definiciones de infraestructura. La diferencia está en los extremos.

La buena noticia para quien duda: el núcleo es compatible. Más de 3.900 providers, la misma sintaxis HCL y el mismo formato de state funcionan en ambos. Por eso migrar no reescribe tu infraestructura; en la práctica es cambiar el binario que la ejecuta.

3. El árbol de decisión

Aquí está el método. En lugar de un "X es mejor que Y", responde tres preguntas en orden. La primera que te dé un destino claro, gana.

Figura 2 — Tres preguntas, no un veredicto. La licencia y la gobernanza pesan más que la comparación de features para la mayoría de los equipos.

Pregunta 1 — ¿Es un proyecto nuevo, sin inversión previa en Terraform? Si arrancas de cero, OpenTofu es el default sin arrepentimiento: misma sintaxis, mismo ecosistema de providers, cifrado de state, sin ambigüedad de licencia y a un cambio de binario de volver a Terraform si algún día lo necesitas. No hay casi nada que perder.

Pregunta 2 — ¿Dependes de HCP Stacks, Sentinel o del ecosistema IBM? Si tu flujo se apoya en esas piezas (o estás dentro de IBM Cloud Pak / Infragraph, o tu procurement exige a HashiCorp como proveedor), quédate en Terraform —o migra solo los workspaces que no dependan de ellas. Nada de esto tiene hoy un equivalente directo en OpenTofu.

Pregunta 3 — ¿Tu situación tiene riesgo legal con la BSL? Esto aplica si vendes un servicio o construyes un producto sobre IaC, si estás en la UE con requisitos de soberanía, o si tu equipo legal/compliance marca la BSL como riesgo. En esos casos el riesgo es real y concreto: migra a OpenTofu, cuya licencia MPL bajo la Linux Foundation ya no puede volver a cambiar.

¿Respondiste "no" a las tres? Entonces es opcional. Para uso interno sin preocupación de licencia, puedes quedarte en Terraform sin problema. Pero vale la pena evaluar OpenTofu igual: por sus features (el cifrado de state es genuinamente útil) y para no quedar atado a un único proveedor que ya subió precios de su plataforma gestionada.

4. 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:

• Instala el binario tofu junto a terraform. Pueden convivir.
• Corre tofu init y tofu plan contra un workspace y confirma que el plan sale vacío (sin cambios). Ese "no changes" es tu prueba de que el state se leyó bien.
• Migra de a poco y mantén ambos motores en paralelo mientras dure la transición. La estrategia dual es válida y común.

Dos advertencias que ahorran dolores. Primero: el state es binario-compatible en ambas direcciones —puedes volver a Terraform— excepto si activas el cifrado de state de OpenTofu, que vuelve 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 (variables en bloques backend en OpenTofu; archivos .tfstack.hcl en Terraform) y fallan en el otro. El solapamiento todavía es grande, pero se va a ir encogiendo.

Migrar no reescribe tu infraestructura: cambia el motor que la ejecuta. El riesgo real no está en el state, está en las features de plataforma de las que dependes.

5. Cuándo NO migrar

Para ser justos: Terraform no se rompió y tiene ventajas que importan a ciertos equipos. HCP Terraform sigue siendo una plataforma gestionada madura que el ecosistema OpenTofu no iguala punto por punto para flujos enterprise llave en mano. El soporte respaldado por IBM, la profundidad de documentación acumulada desde 2014 y las certificaciones en industrias reguladas 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 momentum propio como para que las ventajas de licencia y gobernanza dejaran de venir con un costo técnico. Por eso, para equipos que no estén casados con flujos específicos de HCP Terraform, OpenTofu es cada vez más la recomendación por defecto.

Antes de mover tu infraestructura: validación sin riesgos

La decisión entre OpenTofu y Terraform no se resuelve comparando features en una tabla. Se responde evaluando tu dependencia real de HCP Terraform, el cumplimiento licenciamiento de tu organización y el costo operativo de mantener dos motores IaC durante la transición. Si usas Terraform OSS puro sin Sentinel, sin Stacks y sin RBAC gestionado por HashiCorp, el riesgo técnico de migrar es bajo —pero el riesgo operativo de no validar antes existe.

El error más frecuente es asumir compatibilidad total porque el lenguaje es el mismo. Un solo proveedor que use APIs internas de Terraform puede romper un apply en producción. Valida antes, migra después.

1. 1Clonar y ejecutar tofu init en stagingCopia tu código IaC a un entorno aislado y ejecuta `tofu init` para verificar que todos los proveedores y módulos se descargan correctamente.
2. 2Comparar outputs de planEjecuta ambos motores sobre el mismo state y diff los resultados. Cualquier diferencia en recursos planificados indica un punto de fricción.
3. 3Validar backends y secretsConfirma que tu backend de state (S3, GCS, Azure Blob) y cualquier cifrado de secrets funcionan igual con `tofu`.
4. 4Actualizar pipelines de CI/CDReemplaza el binario de Terraform por Tofu en tus pipelines sin cambiar la lógica. Ejecuta applies en staging durante al menos una semana antes de tocar producción.