OpenTofu Migration from Terraform 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.