Terraformer — the tool that reverse-engineered your existing cloud infrastructure into Terraform HCL — was archived in March 2026. Read-only, no new releases, no maintainer. If you’ve been using it for bulk imports of existing AWS or GCP accounts, you need a plan.

What terraformer did, for context

The problem it solved: you inherited a cloud account full of manually-clicked resources. terraform import requires one resource at a time and you still have to write the HCL schema by hand first. With 200 security groups and 50 VPCs that’s not a workflow, it’s a punishment.

Terraformer flipped this. Point it at your account, it calls the provider APIs, generates .tf files and a terraform.tfstate for everything it finds. Not clean output, not production-ready — but a starting point you can actually terraform plan against. For bulk migrations it was the fastest thing available.

aws-vault exec my-profile -- terraformer import aws \
  --resources=vpc,subnet,security_group,ec2_instance \
  --regions=us-east-1 \
  --filter="Name=tags.Env;Value=prod"

Output lands in generated/aws/<region>/<resource_type>/ with a main.tf, outputs.tf, provider.tf, and local terraform.tfstate per resource type. You’d then spend an afternoon renaming tfer--i-0abc123def456 to something human, ripping out deprecated attributes like enable_classiclink, filling in missing secrets (aws_db_instance.password is never readable from the API), and migrating the state to S3. Tedious but tractable.

That workflow still works today. The tool still runs. But you’re on a clock.

What breaks and when

Provider version pinning — already biting people. Terraformer bakes a provider version into each generated provider.tf. The last release shipped with AWS provider ~4.x expectations. AWS provider 5.x dropped and renamed attributes. Running terraform plan on old terraformer output against a current provider gives you:

Error: Invalid version constraint

  on provider.tf line 4, in terraform:
   4:     aws = "~> 4.0"

An argument named "enable_classiclink" is not expected here.

Fix: edit the generated provider.tf, bump the version constraint, delete the dead attributes. One-time cleanup, not fatal — but it’s manual work with no upstream fix coming.

New resource types are frozen. Terraformer has a hardcoded list of supported resource types per provider. Anything AWS, GCP, or Azure shipped after March 2026 doesn’t exist in Terraformer’s world. If you need to import aws_verifiedaccess_instance or aws_bedrockagent_agent or whatever landed in the last six provider releases, you’re doing it by hand.

State format divergence — the slow-burn problem. Terraformer shells out to the provider binary and manipulates state files directly. If the Terraform or OpenTofu state format changes in a future release, Terraformer might produce state files that look fine but behave wrong. This is the failure mode that won’t announce itself with a clean error message.

The short version: for a one-shot migration you ran last year — you’re probably fine, clean up the provider pins and move on. For anything you’re still running as part of a pipeline — stop, you’re accumulating risk.

What to use instead

There’s no drop-in replacement with the same breadth. But Terraform 1.5+ built native import capabilities that cover most of what people actually used Terraformer for.

Terraform 1.7 import blocks with for_each. The import block replaced the old terraform import CLI command. It’s declarative, lives in your .tf files, and is reviewable in PRs. Terraform 1.7 added for_each so you can bulk-import lists of resources:

# import.tf
locals {
  vpc_ids = ["vpc-0abc123", "vpc-0def456", "vpc-0ghi789"]
}

import {
  for_each = toset(local.vpc_ids)
  id       = each.value
  to       = aws_vpc.imported[each.value]
}

resource "aws_vpc" "imported" {
  for_each = toset(local.vpc_ids)
  # intentionally empty — terraform fills this in
}

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

-generate-config-out is the key flag. Terraform writes the full resource configuration to generated.tf based on what it reads from AWS. Review it, clean it up, then terraform apply to pull the resource into state. The output is cleaner than Terraformer’s because it’s generated by the same provider that will manage the resource — no version drift, no deprecated attributes.

The catch: you need the resource IDs upfront. Terraformer discovered them for you by calling ListVpcs, DescribeInstances, etc. With native import blocks you’re doing that discovery yourself:

# Get all VPC IDs in a region, build the local variable
aws ec2 describe-vpcs \
  --query 'Vpcs[].VpcId' \
  --output text | tr '\t' '\n'

More steps, but it’s just AWS CLI piped into HCL. Write a small script per resource type once, reuse it. No abandoned third-party dependency in your critical path.

OpenTofu has the same import block feature and is under active development via the Linux Foundation. If you moved off Terraform after the BSL licensing change, it works identically — same syntax, same -generate-config-out flag.

Script your own discovery layer. Some teams skip third-party tooling entirely and write a small script that calls the AWS API, emits import blocks, and feeds them to terraform plan -generate-config-out. Ugly to write once, completely under your control forever:

#!/bin/bash
# generate-vpc-imports.sh
echo 'locals { vpc_ids = ['
aws ec2 describe-vpcs \
  --query 'Vpcs[].VpcId' \
  --output text | tr '\t' '\n' | sed 's/.*/"&",/'
echo '] }'

Not pretty. In 2026! But it has zero dependencies and won’t break when a provider version bumps.

The migration path if you’re still on terraformer

If you have existing state files generated by Terraformer that you’re still managing, the approach is:

  1. Pin your provider versions in versions.tf to whatever Terraformer generated, run terraform plan, fix the drift.
  2. For each resource type, decide: keep managing it with Terraform (migrate the state to a proper backend) or accept it as unmanaged.
  3. For new imports going forward, use native import blocks. Stop reaching for the Terraformer binary.
  4. Gradually replace the generated tfer-- resource names with terraform state mv as you touch each module. Don’t try to do it all at once.

You don’t need to migrate everything overnight. Terraformer-generated state is just state — Terraform doesn’t know or care how it got there. The urgency is about new imports and provider compatibility, not the existing state files.

tl;dr

Terraformer is archived. It still runs, but provider drift will bite you and new resource types are frozen as of March 2026. For one-shot migrations of existing infra: still the fastest option today, clean up the provider pins, don’t plan to run it again. For anything ongoing: switch to Terraform 1.7 native import blocks with -generate-config-out. More setup, better output, actually maintained.

Know what you are doing and have fun!

3h4x