Qué es cada herramienta
Terraform e OpenTofu son herramientas de infraestructura como código (IaC): describes la infraestructura en ficheros declarativos, la herramienta calcula el plan de cambios y lo aplica contra los proveedores de nube. El flujo de trabajo (init, plan, apply) y el estado que registra qué recursos gestiona son equivalentes en lo esencial.
OpenTofu nace como bifurcación (fork) de Terraform. Según su propia FAQ, surge como respuesta al cambio de licencia de HashiCorp, que dejó de usar una licencia de código abierto para pasar a la Business Source License (BUSL). Terraform sigue siendo desarrollado por HashiCorp, hoy parte de IBM.
Licencias y gobierno: el motivo real de la comparación
Terraform. HashiCorp anunció el 10 de agosto de 2023 que las futuras versiones de sus productos pasaban de MPL 2.0 a BUSL 1.1. El fichero LICENSE del repositorio de Terraform indica hoy BUSL 1.1, con IBM como licenciante, una fecha de cambio a los cuatro años de publicar cada versión y MPL 2.0 como licencia final. La licencia incluye una concesión de uso que permite el uso en producción, con restricciones sobre ofrecer el software a terceros de forma alojada o embebida en competencia con los productos de pago. IBM completó la adquisición de HashiCorp el 27 de febrero de 2025.
OpenTofu. El repositorio se publica bajo MPL-2.0. Se anunció como proyecto de la Linux Foundation el 20 de septiembre de 2023 y fue aceptado en la CNCF el 23 de abril de 2025, en el nivel Sandbox (que es el más temprano). Su FAQ describe un equipo central con un responsable técnico, un comité de dirección para los cambios grandes y un proceso público de RFC.
Implicaciones, no consejo legal. Para una organización que usa Terraform solo internamente para gestionar su infraestructura, las restricciones de la BUSL pueden no afectarle en la práctica; para quien ofrece servicios o productos que embeben IaC, conviene leer el texto con cuidado. Qué licencia es aceptable la decide cada organización, con su asesoría legal. Lo que sí podemos decir es que la licencia, el gobierno y la dependencia de un único proveedor son criterios de riesgo que merece la pena dejar por escrito.
Diferencias prácticas que importan
Compatibilidad. OpenTofu busca mantener la compatibilidad con la configuración de Terraform, y según su FAQ funciona con los proveedores existentes: no tiene proveedores propios. Esa misma FAQ indica compatibilidad con estados creados hasta Terraform 1.5.x; puede estar desactualizada, así que contrasta siempre la guía de migración de la versión que uses.
Registro. OpenTofu usa un registro propio (search.opentofu.org) con proveedores y módulos compatibles. Comprueba en tu ensayo que todos los proveedores y módulos que usas se resuelven y se instalan correctamente; el origen de cada uno puede cambiar la ruta de descarga.
Estado. Los dos mantienen un fichero de estado. OpenTofu documenta cifrado de estado y de planes (método AES-GCM), con claves derivadas de una contraseña o gestionadas en AWS KMS, GCP KMS, Azure Key Vault u OpenBao, entre otras. Es una función a evaluar si el estado contiene datos sensibles; no hemos comparado su equivalente en Terraform, así que no afirmamos que no lo tenga.
Funciones y versiones. Ambos proyectos evolucionan por separado y añaden funciones propias. Antes de decidir, revisa las notas de versión actuales de cada uno frente a lo que realmente usas. No decidas por una lista de funciones genérica: decide por las que tu código necesita.
Cuándo elegir cada una
Terraform tiene sentido si ya lo usas y la licencia encaja con tu uso tras revisarla, si dependes de productos del ecosistema HashiCorp/IBM que quieres mantener integrados, o si tu equipo y tu proveedor de soporte están alineados con él. Cambiar solo por cambiar tiene coste y no aporta nada.
OpenTofu tiene sentido si necesitas una licencia de código abierto (MPL-2.0) y un gobierno neutral por requisitos internos, de clientes o de compras; si quieres reducir la dependencia de un único proveedor; o si te interesan funciones concretas como el cifrado de estado.
Quedarse como está también es una decisión válida. Si el código funciona y la licencia no te plantea problemas, no hay urgencia: lo recomendable es documentar la decisión y revisarla periódicamente, no migrar por inercia.
Cómo migrar con ensayo y plan de retroceso
La documentación oficial de OpenTofu indica que el proceso está diseñado para ser seguro y reversible, y lo divide en cuatro etapas: copia de seguridad del estado y del código, instalación, inicialización y verificación, y una prueba con un cambio pequeño. No prometemos que sea trivial en tu caso: depende de versiones, proveedores y de cómo esté organizado el código. Un plan de ensayo razonable:
1. Inventario. Lista repositorios, backends de estado, versiones de Terraform y de proveedores, módulos propios y de terceros, y dónde se ejecuta el IaC (pipelines, estaciones de trabajo).
2. Copia del estado. Antes de nada, copia el estado (en local, los ficheros de estado; en remoto, según el procedimiento de tu backend) y comprueba que sabes restaurarlo.
3. Ensayo fuera de producción. Empieza por un entorno de pruebas con una copia del estado. Ejecuta tofu init y tofu plan: lo esperado es «sin cambios» o el mismo resultado que con Terraform. Si el plan muestra cambios inesperados, no apliques: investiga primero.
4. Primer apply controlado. En el entorno de ensayo, ejecuta tofu apply: la guía indica que se ejecuta aunque no haya cambios de infraestructura, porque puede actualizar el formato del estado, así que ten la copia lista antes. Después prueba con un cambio pequeño y no crítico (por ejemplo, una etiqueta) y revisa el plan antes de aplicar.
5. Cuidado con terraform_remote_state. Si varias configuraciones se pasan datos con ese recurso, la migración requiere más cuidado y orden; la documentación de OpenTofu tiene una guía aparte.
6. Plan de retroceso escrito. La guía de OpenTofu describe cómo volver a Terraform: dejar de usar OpenTofu, restaurar las copias si el estado cambió, ejecutar terraform init y terraform plan y confirmar que no hay cambios inesperados. Como tofu apply puede cambiar el formato del estado, el retroceso depende de tener la copia previa, y conviene mantener fijada la versión de Terraform que usabas. Ensáyalo antes de migrar producción, con ventana acordada y propietario del cambio.
7. Cambio por pasos. Migra entorno a entorno y repositorio a repositorio, con revisión por pull request y fijando versiones en los pipelines.
Cómo encaja con el diseño de plataformas
Terraform y OpenTofu pueden ser la capa de IaC de una plataforma interna (platform engineering e IDP) en AWS, Azure, Google Cloud y OCI: cuentas, suscripciones, proyectos o compartimentos, redes, identidad, clústeres y etiquetado, versionados y revisados por pull request. La decisión de herramienta es secundaria frente a decisiones de diseño como la estructura de módulos, la separación de estados por entorno, la gestión de secretos fuera del código y la política de versiones.
En Nubyron diseñamos plataformas con IaC sobre Kubernetes y DevOps y te ayudamos a elegir y ensayar la herramienta que encaje con tu caso; también podemos acompañar el flujo de entrega continua como DevOps como servicio. Entregamos la arquitectura, el código de referencia y las guías para que tus equipos lo operen.
Preguntas frecuentes
¿OpenTofu es un reemplazo directo de Terraform?
OpenTofu busca mantener la compatibilidad con la configuración de Terraform y usa los proveedores existentes, pero el resultado depende de tus versiones, proveedores y módulos. Se comprueba con un ensayo (init y plan sin cambios) antes de tocar producción.
¿Puedo seguir usando Terraform en producción con la BUSL?
La licencia incluye una concesión de uso que contempla el uso en producción, con restricciones frente a ofrecer el software a terceros de forma alojada o embebida en competencia con los productos de pago. Si tu caso es dudoso, léela con tu asesoría legal: la decisión es de cada organización.
¿Qué licencia y gobierno tiene OpenTofu?
El repositorio de OpenTofu usa MPL-2.0. Es un proyecto de la Linux Foundation y fue aceptado en la CNCF en nivel Sandbox el 23 de abril de 2025. Su FAQ describe un equipo central, un comité de dirección y un proceso público de RFC.
¿Qué hago con el estado al migrar?
Copia el estado antes de empezar, ensaya con una copia en un entorno de pruebas y comprueba que el plan no muestra cambios inesperados. Si algo falla, el retroceso consiste en restaurar las copias y volver a ejecutar Terraform. Ensáyalo antes de migrar producción.
¿Nubyron me ayuda a elegir y migrar?
Podemos revisar tu caso, preparar el ensayo y el plan de retroceso, y acompañar al equipo. No damos asesoramiento legal sobre licencias: eso lo valora tu asesoría jurídica.
¿Estás valorando OpenTofu o Terraform?
Revisamos tu código de IaC, tus proveedores y tu pipeline, y te ayudamos a decidir y, si procede, a preparar un ensayo de migración con plan de retroceso.
Podemos revisar tu caso contigo en una conversación de 30 minutos.
Hablar con Nubyron