Struggling to manage existing cloud resources with Terraform? Learn why tools like Terraformer exist, their pros and cons, and three practical strategies for taming your untracked infrastructure.

So, You’ve Inherited a ClickOps Mess. Should You Use Terraformer?

I still remember the feeling. It was a 2 a.m. PagerDuty alert. A key application was failing, and the logs pointed to a permissions issue on an S3 bucket I’d never seen before. A bucket named something like app-data-final-final-PROD. It wasn’t in our Terraform state. It wasn’t in any of our modules. After a frantic search, we discovered a former developer, long since gone, had manually created it in the AWS console for a “quick fix” two years prior. It now held terabytes of critical production data, completely outside of our IaC, a ticking time bomb of configuration drift. That night, wrestling that rogue bucket under Terraform’s control, I really wished for a magic wand. For many, tools like Terraformer seem like that magic wand.

The Root of the Problem: State Drift and Shadow IT

Before we talk about the fix, let’s be honest about the cause. This situation happens for a few common reasons:

• The “Quick Fix”: A developer or sysadmin under pressure needs a resource right now. They jump into the cloud console, click a few buttons, and the problem is solved… for today. This is “ClickOps,” and it’s the primary source of drift between your code and reality.
• Legacy Infrastructure: Your company adopted Terraform last year, but you’ve got five years of infrastructure that was built by hand before that. It works, but it’s a black box.
• Acquisitions & Mergers: You’ve just inherited another team’s cloud account, and their idea of “infrastructure as code” was a series of shell scripts and a well-worn credit card.

In all these cases, you’re left with valuable, running infrastructure that your Terraform state file knows nothing about. Trying to manage it is like trying to navigate a city with a map that’s missing half the streets.

Taming the Beast: Three Ways to Handle Untracked Resources

You can’t just run terraform apply; it would try to destroy the real-world resources it doesn’t know about. So, how do you get that manually-created infrastructure under control? You’ve got a few options, ranging from a surgical strike to a full-blown assault.

Option 1: The Surgical Strike (terraform import)

If you only have a handful of resources to wrangle, the built-in terraform import command is your best friend. It’s a manual, precise process. You write the code, then you tell Terraform to “adopt” the existing resource and link it to your code.

The Workflow:

1. Write the HCL: First, you write the Terraform resource block for the thing that already exists. You have to match the configuration (name, size, type, etc.) as closely as you can.

resource "aws_s3_bucket" "prod_data_archive" {
  bucket = "prod-critical-archive-data-98765"

  tags = {
    Name        = "Critical Prod Archive"
    Environment = "Production"
    ManagedBy   = "Terraform"
  }
}

2. Run the Import Command: Next, you run the import command, telling Terraform: “The code I wrote at aws_s3_bucket.prod_data_archive corresponds to the real-world S3 bucket named prod-critical-archive-data-98765.”

terraform import aws_s3_bucket.prod_data_archive prod-critical-archive-data-98765

3. Plan and Reconcile: Run terraform plan. You’ll likely see some differences between your code and the imported state. This is good! It’s your chance to align your code with the resource’s actual configuration before you apply any changes.

This method is great for one-offs, but it’s incredibly tedious if you have to import an entire VPC with dozens of subnets, route tables, and security groups.

Option 2: The Recon Mission (Using Terraformer)

This is where the big guns like Terraformer come in. Terraformer (and tools like it) does the reverse of Terraform: it scans your cloud account and generates the HCL code and the import commands for existing resources. This is your go-to when you’re facing a whole environment, not just a single resource.

Imagine you need to import a whole VPC (vpc-0123abcd) in us-west-2. Instead of hundreds of manual imports, you could run something like this:

terraformer import aws --resources=vpc,subnet,sg,nat_gateway --filter="Name=vpc-id;Value=vpc-0123abcd" --regions=us-west-2

This will scan your account and spit out a directory full of .tf files and a script to run all the necessary import commands. It feels like magic. But here’s the catch:

Darian’s Warning: Terraformer’s output is a rough draft, not a masterpiece. It generates verbose, explicit, and often ugly code. Your job is to be the editor. You must refactor, modularize, and clean up that generated code before you ever dream of committing it or running terraform apply on it. Think of it as a tool for discovery and bootstrapping, not a one-click solution.

Option 3: The ‘Nuke and Pave’ (Rebuild from Scratch)

Sometimes, the existing infrastructure is such a tangled mess that trying to reverse-engineer it is more work than starting over. This is the ‘Nuke and Pave’ approach. It’s the cleanest, but also the most disruptive.

The process is straightforward:

1. Write the ideal Terraform code for what you need, using proper modules and best practices.
2. Provision this new, clean infrastructure alongside the old, messy one (e.g., prod-db-02 next to the old prod-db-01).
3. Perform a planned migration, moving data and shifting traffic from the old environment to the new one.
4. Once everything is running on the new, Terraform-managed infrastructure, you can confidently decommission the old resources.

This is perfect for non-critical dev/staging environments or during a major, planned production upgrade. It’s a luxury you can’t always afford, but when you can, it’s the best way to pay down technical debt.

My Verdict: Is Terraformer a Hero or a Crutch?

So, should you use Terraformer? Yes, but with your eyes wide open.

I see Terraformer as an essential diagnostic and bootstrapping tool, not a final solution. It’s the machine that takes an existing building and deconstructs it into a giant pile of bricks, wires, and pipes. It shows you everything you have. But it’s still your job, as the architect and engineer, to take that pile and rebuild it into a clean, modular, and maintainable structure.

Don’t just run Terraformer, commit the output, and call it a day. Use it to accelerate your understanding, generate a baseline, and then invest the real engineering effort to refactor that output into IaC you can be proud of. It’s a powerful tool for getting out of a jam, but it’s not a substitute for thoughtful design.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions