Terraformer Alternatives, Chosen by the Limit You Hit

• The four reasons people look for an alternative
• What actually breaks in the output
• The alternatives, and what each is actually for
• Choosing by the limit you hit
• The honest position
• Frequently asked questions

Terraformer's niche is whole-account export: point it at a cloud, name the services, and get HCL plus state for everything it finds. If you have hit its limits, the useful question is which limit, because the alternatives are good at different things and several of them are free.

We maintain a patched fork of that engine, so the failure modes below are ones we fix rather than ones we read about.

The four reasons people look for an alternative

Worth identifying which one is yours, because it changes the answer completely.

1. The output does not validate or plan cleanly. Most common, and the most fixable. Details below.
2. It is a snapshot and you need a process. No scheduling, no drift detection, no history. Run it twice and the two results have no relationship.
3. Coverage gaps. A service you need is unsupported or partially supported.
4. Operational burden. Local install, local credentials, local state files, and someone has to own it.

What actually breaks in the output

These are specific and they recur. Knowing them tells you whether the fix is an afternoon or a different tool.

Configuration that will not parse. depends_on references get emitted as quoted strings, which is not valid in Terraform 1.x. aws_kms_grant can carry an invalid constraints block. Cross-module references can point at an ARN output that the generated outputs file never defined. Each fails at validate time, and each is a mechanical fix once you know to look.

A missing required argument. When a resource's read returns a nearly empty state, the emitted block can be missing an argument the provider requires. aws_ecrpublic_repository without repository_name is the example we hit; validation fails outright.

A region attribute that takes down the entire plan. The scanned region gets stamped onto resources that exist in only one region. ECR Public lives in us-east-1, so provider 6.x resolves its endpoint from that attribute and tries to reach a host that does not exist. That failure is not scoped to the resource; it errors the whole plan.

Destroy-and-recreate on something nobody touched. Legacy flatmap state can leave a required, force-new attribute empty even after a genuine refresh. The first plan reads that as null becoming a value and proposes replacement. This is the one to be careful about, because applying it causes a real outage from a tool that only exported.

Attributes the API never returns. Terraform-side flags like force_destroy and skip_final_snapshot cannot be imported, because nothing reads them back. Your first plan shows a benign diff for each.

The alternatives, and what each is actually for

Terraform's own import block

Since Terraform 1.5 you can declare an import block and run terraform plan with -generate-config-out to have Terraform write the configuration for you. Official, free, and the output is by definition compatible with the provider version you are running.

The trade is that you supply the identity of every resource. Terraform does not go and discover your account. That makes it excellent for tens of resources and painful for thousands. Our import block tutorial covers the mechanics and where it stops scaling.

AWS's own template generation

AWS can scan an account and generate a CloudFormation template from discovered resources, which can then be taken into CDK. If you are not committed to Terraform, this is a serious option and it comes from the party that owns the APIs.

It is the wrong path if Terraform is the requirement, since you would be converting between IaC languages to get there.

former2

Browser-based, no install, and it emits several formats rather than only HCL. Better than Terraformer when you want to pick specific resources rather than sweep a whole account. Covered in more depth on the former2 alternatives page.

Pulumi's import

If you are open to leaving HCL behind, Pulumi can import existing resources and generate code in a general-purpose language. That is a bigger decision than picking an exporter, and it is the right one only if the language change is something you wanted anyway.

Commercial platforms

Firefly, ControlMonkey, Brainboard, CloudGeni and InfraSync all address parts of this. They differ sharply in scope and in how much authority they take over your account. The full comparison lays out the matrix, and each has its own page.

Choosing by the limit you hit

The honest position

Terraformer is good software solving a genuinely hard problem, and the fact that we build on a fork of it rather than replacing it says what we think of it. Reverse-engineering a cloud API into a configuration language produces rough edges no matter who does it. Anyone in this category is either doing the correction work or shipping output that does not plan cleanly.

If you need one export and you can spend an afternoon on the result, Terraformer is free and it works. If you need the account re-read on a schedule, drift surfaced against a baseline, and changes arriving as pull requests, that is not a limitation of Terraformer. It is a different product, and the comparison is here.

Frequently asked questions

What is the best alternative to Terraformer?

It depends which limit you hit. For tens of resources, Terraform's own import block with -generate-config-out is official and free. For picking specific resources rather than sweeping an account, former2. For drift detection and scheduling, a managed platform, because no exporter does that. If your only problem is output that does not validate, you may not need a different tool at all.

Why does Terraformer output fail terraform validate?

Several specific reasons: depends_on references emitted as quoted strings, which is invalid in Terraform 1.x; an invalid constraints block on aws_kms_grant; cross-module references pointing at an ARN output that was never defined; and resources emitted without a required argument when their read returns a nearly empty state. Each is mechanical to fix once you know to look.

Can Terraform import an entire AWS account by itself?

Not by discovery. Since Terraform 1.5 an import block plus terraform plan -generate-config-out will write configuration for you, but you supply the identity of every resource. Terraform does not go and enumerate your account, which makes the native path excellent for tens of resources and painful for thousands.

Why does my first plan want to destroy and recreate resources after an export?

Usually because legacy flatmap state left a required force-new attribute empty even after a genuine refresh, so the plan reads null becoming a value and proposes replacement. Nothing changed in AWS. Read a first plan closely rather than applying it, because this is how an export tool causes a real outage.

Is former2 better than Terraformer?

They suit different jobs. former2 runs in a browser with no install and emits several IaC formats, which is better when you want to select specific resources. Terraformer sweeps whole accounts and services at once and emits HCL with state, which is better for bulk codification.

Should I pay for a tool or fix Terraformer's output myself?

Fix it yourself if you need one export and can spend an afternoon on the result. Terraformer is free and it works. Pay only if you need the account re-read on a schedule, drift surfaced against a baseline, managed credentials and a review surface, because none of those are things an exporter is trying to do.