Terraformer Alternatives in 2026: Generate Terraform From Existing Cloud Resources

The best Terraformer alternative in 2026 depends on how many resources you need to bring under code. For a handful, use Terraform's own import blocks with terraform plan -generate-config-out, which is built into Terraform 1.5 and later and into OpenTofu 1.6 and later. For a single cloud, the vendor tools work: aztfexport for Azure, and Former2 or the CloudFormation IaC generator for AWS. For a whole estate across AWS, Azure, Google Cloud and Oracle Cloud, with review and policy checks before anything changes, ops0 Discovery handles the scan, the code, the import and the pull request in one flow.

You need an alternative because Terraformer itself is finished. Its GitHub repository was archived on March 16, 2026, and the README now says the project "is no longer maintained and is deprecated", with no further updates or security patches. The last release, 0.8.30, shipped in March 2025.

What Terraformer Did

Terraformer was a command-line tool, created by the Waze SRE team and hosted under Google's GitHub organization (the README notes it is not an official Google product). It did "reverse Terraform": it read existing resources through the provider's API and wrote two things, Terraform configuration files and a state file. The state file is Terraform's record of which real cloud object each block of code manages. Without it, Terraform would try to create a second copy of everything.

A typical AWS run looked like this:

terraformer import aws --resources=vpc,subnet --regions=eu-west-1 --profile=prod

It supported AWS, Google Cloud, Azure and dozens of SaaS providers, and it needed only read-only permissions. That reach is why it collected more than 14,000 GitHub stars and still gets about 2,900 searches a month in the US.

Why Teams Moved Away From It

Archiving is the final reason, but most engineers gave up on the output earlier. These were the common complaints:

• Output that reads like a dump. By default Terraformer writes one file per resource into a folder per service (generated/aws/vpc/, generated/aws/subnet/). Every attribute comes back as a literal value from the API, with no variables or modules, so the code works but nobody wants to maintain it.

• Cross-service links through remote state. With --connect on, Terraformer ties services together using terraform_remote_state, a data source that reads outputs from another state file. That made each service folder depend on the others instead of on clean references inside one configuration.

• An old state format. The README still lists Terraform 0.13 support and tells you to run terraform state replace-provider to migrate generated state to the current provider address before modern Terraform will use it.

• Broken providers. The README marks the Cloudflare provider as broken, and with the repo archived, no fix is coming.

• All or nothing. Filtering by ID or tag was possible, but there was no way to see resources first, judge which ones mattered, and pick.

Option 1: Terraform Import Blocks and Config Generation

Since Terraform 1.5, you can declare an import in code instead of running the old terraform import command one resource at a time. An import block names the resource address in your configuration (to) and the cloud provider's ID for the real object (id). Here is a production RDS database created in the console:

import {
  to = aws_db_instance.payments_ledger
  id = "rds-payments-ledger-prod"
}

Then ask Terraform to write the matching resource block for you:

terraform plan -generate-config-out=generated.tf

Terraform reads the live database through the AWS provider, writes a resource "aws_db_instance" "payments_ledger" block into generated.tf, and shows a plan that imports it. The file must not exist yet, or the command fails. Review the generated code, fix anything odd, run terraform plan until it shows only the import and no changes, then terraform apply to record the database in state. Nothing in the cloud is modified.

Two cautions from HashiCorp's own documentation. Configuration generation is still labeled experimental, and later minor versions may change its formatting. It can also produce invalid code for resources with complex schemas: the docs show an EC2 example where ipv6_address_count conflicts with ipv6_addresses, and you delete one and plan again. OpenTofu supports the same import block and -generate-config-out flag, also marked experimental.

Newer Terraform releases add bulk import. You write list blocks in a .tfquery.hcl file to search for unmanaged resources of a type, then run terraform query -generate-config-out=generated.tf to get resource and import blocks for everything found. Coverage depends on which resource types your provider supports for listing, so check the provider docs first.

The catch with the native route is discovery. Terraform imports what you name. Finding every console-created resource across accounts and regions, and getting their IDs, is still your job.

Option 2: Cloud-Specific Export Tools

• aztfexport (Azure). Microsoft's Azure Export for Terraform exports a single resource, a resource group, or the results of an Azure Resource Graph query (Azure's query service over every resource in your subscriptions) into HCL plus state. It supports both the AzureRM and AzAPI providers, and Microsoft still maintains it. Microsoft notes the generated configuration is not meant to be comprehensive.

• Former2 (AWS). An open-source web app at former2.com that scans an AWS account with read-only credentials and lets you pick resources to generate CloudFormation, Terraform, CDK or Pulumi code. You choose what to export, which Terraformer never offered. Its own README reports Terraform coverage of about 49 percent of the resource types it scans, and it writes code only, so you still bring each resource into state yourself. Full coverage also needs the Former2 Helper browser extension.

• CloudFormation IaC generator (AWS). AWS's built-in scanner finds resources not managed by CloudFormation in a region and builds a CloudFormation template, which you can import as a stack or turn into a CDK app with cdk migrate. It outputs CloudFormation, not Terraform, so it only helps if CloudFormation is your target. One template holds at most 500 resources.

Terraformer Alternatives Compared

Option 3: ops0 Discovery for a Whole Estate

The native tools cover single resources and single clouds well. The work that stalls codification projects sits around them: finding what exists, deciding what to adopt, importing in the right order and getting the result reviewed. ops0 Discovery covers that whole path, and your engineers stay in control of every step.

• Scan read-only. Pick an AWS account and regions, an Azure subscription, a Google Cloud project or an Oracle Cloud tenancy, and press scan. Discovery uses read-only access and pulls full configuration for each resource, with security findings included. A mid-sized account finishes in under 30 minutes.

• See what is unmanaged. The Assets tab marks every resource as managed or unmanaged by matching IDs and ARNs against your existing state and code, so ClickOps resources (anything created by clicking in a cloud console) stand out. Each one shows its risk and internet exposure before you choose it.

• Pick and generate. Select the resources you want, choose a new or existing project, and ops0 generates Terraform or OpenTofu deterministically, with a status per resource. Retry or drop any that fail. Resources are imported in dependency order, so a VPC lands before its subnets and a subnet before the database inside it.

• Real imported state. Choose the state backend: S3 with locking, Azure Storage, Google Cloud Storage or OCI Object Storage, or keep the project's existing one. Imports go through import blocks, so the state reflects the live resources from the first plan.

• Review before anything applies. You see a diff against the project, the import blocks, IaC security findings and the project's enforced policies before you propose. The change then waits behind the project's approval gate, and nothing is planned or applied from Discovery itself.

• Ship it as a pull request. Push the generated code to a branch in GitHub or GitLab, including self-managed GitLab, and open a pull request or merge request in the same step. Each import gets its own files, so it never overwrites earlier work.

After the first import, the project inventory keeps an "Unmanaged only" view, so the next resource someone creates in the console shows up and can be adopted the same way. See Discovery, IaC projects and the IaC adoption use case. For the AWS-only native walkthrough, read How to Generate Terraform from Existing AWS Resources.

Step-by-step guides are in the docs: import existing resources and migrate ClickOps to IaC.

Which Terraformer Alternative Should You Use?

• A few resources, one account: Terraform or OpenTofu import blocks with -generate-config-out. Free, built in, and the review is quick.

• Azure only: aztfexport. It writes HCL and state for a resource group or a Resource Graph query in one command.

• AWS, CloudFormation as the target: the CloudFormation IaC generator.

• AWS, quick look at the code for a few resources: Former2, then import each resource into state yourself.

• Hundreds of resources, several clouds, and a team that reviews every change: ops0 Discovery, which turns the scan into Terraform or OpenTofu, imported state and a pull request your engineers approve.

Whichever tool you pick, treat generated code as a first draft. The goal is a plan that shows zero changes after import, reviewed by the engineers who will own it.