Terraform to OpenTofu Migration: A Complete Infrastructure as Code Planning Guide

Migrating from Terraform to OpenTofu is more than replacing a CLI binary and updating pipeline configurations. Before touching production
infrastructure, engineering teams need a clear understanding of their
Terraform estate, state management, module dependencies, backend
configurations, security controls, and operational risks. This guide
walks through the planning phase of an enterprise-grade IaC migration,
covering infrastructure assessments, stakeholder alignment, migration
roadmaps, rollback strategies, and ownership models. Because the best
time to discover a migration problem is before it reaches production.

Terraform to OpenTofu Migration: Why Meticulous Planning Matters More Than the Migration Itself

Infrastructure as Code has changed how engineering teams provision,
manage, and scale infrastructure. What once involved manually
configuring cloud resources through consoles has gradually moved towards version-controlled configuration, automated provisioning, and repeatable deployment workflows. Terraform has played a significant role in that transformation, becoming one of the most widely adopted IaC tools across DevOps, SRE, and Platform Engineering teams.

However, the introduction of OpenTofu has given organizations another
direction to consider when thinking about the future of their
infrastructure automation. With its open-source governance model and
community-driven development, OpenTofu has become a serious
consideration for teams looking to move away from Terraform's licensing
model while retaining a familiar Terraform-style workflow.

But here is something worth discussing before getting excited about the
migration.

Moving from Terraform to OpenTofu is not simply a tooling change. It
is an infrastructure transition that needs to be treated with the same
level of care as a production platform migration.

In smaller environments, switching tools might appear straightforward.
You install OpenTofu, run an initialization command, validate your
configuration, and start working. But enterprise environments rarely
operate with that level of simplicity. They have hundreds of Terraform
repositories, shared modules, remote state backends, multiple cloud
accounts, deployment pipelines, security policies, and teams depending
on infrastructure that cannot afford unexpected changes.

A migration that looks simple on paper can quickly become complicated
when state ownership, provider compatibility, remote backends, and
deployment responsibilities enter the picture.

This is precisely why planning deserves more attention than the actual
execution.

In this article, we will walk through how DevOps, SRE, and Platform
Engineering teams should approach Terraform-to-OpenTofu migration
planning, what needs to be assessed before making changes, how to
structure a migration roadmap, and how to avoid turning a tooling
transition into an infrastructure incident.

1. Start With an Assessment of Your Existing Terraform Landscape

Before introducing OpenTofu into your engineering environment, you need
to understand exactly what you are migrating. This sounds obvious, but
it is one of the most frequently overlooked steps in infrastructure
migrations. Teams often know where their Terraform repositories are
located, but they do not necessarily know how many active configurations exist, which environments depend on them, who owns them, or which infrastructure components would be affected if something went wrong.

In an enterprise environment, Terraform is rarely maintained in a single repository. You might have separate repositories for AWS networking, EKS clusters, IAM policies, shared infrastructure modules, application infrastructure, monitoring, and security configurations. Some teams might maintain their own Terraform modules, while others consume centrally managed modules maintained by the Platform Engineering team.

Trying to migrate all these configurations without a proper inventory is a recipe for unnecessary troubleshooting. The first activity should be a complete assessment of the existing
Terraform estate.

What should you inventory?

I would break the assessment into five major areas.

1. Terraform repositories and configurations

Start by identifying every repository, working directory, and Terraform
configuration currently used across the organization. Do not restrict
the assessment to repositories owned by the central infrastructure team. Application teams, security engineers, and networking teams might also maintain Terraform configurations that provision or modify
infrastructure.

For every repository, collect information such as:

• Repository name and ownership.
• Terraform CLI version.
• Number of Terraform workspaces.
• Cloud providers and services being managed.
• Active environments, including development, staging, and production.
• Last successful deployment and frequency of infrastructure changes.
• Current status of the configuration and whether it is still actively maintained.

This gives you a realistic picture of the migration scope instead of
relying on assumptions about how much Terraform is actually being used.

2. Terraform state files and workspaces

State management deserves special attention because it is where your
Terraform configuration and actual infrastructure converge. A state file maintains the relationship between the resources defined in your
configuration and the real resources managed by Terraform.

Identify where each state file is stored, whether it uses local state or remote backends, how state locking is implemented, and which teams or pipelines have permission to access it.

For example, an organization might have:

 ---------------------------------------------------------------------------------------- Environment Backend State location Ownership ----------------- ----------------- ---------------------------------- ----------------- Development S3 `dev/network/terraform.tfstate` Platform Team Staging S3 `staging/eks/terraform.tfstate` Cloud Team Production S3 `prod/network/terraform.tfstate` Infrastructure Team Security Azure Blob `security/iam/terraform.tfstate` Security Team ---------------------------------------------------------------------------------------- 

The actual backend configuration will vary between organizations, but
the important thing is to establish a clear mapping between
configurations, state locations, and ownership.

Also, identify whether multiple configurations consume outputs from one
another through terraform_remote_state. These relationships become
particularly important when deciding the migration sequence.

3. Module dependencies

Shared modules are another area where migration planning can become
complicated.

Imagine an organization maintaining a central VPC module that is
consumed by 30 different application repositories. If the module is
changed without understanding its consumers, you could introduce
compatibility issues across multiple environments.

Build an inventory of:

• Internal Terraform modules.
• Public registry modules.
• Git-based module dependencies.
• Module version constraints.
• Provider requirements declared by individual modules.
• Custom modules that are no longer maintained.
• Modules with dependencies on Terraform-specific functionality.

Pay particular attention to modules shared across multiple teams. They
should receive additional testing because a problem in a shared module
can affect considerably more infrastructure than a problem in an
isolated configuration.

4. Backend configurations

Document every backend configuration currently in use. This includes S3, Azure Blob Storage, Google Cloud Storage, Terraform Cloud or other
supported remote state solutions, depending on your infrastructure
architecture.

Do not simply record the backend type. Understand the operational
details behind it:

• Authentication and access mechanisms.
• State locking and concurrency controls.
• Encryption at rest.
• Versioning and backup policies.
• State access permissions.
• Recovery procedures.
• Workspace naming and state key conventions.

A backend that works perfectly with Terraform should still be validated
against your selected OpenTofu version and deployment environment.

5. Critical workloads and business dependencies

Finally, classify infrastructure according to its business importance.

Not every Terraform configuration carries the same operational risk. A
development environment used by a small engineering team is very
different from a production networking configuration that supports
several business-critical applications.

Identify workloads that would require additional approval, testing, or
maintenance windows before migration.

For example:

 Workload Criticality Migration priority --------------------------------------- ------------- ------------------------- Development infrastructure Low Early Internal monitoring stack Medium Early, after validation Staging Kubernetes clusters Medium Controlled rollout Production application infrastructure High Later Core networking and IAM Critical Carefully scheduled 

The idea is not to migrate infrastructure based on repository order. It
is to migrate based on dependencies, operational risk, and the team's
ability to validate the outcome.

Planning principle: You cannot manage migration risk if you do not know what infrastructure you own.

2. Build an Infrastructure Dependency Map Before Touching Anything

One of the biggest mistakes engineering teams can make is treating
Terraform repositories as independent migration units.

In reality, infrastructure configurations frequently depend on one
another. A networking configuration might expose VPC IDs and subnet IDs, which are then consumed by an EKS configuration. That EKS configuration might expose cluster endpoints and authentication information, which another configuration uses to deploy Kubernetes resources.

These dependencies create a chain of relationships that must be
understood before deciding the migration order.

Consider a simplified example:

Example: Terraform infrastructure dependency chain

Network Infrastructure (VPC, Subnets, Routing Tables) | | VPC and subnet outputs v Kubernetes Infrastructure (EKS Cluster, Node Groups, IAM Roles) | | Cluster outputs v Application Infrastructure (Helm Releases, Kubernetes Resources) | | Application endpoints and configuration v Observability Infrastructure (Monitoring, Logging, Alerting) 

Illustrative infrastructure dependency graph, not a universal
deployment architecture.

Understand the direction of dependencies

The terraform_remote_state data source is particularly important here.

For example, one configuration might expose a VPC ID:

output "vpc_id" { value = aws_vpc.main.id } 

Another configuration might consume that output:

data "terraform_remote_state" "network" { backend = "s3" config = { bucket = "company-terraform-state" key = "network/terraform.tfstate" region = "ap-south-1" } } resource "aws_subnet" "application" { vpc_id = data.terraform_remote_state.network.outputs.vpc_id } 

The second configuration depends on the first. That relationship needs
to be documented because the two configurations might be migrated at
different times.

OpenTofu's migration documentation specifically addresses this
situation. Its recommended approach for interdependent configurations is to migrate dependent configurations before the configurations that
provide their state outputs. This allows OpenTofu-based consumers to
continue reading Terraform-generated state during the transition,
reducing compatibility risks in a mixed-tool environment.

How should you build the dependency map?

Start with a repository-wide search for:

• terraform_remote_state
• Module source references.
• Shared backend configurations.
• Provider aliases.
• Cross-account role assumptions.
• Shared resource outputs.

Then document which configurations consume outputs from which other
configurations.

A simple dependency matrix is enough to begin with:

 Configuration Depends on Consumers --------------- ------------------- ----------------------------- Network None EKS, Security Security Network EKS, Applications EKS Network, Security Applications, Observability Applications EKS, Security None Observability EKS None 

This matrix gives the migration team a starting point for identifying
leaf configurations, dependency chains, and the safest migration
sequence.

My recommendation: Do not approve a production migration until the
team has a documented dependency map. It is much easier to identify a
dependency in a planning document than to discover it during a failed
production pipeline.

3. Validate OpenTofu Compatibility Before Creating the Migration Roadmap

Once you understand the existing Terraform environment, the next step is to determine whether your current infrastructure code is ready for
OpenTofu.

Although OpenTofu aims to maintain compatibility with Terraform
configurations, that does not mean every organization can assume a
completely frictionless transition.

Your actual migration experience depends on the Terraform version
currently in use, the OpenTofu version selected, provider availability,
module dependencies, backend configurations, and any Terraform-specific
functionality used by your code.

This is where a proper compatibility assessment becomes important.

Check Terraform and OpenTofu version compatibility

Start by identifying the Terraform versions used across all
repositories.

Some organizations standardize their Terraform version, while others
have different versions across teams and environments. That difference
can introduce unnecessary variables during migration.

For example:

• Team A uses Terraform 1.5.x.
• Team B uses Terraform 1.6.x.
• Team C uses Terraform 1.8.x.
• Team D uses Terraform 1.9.x.

Instead of migrating all four environments simultaneously, establish a
supported migration path for each version based on the official OpenTofu migration documentation.

Do not assume that the latest OpenTofu release is automatically the
correct first migration target for every older Terraform installation.
OpenTofu has published version-specific migration guidance, including
guidance for migrating from Terraform 1.8.x and 1.9.x.

The objective should be to reduce version-related uncertainty before
introducing changes to production infrastructure.

Validate provider compatibility

Providers are responsible for communicating with infrastructure
platforms and APIs. Your AWS provider, Azure provider, Kubernetes
provider, and other third-party integrations are therefore essential
parts of the migration.

A configuration might initialize successfully but still encounter
problems when it attempts to use a particular provider version or
resource feature.

Check:

• Whether the provider is available through the OpenTofu Registry or another configured source.
• Whether the selected provider version works with your chosen OpenTofu version.
• Whether the provider supports all the resource types currently used.
• Whether provider authentication works in your CI/CD environment.
• Whether custom or internally maintained providers require additional validation.

Also review your provider version constraints and dependency lock files.

For example:

terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } } } 

Avoid changing provider versions unnecessarily during the migration. If
the existing provider version is working correctly, keep it pinned
initially and evaluate upgrades separately.

OpenTofu supports Terraform-compatible providers, but provider selection and version constraints still need to be managed deliberately.

Review module compatibility

Do not overlook modules just because they are written in HCL.

A module might depend on a particular provider version, use functions or language features that differ between Terraform and OpenTofu, or
retrieve dependencies from a registry that needs to be checked.

For each important module, verify:

1. The module source is accessible.
2. The required provider versions are available.
3. The module initializes successfully with OpenTofu.
4. Its outputs and resource references behave as expected.
5. Its consumers continue to produce the expected plans.

Pay special attention to internally maintained modules. These are often
the most difficult dependencies to validate because documentation and
automated testing may be limited.

Check Terraform-specific functionality

Search your existing codebase for functionality that may require changes when moving to OpenTofu.

For example, review:

• Terraform-specific functions.
• Experimental or version-dependent features.
• Test framework usage.
• Backend-specific configuration.
• Automation tools that explicitly invoke Terraform.
• Integrations that assume Terraform CLI output or command behavior.

The important point is to separate compatibility issues from ordinary
infrastructure improvements.

If you discover an unrelated opportunity to upgrade providers, redesign
modules, or reorganize state, record it as a separate initiative rather
than introducing it into the initial migration.

Keep the first migration as close to the existing working
configuration as possible.

4. Treat State Management as a First-Class Migration Workstream

If there is one area I would never rush during a Terraform-to-OpenTofu
migration, it is state management.

A Terraform state file is not just another configuration artifact that
can be replaced whenever necessary. It contains resource identities,
metadata, dependencies, and information that Terraform uses to
understand the infrastructure it manages.

A mistake involving state can create situations where the tool believes
a resource needs to be recreated, modified, or destroyed even though the actual infrastructure has not changed.

That is the kind of problem nobody wants to troubleshoot during a
production deployment.

Establish a state backup strategy

Before migrating any configuration, create a recoverable backup of its
current state. For local state, this includes preserving the state file and any relevant backup files. For remote state, use the backend's native backup and recovery capabilities.

For example, an organization using AWS S3 should review:

• S3 bucket versioning.
• Server-side encryption.
• IAM permissions.
• State locking configuration.
• Recovery procedures.
• Access logging and audit requirements.

A backup is only useful if you know how to restore it. Therefore, the
migration team should perform at least one recovery test in a
non-production environment.

OpenTofu's migration guidance explicitly recommends backing up state and configuration before initialization and testing the migration process before proceeding.

Document state ownership and access

Another important question is: who is allowed to modify the state?

In large organizations, multiple engineers and automated pipelines may
interact with the same infrastructure. Without clear access boundaries,
two different tools or pipelines could attempt to manage the same state
simultaneously.

Before migration, define:

• Which team owns each state file.
• Which CI/CD pipeline is authorized to apply changes.
• Who can perform manual operations.
• How locking prevents concurrent modifications.
• Who can approve emergency state operations.
• How state backups are accessed during recovery.

This is also a good opportunity to review excessive permissions and
remove unnecessary access.

Avoid concurrent Terraform and OpenTofu operations

One operational rule should be established before migration begins:

Never allow Terraform and OpenTofu to independently apply changes
against the same state during the transition.

You can have both CLIs installed in the same environment for validation
and rollback purposes. However, that does not mean both should be
allowed to modify the same infrastructure state.

Establish a controlled handover point:

1. Stop new infrastructure deployments for the configuration.
2. Confirm no Terraform operation is currently running.
3. Capture the latest state backup.
4. Record the current Terraform version and provider selections.
5. Initialize and validate the configuration using OpenTofu.
6. Allow OpenTofu to become the authorized management tool only after verification.

This avoids confusion about which tool is responsible for the latest
state and prevents overlapping operations.

Decide how remote state will be handled

Do not assume that migrating to OpenTofu means you must also migrate
your remote state backend. These are separate decisions.

If your existing backend is suitable and supported by your selected
OpenTofu version, keeping it in place initially can reduce migration
complexity.

For instance, an organization already using S3 for Terraform state does
not need to redesign its state storage architecture simply because it is adopting OpenTofu.

Keep the existing backend configuration stable unless there is a
separate business or technical reason to change it.

5. Align Security, Networking, Compliance, and Platform Teams Early

Technical compatibility is only one part of an enterprise migration. The other part is organizational alignment. This is where migrations often become delayed, even when the engineering team has completed most of the technical preparation.

Think about what happens when an infrastructure team introduces a new
CLI tool into an established enterprise environment. The security team
may want to review its distribution and software provenance. The
networking team might need to approve access to a new registry endpoint. The compliance team may require evidence that the new tooling meets internal governance requirements.

If these discussions happen after the migration has already started, the engineering team can end up waiting for approvals that should have been obtained weeks earlier.

Security team alignment

The security team should be involved in reviewing how OpenTofu will be
installed, authenticated, executed, and maintained.

Some important areas to discuss include:

• Binary distribution and integrity verification.
• Software supply chain security.
• Provider and module source policies.
• Secret management.
• State encryption and access controls.
• CI/CD runner permissions.
• Vulnerability scanning and dependency management.

For example, if your organization uses a centralized artifact repository to distribute approved binaries, establish how OpenTofu releases will be downloaded, verified, approved, and distributed.

Also review how providers and modules are obtained. A migration should
not unintentionally introduce unapproved external dependency sources.

Networking team alignment

OpenTofu introduces its own operational requirements around downloading
providers, modules, and other dependencies.

Organizations operating behind corporate proxies, restricted outbound
networks, or private infrastructure environments should validate
connectivity before the migration.

Coordinate with networking teams to check:

• OpenTofu Registry connectivity.
• Provider download endpoints.
• Module source accessibility.
• Proxy configuration.
• Private registry connectivity.
• DNS and firewall restrictions.

A pipeline that cannot download its required provider packages is not
going to complete successfully, regardless of how correct the HCL
configuration is.

Compliance and governance alignment

In regulated environments, infrastructure changes are often subject to
audit requirements, approval policies, and change management procedures. The migration team should confirm that OpenTofu fits within existing governance processes.

For example:

 ----------------------------------------------------------------------- Governance area What needs validation ----------------------------------- ----------------------------------- Change management Are infrastructure changes still subject to approval? Auditability Can plans, applies, and state operations be traced? Access control Are RBAC and IAM permissions properly enforced? Policy enforcement Do existing infrastructure policies still work? Software governance Is OpenTofu an approved tool? Data protection Are state files encrypted and access-controlled? ----------------------------------------------------------------------- 

The objective is not to create an entirely new governance framework. It
is to ensure that existing controls continue to work after the tooling
transition.

Platform Engineering alignment

The Platform Engineering team should ideally own the migration standards and provide a reusable implementation path.

This includes maintaining:

• Approved OpenTofu versions.
• Standardized CI/CD templates.
• Reusable backend configurations.
• Provider and module policies.
• Migration checklists.
• Troubleshooting documentation.
• Operational ownership guidelines.

Application teams should not have to independently figure out how to
migrate their infrastructure or build their own OpenTofu pipelines.

A central platform team can reduce duplicated effort by providing a
tested migration template that individual teams can adopt.

6. Create a Migration Roadmap With Clear Milestones

Once the assessment, compatibility review, state strategy, and
stakeholder alignment are complete, it is time to turn the findings into an actual migration roadmap.

I would strongly recommend avoiding a single migration deadline for the
entire organization. Instead, break the migration into manageable phases with clear entry criteria, exit criteria, owners, and approval requirements. Here is an example of how an enterprise migration roadmap could look.

Terraform to OpenTofu migration roadmap

 ------------------------------------------------------------------------ Phase Timeline Activities Exit criteria ----------------- ----------------- ------------------ ----------------- 1\. Discovery and Week 1--2 Inventory Approved assessment repositories, inventory and states, backends, dependency map. modules, dependencies, and workload criticality. 2\. Compatibility Week 3 Validate versions, Compatibility and risk providers, report and risk assessment modules, backends, register. and CI/CD requirements; identify blockers. 3\. Pilot Week 4 Select a low-risk Successful pilot migration configuration, and documented initialize lessons. OpenTofu, compare plans, test state handling and rollback. 4\. Controlled Week 5--6 Migrate low- and Scheduled migration medium-risk configurations configurations, pass validation. follow dependency-aware sequencing, validate pipelines, and obtain sign-offs. 5\. Production Week 7--8 Migrate production Production migration configurations in workloads approved windows, successfully validate state and handed over. plans, monitor health, and maintain rollback readiness. 6\. Week 9 Standardize CI/CD OpenTofu becomes Standardization templates, update the approved IaC and closure documentation, standard. remove obsolete execution paths, and review outcomes. ------------------------------------------------------------------------ 

Illustrative nine-week roadmap. Actual timelines depend on
infrastructure size, dependencies, governance, and team capacity.

Assign ownership to every milestone

A roadmap without ownership is simply a collection of dates.

Every phase should have an accountable person or team. For example:

 Workstream Primary owner Responsibility ------------------------ ---------------------- --------------------------- Migration strategy Platform Engineering Overall coordination State management Cloud Infrastructure Backup and recovery Provider compatibility DevOps Validation and testing Security review Security Engineering Supply chain and access Network access Networking Registry and proxy access Compliance Governance Team Audit and policy approval Production rollout SRE Operational validation 

It is also useful to identify one migration lead who can coordinate
decisions across these teams and maintain a single source of truth for
migration progress.

7. Design a Pilot Migration Before Scaling Across the Organization

I would never recommend making the first OpenTofu migration a production networking stack or a business-critical Kubernetes cluster.

A pilot gives the engineering team an opportunity to validate
assumptions in a controlled environment. It also exposes problems that
might not have been identified during repository assessments.

Choose a configuration that represents a realistic part of your
infrastructure without introducing unnecessary business risk.

For example, a small development environment containing a VPC, a few
security groups, and an EC2 instance could be a suitable starting point. The pilot should exercise the same operational workflow that production will eventually use.

What should the pilot validate?

Configuration initialization

Can OpenTofu initialize the existing configuration without unexpected
errors?

tofu version tofu init 

Configuration validation

Can OpenTofu validate the existing HCL configuration?

tofu validate 

State compatibility

Can OpenTofu read the existing Terraform state correctly? Review the state and compare resource identities and relevant metadata where appropriate.

tofu state list 

Plan comparison

This is one of the most important checks.

Run a Terraform plan before migration and preserve the output. Then run
the OpenTofu plan against the same configuration and equivalent
infrastructure state.

terraform plan -out=terraform-plan tofu plan -out=opentofu-plan 

The goal is to understand whether the two tools produce equivalent
infrastructure decisions. Do not blindly compare the binary plan files. They are not intended to be interchangeable. Compare the human-readable plan output, resource actions, and relevant values.

Ideally, the OpenTofu plan should show no unexpected infrastructure
changes.

Deployment validation

After reviewing and approving the pilot, test a small, non-critical
infrastructure change.

For example, update a resource tag in the development environment and
verify that OpenTofu can successfully plan and apply the change.

tofu plan tofu apply 

The purpose is to verify that the migration works beyond initialization
and read-only validation.

OpenTofu's official migration guide follows the same general principle:
back up the infrastructure, initialize OpenTofu, verify the plan, and
test a small change before relying on it for ongoing infrastructure
management.

Record what you learn

Do not treat a successful pilot as merely a checkbox.

Document:

• Issues encountered during initialization.
• Provider and module download behavior.
• Backend authentication problems.
• State compatibility observations.
• Differences in plan output.
• Pipeline modifications.
• Rollback execution results.

These findings should become the foundation of your organization-wide
migration playbook.

8. Plan CI/CD Pipeline Changes Before the Actual Cutover

Another area that deserves attention is CI/CD.

Most organizations do not execute Terraform manually for every
infrastructure deployment. They rely on Jenkins, GitHub Actions, GitLab
CI, Azure DevOps, or internal deployment platforms.

That means migrating the CLI alone is not enough. The automation
responsible for running it must also be updated and validated.

Consider a typical Terraform pipeline:

Developer creates a pull request | v Terraform fmt | v Terraform validate | v Terraform plan | v Approval process | v Terraform apply 

After migration, the equivalent workflow should execute OpenTofu
commands while retaining the organization's existing approval and
security controls.

What needs to change?

Review all automation that references the Terraform binary or its
output.

This includes:

• Jenkinsfiles.
• GitHub Actions workflows.
• GitLab CI configurations.
• Docker images used by infrastructure runners.
• Shell scripts and deployment wrappers.
• Terraform-specific automation integrations.
• Policy-as-code integrations.
• Internal developer platform templates.

For example, a basic GitHub Actions workflow might look like this:

name: OpenTofu Infrastructure Pipeline on: pull_request: paths: - "infrastructure/**" permissions: contents: read jobs: validate: runs-on: ubuntu-latest defaults: run: working-directory: infrastructure steps: - name: Checkout repository uses: actions/checkout@v4 - name: Setup OpenTofu uses: opentofu/setup-opentofu@v1 - name: Initialize OpenTofu run: tofu init -input=false - name: Format Check run: tofu fmt -check -recursive - name: Validate Configuration run: tofu validate - name: Generate Plan run: tofu plan -input=false 

This is an illustrative validation workflow, not a production-ready
deployment pipeline. In an enterprise environment, you should
additionally configure provider authentication through secure identity
mechanisms, state locking, controlled permissions, and protected apply
workflows.

Maintain existing deployment controls

A migration should not become an excuse to weaken your CI/CD security
model. If your Terraform pipelines currently require peer approval before production changes, retain that approval mechanism.

If your infrastructure deployment uses short-lived cloud credentials,
preserve that authentication approach.

If you have policy checks that prevent public S3 buckets, unrestricted
security groups, or unauthorized resource creation, ensure that those
checks continue to work.

The objective is to change the IaC execution engine without disrupting
the operational controls built around it.

9. Establish a Rollback Strategy Before the First Production Migration

Every serious infrastructure migration needs a rollback strategy.

Not a document created after something breaks. Not a vague statement
that the team can reinstall Terraform if necessary. A real, tested
procedure that explains exactly how to return to the previous operating
model.

One important distinction: rolling back the CLI is not necessarily the
same as rolling back the state.

If OpenTofu has already written state or used functionality that is not
compatible with your previous Terraform version, simply switching
binaries might not be sufficient.

This is why rollback planning must account for both configuration and
state.

Define your rollback triggers

Before starting, agree on the conditions that would cause the team to
stop the migration.

Examples include:

• Unexpected resource replacements in the OpenTofu plan.
• Provider initialization failures that cannot be resolved within the approved window.
• State locking or backend access problems.
• Unexpected state changes.
• Failure of critical infrastructure dependencies.
• Inability to meet security or compliance requirements.

These conditions should be agreed upon by the migration lead,
infrastructure owner, and relevant SRE or operations team.

Create a practical rollback sequence

A typical rollback procedure should look something like this:

1. Stop further OpenTofu applies and freeze changes to the affected configuration.
2. Identify whether OpenTofu changed the state or infrastructure.
3. Preserve the latest OpenTofu state and execution logs for investigation.
4. Restore the approved Terraform configuration and compatible state snapshot if required.
5. Reinitialize Terraform and verify backend connectivity.
6. Run a Terraform plan and review every proposed action.
7. Resume Terraform management only after the infrastructure owner approves the result.

For example:

terraform init terraform plan 

Do not automatically run terraform apply just because the rollback
process has started. First, establish that Terraform can correctly interpret the restored configuration and state without proposing unexpected changes.

Define the rollback ownership

The team should know who can authorize a rollback, who has access to
state backups, who will execute recovery operations, and who will
communicate with affected stakeholders. Also define the maximum acceptable recovery time for critical infrastructure.

A rollback procedure that requires waiting several hours for someone to
locate a state backup is not an effective production recovery plan.

A migration is not production-ready until the team knows how to
recover from a failed migration.

10. Define Migration Success Criteria and Operational Readiness

One final planning activity is often overlooked: deciding what
successful migration actually means.

Teams sometimes measure migration progress by counting how many
repositories have replaced terraform with tofu. That is useful for
tracking adoption, but it does not tell you whether the infrastructure
is operating correctly.

A configuration can initialize successfully while still having broken
automation, missing access controls, or unexpected resource changes. Define measurable success criteria before starting.

Suggested migration metrics

 ----------------------------------------------------------------------- Metric Expected outcome ----------------------------------- ----------------------------------- Configuration compatibility All approved configurations initialize and validate State integrity No unexpected resource identity or state changes Plan consistency No unexplained infrastructure differences Pipeline reliability CI/CD workflows execute successfully Security compliance Existing controls remain enforced Rollback readiness Recovery procedure has been tested Ownership Every migrated configuration has an accountable owner Documentation Operational runbooks and standards are updated ----------------------------------------------------------------------- 

Also establish an operational observation period after production
cutover.

During this period, monitor infrastructure deployment failures, state
locking errors, provider initialization issues, and unexpected plan
differences.

Keep the migration team available to investigate issues rather than
immediately moving everyone to unrelated engineering work.

Once the observation period is complete and the acceptance criteria are
met, the migration can be formally closed.

A Practical Pre-Migration Checklist for DevOps and Platform Teams

Before moving into the actual migration execution, I would recommend
using the following checklist as a final readiness review.

Infrastructure discovery

• [ ] All Terraform repositories and configurations are inventoried.
• [ ] Terraform versions and workspace usage are documented.
• [ ] State files and backend configurations are mapped.
• [ ] Shared modules and provider dependencies are identified.
• [ ] Critical workloads and infrastructure owners are documented.

Compatibility assessment

• [ ] OpenTofu version and migration path are selected.
• [ ] Provider compatibility is validated.
• [ ] Module compatibility is reviewed.
• [ ] Terraform-specific functionality is assessed.
• [ ] Existing lock files and dependency constraints are reviewed.

State and recovery

• [ ] State backups are created and verified.
• [ ] Backend locking and access permissions are tested.
• [ ] State ownership is documented.
• [ ] Concurrent Terraform and OpenTofu applies are prevented.
• [ ] Rollback and state restoration procedures are tested.

Stakeholder alignment

• [ ] Security team has reviewed the tooling.
• [ ] Networking team has validated registry connectivity.
• [ ] Compliance requ...