What’s the safest way to migrate existing CloudFormation stacks to OpenTofu?

Protect the resources from CloudFormation before doing anything else. Add DeletionPolicy: Retain and UpdateReplacePolicy: Retain to the stack resources and deploy that change first. This prevents CloudFormation from deleting live infrastructure if the stack or a resource is later removed. Generated configuration may include explicit physical names assigned by CloudFormation; keep those names initially because removing a name can cause a replacement. Make the initial OpenTofu phase import-only, and handle intentional improvements or infrastructure changes in a separate phase.

The safest approach is to migrate one stack and customer environment at a time, starting with a lower-risk environment. Use OpenTofu import blocks and plan -generate-config-out to create an initial configuration, then review and clean it up manually. Treat a clean no-op plan as the completion criterion—not merely a successful import. Before every migration, back up and carefully inspect the state, and run plans with refresh-only or otherwise read-only checks until you’re confident the configuration matches reality.

Keep the first production apply extremely conservative. Import the resources, run a refresh and plan, and investigate every proposed update, replacement, or deletion. Don’t accept a plan just because the import succeeded. Use backups and locking for state, restrict who can apply during the migration, and preserve the original CloudFormation definitions until the OpenTofu state and no-op plan have been validated. After that, retire CloudFormation gradually rather than changing ownership and configuration all at once.

Resource dependencies are usually less difficult than expected because imports use the real AWS resource IDs rather than relying on CloudFormation’s creation order. Still, migrate related resources in logical groups and verify references between them. Don’t use lifecycle ignore_changes as a blanket solution for every difference; it can hide real drift and leave OpenTofu unable to manage important settings. If it is needed temporarily for provider-normalized fields or unavoidable external changes, document it and revisit it after the migration.

The generated configuration is useful as a starting point, but it often produces a huge collection of static resources. For repeated customer environments, use it to discover the actual settings and import IDs, then refactor the result into reusable modules with customer-specific root configurations and variables. A script using the CloudFormation API can generate import blocks or resource definitions and present drift in a more manageable way. Test the modules on development environments first, and compare two materially different environments early so you discover which settings really need to be configurable.