Migrar de Terraform a OpenTofu: Infraestructura como Código

Migrar de Terraform a OpenTofu no requiere reconstruir la infraestructura ni reescribir los archivos de configuración en lenguaje HCL. OpenTofu nació como un fork totalmente de código abierto (bajo la Linux Foundation y la licencia MPLv2) creado en respuesta al cambio de licencia de HashiCorp hacia BSL (Business Source License). La migración se realiza como un reemplazo directo (drop-in replacement): OpenTofu mantiene compatibilidad total con la sintaxis de los archivos .tf, reconoce los proveedores (providers) y módulos existentes, y lee sin modificaciones la estructura del archivo de estado (state file). Garantiza además el mismo mecanismo de bloqueos atómicos en S3/DynamoDB dentro de los pipelines de CI/CD.

En el ámbito de la Infraestructura como Código (IaC) en este 2026, la estabilidad del ecosistema sufrió un giro decisivo tras la decisión de HashiCorp de abandonar la licencia de código abierto tradicional en favor de la Business Source License (BSL). Este cambio introdujo restricciones severas para empresas de servicios, plataformas SaaS e integradores de tecnología, creando un escenario de incertidumbre comercial y riesgo de vendor lock-in.

Como respuesta de la comunidad y con el respaldo de la Linux Foundation, surgió OpenTofu. Dentro de nuestra categoría Código Abierto e Infraestructura Autohospedada, analizaremos la migración estratégica de Terraform a OpenTofu. Conectando esto con nuestras publicaciones previas sobre automatización, despliegues en contenedores y seguridad perimetral, descubrirás cómo realizar esta transición sin riesgos, conservando tus archivos de estado, manteniendo el bloqueo atómico en S3/DynamoDB y asegurando la continuidad de tus pipelines de integración continua.

La génesis del cambio: De la licencia BSL a la gobernanza abierta

El modelo de IaC se basa en la capacidad de declarar recursos de red, cómputo y almacenamiento en archivos de texto legibles, permitiendo auditar y versionar la infraestructura como si fuera código de aplicación. Durante años, Terraform fue el estándar de facto bajo la licencia Mozilla Public License (MPL).

El cambio a la BSL modificó esta dinámica:

• Restricción de Uso Comercial: Prohíbe utilizar el software para construir productos competitivos o plataformas de gestión de infraestructura de terceros.
• Incertidumbre Legal: Dificulta el uso del binario en herramientas internas de automatización o entornos multicloud empaquetados.

OpenTofu se estableció como una bifurcación (fork) abierta del código base de Terraform en su última versión MPL (v1.5.x). Gobernado de forma neutral por la Linux Foundation, garantiza que la herramienta permanezca como un proyecto de código abierto, protegido contra cambios unilaterales de licencia por intereses corporativos.

Anatomía de la migración: El archivo de estado y la compatibilidad HCL

El núcleo operativo de IaC es el archivo de estado (State File), habitualmente denominado terraform.tfstate. Este archivo JSON contiene el mapeo exacto entre los recursos declarados en código HCL y los objetos reales desplegados en la nube (instancias EC2, redes VPC, bases de datos, etc.).

La mayor inquietud durante una migración es el riesgo de corrupción del archivo de estado, lo que podría provocar la destrucción accidental de recursos o desincronizar el entorno.

OpenTofu resuelve este problema garantizando compatibilidad retroactiva:

1. Sintaxis HCL Cien Por Ciento Compatible: OpenTofu procesa de forma nativa los archivos de configuración .tf y .tfvars existentes sin requerir cambios de sintaxis o reescritura de módulos.
2. Interpretación Directa del Estado: El motor de OpenTofu lee y actualiza la estructura del archivo terraform.tfstate de manera idéntica. No se requiere ejecutar scripts de conversión ni exportar los datos.

Para realizar la migración en un entorno local o de desarrollo, el proceso se reduce a reemplazar el comando terraform por tofu:

• Se ejecuta tofu init dentro del directorio del proyecto.
• OpenTofu detecta el backend y los proveedores ya descargados, reconfigura el entorno local y asume el control del estado sin alterar los recursos desplegados.

Backends remotos y bloqueos atómicos con S3 y DynamoDB

En entornos de producción, el archivo de estado no se almacena localmente, sino en un backend remoto centralizado. La arquitectura estándar en AWS utiliza un bucket de Amazon S3 para alojar el archivo cifrado y una tabla de Amazon DynamoDB para gestionar los bloqueos de concurrencia (State Locking).

El bloqueo de estado previene la condición de carrera (Race Condition): si dos ingenieros o dos ejecuciones paralelas de CI/CD intentan modificar la infraestructura al mismo tiempo, DynamoDB registra un candado atómico (LockID) que impide la ejecución concurrente, evitando que el archivo de estado se corrompa.

OpenTofu mantiene el soporte para los backends remotos estándar (S3, Google Cloud Storage, Azure Blob Storage, Consul y HTTP):

• Al ejecutar tofu plan o tofu apply, OpenTofu solicita el bloqueo en la tabla de DynamoDB utilizando las mismas llamadas a la API de AWS.
• La verificación y liberación del candado operan de forma transparente, garantizando la seguridad en entornos compartidos.

Registro de proveedores (Registry) y automatización en CI/CD

Otro cambio relevante es la gestión del registro de proveedores (Providers Registry). Terraform utiliza por defecto el registro administrado por HashiCorp (registry.terraform.io).

OpenTofu implementa un registro abierto e independiente (OpenTofu Registry). Cuando ejecutas tofu init, el CLI redirige la descarga de los providers (AWS, Google, Cloudflare, Docker, etc.) desde este registro abierto, que mantiene copias actualizadas de los proveedores oficiales.

En pipelines de CI/CD (como GitHub Actions, GitLab CI, Woodpecker o Jenkins), la migración implica actualizar la imagen de contenedor o la acción del pipeline:

• Se reemplaza la acción oficial de Terraform por la acción oficial de OpenTofu (opentofu/setup-opentofu).
• Se cambia el binario invocado en los scripts de despliegue (terraform apply pasa a ser tofu apply).
• Los secretos, claves de acceso a la nube y variables de entorno se mantienen sin modificaciones.

Tabla Comparativa DatoCortex

Criterio Técnico y Legal	HashiCorp Terraform (Licencia BSL)	OpenTofu (Licencia MPLv2 / Linux Foundation)
Licencia de Software	BSL v1.1 (Propietaria / Uso restringido)	MPLv2 (100% Código Abierto / Permisiva)
Gobernanza del Proyecto	HashiCorp / IBM (Control corporativo único)	Linux Foundation (Gobernanza comunitaria neutral)
Sintaxis y Compatibilidad HCL	Estándar HCL2	Totalmente compatible con HCL2 y extensiones abiertas
Manejo del Estado (.tfstate)	Formato de estado de HashiCorp	Formato compatible (Lee y escribe estados de Terraform)
Soporte de Backends (S3/DynamoDB)	Nativo	Nativo (Mantiene los mismos mecanismos de bloqueo)
Costo de Adopción	Riesgo de cobro por uso comercial / BSL	Gratis y libre sin restricciones comerciales de por vida

Advertencia DatoCortex: Aunque OpenTofu mantiene compatibilidad total con las versiones v1.5.x y posteriores de Terraform, debes tener precaución si tu infraestructura ya fue actualizada a versiones recientes de Terraform comercial que utilicen sintaxis o características de estado propietarias e incompatibles. Antes de ejecutar tofu apply en producción, realiza una prueba previa con tofu plan sobre una copia del archivo de estado en un entorno de pruebas (staging) para verificar que no existan discrepancias en el esquema.

Preguntas Clave

¿Es necesario ejecutar algún comando de conversión especial sobre el archivo terraform.tfstate antes de usar OpenTofu?

No. OpenTofu fue diseñado como un reemplazo directo (drop-in replacement). Lee la estructura JSON del archivo terraform.tfstate sin necesidad de transformaciones. Al ejecutar tofu init y tofu plan, la herramienta reconoce los recursos existentes y continúa registrando las modificaciones en el mismo archivo de estado, manteniendo intactos los metadatos y las dependencias.

¿Qué sucede con las herramientas del ecosistema como Terragrunt, TFLint o Checkov al cambiar a OpenTofu?

La mayoría de las herramientas populares del ecosistema de IaC (como Terragrunt, TFLint, Trivy o Checkov) ofrecen soporte nativo para OpenTofu. Terragrunt, por ejemplo, permite indicar el uso del binario de OpenTofu mediante la variable de entorno TERRAGRUNT_TFPATH=tofu. Las herramientas de análisis estático y seguridad leen los archivos .tf de forma habitual, por lo que el cambio de CLI no interrumpe el análisis de código en los pipelines.

¿Cómo garantiza OpenTofu la seguridad y disponibilidad de su registro de proveedores (OpenTofu Registry)?

El registro de OpenTofu es una infraestructura descentralizada y de código abierto respaldada por la Linux Foundation. Utiliza redes de distribución de contenido (CDN) globales para alojar las firmas criptográficas y los binarios de los proveedores (providers). Además, el CLI de OpenTofu verifica las firmas GPG de los proveedores durante la ejecución de tofu init, asegurando que los paquetes descargados no hayan sido alterados.

¿Qué ocurre si un proyecto de IaC utiliza módulos remotos alojados en la infraestructura privada de Terraform Cloud / HCP Terraform?

Si tu código depende de módulos alojados en Terraform Cloud, OpenTofu continuará funcionando siempre que la autenticación mediante tokens de API sea válida y el endpoint sea accesible. Sin embargo, para mantener una infraestructura completamente independiente de servicios propietarios, la práctica recomendada es migrar esos módulos a repositorios Git estándar (como GitHub, GitLab o instancias autohospedadas de Forgejo) e invocarlos en OpenTofu mediante URLs de fuente Git tradicionales (source = "git::https://...").

Si quieres conocer otros artículos parecidos a Migrar de Terraform a OpenTofu: Infraestructura como Código puedes visitar la categoría Tutoriales.