CloudFormation to Terraform | Cloud DevOps Solutions

Migrating from CloudFormation or ARM Templates to Terraform: The Assessment

Our assessment inventories your CloudFormation stacks or ARM and Bicep templates, scores each by migration effort and risk, and recommends what to move, what to leave and in which order. You get a plan and effort estimate before committing to any migration work.

Key takeaways

Migration is optional: working CloudFormation does not need replacing, so the first question is whether a move pays back.

The safe path imports live resources into Terraform state; it does not delete and recreate them.

Stacks with data, such as databases and buckets, need the most care and a retain strategy before the old stack is touched.

Moving gradually, stack by stack, keeps the old and new tools coexisting without conflict.

Deliverable of this step is a decision and a plan, not a big-bang conversion.

Should you migrate at all?

Many teams ask about moving from CloudFormation or ARM templates to Terraform because someone senior wants a single tool, or because a new hire prefers it. Those are weak reasons on their own. CloudFormation and Bicep are mature, supported by the cloud vendor, and they work. A migration costs engineering time and carries risk to running systems.

So this step is an assessment, not a conversion. We tell you whether a migration from CloudFormation to Terraform (or from ARM and Bicep) will pay back, which stacks to move and in what order. It is a contained piece of our Terraform and infrastructure as code service, and it sits next to our work on importing existing resources.

Good reasons to migrate

Multiple clouds or SaaS providers that you want to manage with one workflow. Terraform providers cover Cloudflare, Datadog, GitHub and many more.
Module ecosystem and reuse across teams, where versioned modules matter.
Plan quality. Terraform’s plan output is detailed and reviewable, which suits pull request workflows.
Consolidating tooling after acquisitions that left you with a mix of CloudFormation, ARM and Terraform.
Hiring and skills, if your team already knows Terraform better.

Good reasons not to

You are single cloud, small, and the templates are stable. The benefit is small.
You rely heavily on AWS CDK or SAM and the team likes them. Those are higher-level tools over CloudFormation, and moving loses that productivity.
A vendor-managed product deploys through CloudFormation, such as service-catalog based products, and fights you if replaced.
There is a hard deadline for something else. Do not combine a migration with a critical launch.

We say so in the report when migration is not worth it. Sometimes the best recommendation is to leave the existing stacks and write only new infrastructure in Terraform.

How the assessment works

Inventory

We collect templates and live stack data. For CloudFormation that includes templates, parameters, nested stacks, stack sets, custom resources and drift status. For Azure it covers ARM or Bicep deployments by scope. For each we note the owner, how often it changes and what depends on it.

Scoring

Each stack gets a rating across a few dimensions, and a decision follows:

Dimension	Why it matters
Holds data	Databases and buckets need retain policies and backups first
Complexity	Custom resources, macros and deep nesting have no direct Terraform equivalent
Change frequency	Frequently changed stacks benefit most from Terraform’s workflow
Blast radius	Foundational network and identity stacks need the most careful sequence
Ownership	Stacks owned by another team or vendor may be out of scope

Approach per stack

There are three, and the report names one for each stack:

Import in place. Terraform adopts the live resources. Best for stateful and long-lived infrastructure.
Rebuild and cut over. New resources are created by Terraform and traffic or data moves across. Best for stateless layers that are easy to repoint.
Leave alone. Not every stack needs to move.

What an in-place migration looks like

The sequence matters, and the order protects your data. First, on the CloudFormation side, set resources you care about to be retained, so removing the stack later does not remove them:

Resources:
  OrdersDatabase:
    Type: AWS::RDS::DBInstance
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      # existing properties unchanged

Update the stack so the policy is live. Next, write the Terraform and import the resource using an import block, iterating until the plan is empty:

import {
  to = aws_db_instance.orders
  id = "orders-prod"
}

Once Terraform owns the resource and the plan is clean, delete the CloudFormation stack. Because of the retain policy, the resource stays; only the stack’s record of it is removed. Always take a snapshot of critical data before touching the old stack, and double check that every resource you care about shows as retained.

On Azure, the equivalent flow is to import resources into state, check the plan, and then stop deploying the template to that scope. Be careful with deployment modes: complete mode deployments can remove resources absent from a template, so verify what the old pipeline will do before it runs again.

Decisions and trade-offs

Terraform or OpenTofu. Both read the same language, and the choice depends on licensing and ecosystem preferences. We cover your options in the report.

Rewrite quality. Straight translation reproduces the old structure, including its flaws. Migration is a chance to redesign into reusable modules, but redesign adds scope. We separate “move” from “improve” so one does not stall the other.

Coexistence period. For some time both tools will manage different parts of the estate. We define clear ownership boundaries so two tools never manage the same resource.

Failure modes we avoid

Deleting the stack before retention is set, which deletes the resource.
Nested stack and export dependencies that break when a parent stack is removed. We map cross-stack exports first.
Custom resources and macros with no Terraform equivalent being discovered late.
Importing without a state backup. See remote state setup.

A note on state and ordering

Stacks that export values to other stacks are the usual source of surprises. We migrate consumers before providers where possible, or replace stack exports with explicit data lookups first, so no stack is left pointing at an export that has vanished. Foundations such as VPCs and IAM roles go last in most estates, because everything else depends on them and the cost of a mistake is highest there.

Delivery and handover

The assessment delivers an inventory, stack ratings, a recommended order starting with a low-risk pilot, effort ranges, a risk register, and a written view on whether to proceed. If you proceed, the same team carries out the work. If not, you keep the plan.

How to tell the assessment was worth it

You can make a clear, evidence-based decision. The plan names a first stack and the checks that must pass before the second begins. To start, book a consultation and bring your list of stacks.

References

How we deliver it

Inventory the templates

We list every stack or deployment, its resources, parameters, nested stacks, custom resources and who owns it.

Score the stacks

Each one is rated for complexity, data sensitivity, change frequency and dependencies, producing a migrate, keep or retire decision.

Choose the approach

For each stack we pick: import in place, rebuild and cut over, or leave as is, with the reasoning written down.

Design the safety net

Deletion policies, backups, state snapshots and a rollback plan are defined before any change.

Deliver the roadmap

You receive an ordered plan with effort ranges, risks, a pilot stack recommendation and a view of ongoing tooling costs.

Frequently asked questions

Is there an automatic way to convert CloudFormation to Terraform?

Partial tools exist that translate templates or generate code from live resources, but none produce production-ready results unaided. The safe route is to write Terraform that describes the running resources, import them into state, and confirm a clean plan. Translation tools can speed up the draft but need human review.

How do you migrate without downtime?

By importing existing resources into Terraform state rather than recreating them. For CloudFormation, first set a retain deletion policy on resources so deleting the stack does not delete them. Then import, reach a zero-change plan, and finally remove the old stack with the resources retained.

Should we migrate from CloudFormation to Terraform at all?

Only if it solves a real problem, such as multi-cloud use, a need for a wider module ecosystem, or team familiarity. CloudFormation is well integrated with AWS and works. A migration is an investment with its own risk, so the assessment checks the payback before recommending it.

What about ARM templates and Bicep?

The same principle applies. Azure resources can be imported into Terraform state, and tools such as aztfexport help scaffold code. Bicep is a good Azure-native option, so we assess whether leaving it is worthwhile, particularly if your estate is Azure only.

How long does a migration take?

It depends on the number of stacks, their complexity and how much data they hold. The assessment gives effort ranges per stack after inventory. A pilot stack is usually done first, since it shows the real pace and exposes issues in your templates before the larger work begins.