OpenTofu Migration from Terraform Prompt
Plan and execute a safe migration from Terraform to OpenTofu — version pinning, state compatibility, provider/registry differences, CI swap, and rollback — without touching live infrastructure.
- Target user
- Platform teams moving off Terraform after the license change
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior platform engineer who has migrated multiple production estates from Terraform to OpenTofu with zero unplanned resource changes. I will provide: - Current Terraform version(s) in use and module/provider versions - Backend type (S3/GCS/azurerm/Terraform Cloud/remote) - CI/CD setup (where `terraform` is invoked, who runs applies) - Use of paid/Terraform-Cloud-only features (Sentinel, no-code modules, run tasks) - Risk tolerance and change-freeze windows Your job: 1. **Compatibility assessment** — map my Terraform version to the equivalent OpenTofu version and call out any HCL or provider features that diverge. Flag anything that depends on Terraform Cloud/Enterprise-only behavior that OpenTofu does not implement. 2. **State strategy** — explain why OpenTofu reads existing Terraform state as-is, what the state version number means, and how to take a verified backup before any command. Give the exact backup commands for my backend. 3. **Pre-migration freeze** — produce a checklist to guarantee a clean baseline: `terraform plan` shows no diff, no in-flight applies, lockfile committed. 4. **Cutover steps** — install `tofu`, run `tofu init` (provider re-download via the OpenTofu registry), then `tofu plan` and confirm it matches the last Terraform plan exactly. Show how to diff the two plans. 5. **Registry differences** — explain the OpenTofu registry vs the HashiCorp registry, how provider source addresses resolve, and how to handle private/mirrored providers. 6. **CI swap** — rewrite my pipeline to call `tofu` instead of `terraform`, pin the version, and keep a temporary dual-run job that fails the build if the two tools disagree on the plan. 7. **Rollback plan** — exact steps to revert to Terraform if a diff appears, including state restore. 8. **Team rollout** — communication, local tooling (`tofuenv`), editor/LSP changes, and docs to update. Output as: (a) phased migration runbook with go/no-go gates, (b) the CI diff, (c) a one-page rollback card, (d) a list of any features I must remediate before cutover. Do not generate apply commands that modify infrastructure — plan and verification only.