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

Resource dependencies are generally less difficult than expected because imports use the actual AWS resource IDs rather than relying on CloudFormation’s creation order. The bigger risk is configuration drift: names, defaults, lifecycle settings, and provider behavior can make OpenTofu propose replacements. Review every plan, use lifecycle ignore rules only when you understand the long-term trade-offs, and keep backups and locking in place for each state file.

Build and test the modules in development or staging before touching production. It can help to migrate two substantially different environments of the same type early, because that exposes which settings must be configurable and which are truly shared. The initial OpenTofu apply should ideally only establish ownership and make no infrastructure changes; defer intentional improvements or corrections to a separate phase.

The import process is usually the straightforward part. OpenTofu import blocks and plan-based configuration generation can produce a useful starting point, but the generated HCL will still need manual cleanup and refactoring. Treat a completely clean no-op plan as the real migration milestone—not merely a successful import. Keep generated physical names in the configuration initially, since removing a name attribute can cause a replacement later.

For repeated environments, a script using the CloudFormation API can be more useful than blindly dumping everything into static configuration. Generate import definitions and initial resource data, compare the resulting plan with the real infrastructure, and decide which drift is meaningful. The generated configuration is often huge, so use it as scaffolding and then refactor it into reusable modules with environment-specific root configurations.

Before deleting or changing anything in CloudFormation, add DeletionPolicy: Retain and UpdateReplacePolicy: Retain to the stack resources and deploy that update first. This protects the live resources if the stack is later deleted or a resource is removed from its template. Without it, you can have correct OpenTofu state and still accidentally let CloudFormation delete the infrastructure. Migrate one stack at a time, starting with a low-risk customer, and verify the state and plan carefully after each step.