Terraformer and former2 are free, open source, and genuinely useful. If you need a one-time export of an AWS account to Terraform and you are comfortable running a CLI, they will do it and you should use them. This page is about what happens after the export, and about a set of problems with the output that we can describe unusually precisely, because we vendor Terraformer and maintain patches against it.

Where the open source tools stop

Both tools do one thing: read a cloud account and emit IaC. That is the export. There is no drift monitoring, no scheduling, no review surface, no managed credential handling and no history. Run it again next month and you get another pile of files with no relationship to the first.

For a one-time migration that is exactly right, and paying for anything more would be waste. The question is whether your problem is a migration or an ongoing state of affairs. Most brownfield AWS accounts are the second: infrastructure keeps changing, and an export from six weeks ago describes an account that no longer exists.

What the raw output actually needs

This is the part rarely discussed, and it is the reason a first export can be discouraging. Generated HCL does not necessarily pass terraform validate, and the failures are specific rather than vague.

These are fixes we run over generated output. Each exists because the raw result was wrong in a way that broke a real plan:

  • Quoted depends_on references. Emitted as strings, which is not valid in Terraform 1.x. Every affected file fails to parse.
  • An invalid constraints block on aws_kms_grant. Rejected at validate time.
  • Cross-module ARN references that point at nothing. The output references an output named for an ARN while the generated outputs file defines only the ID, so the reference resolves to nothing.
  • A missing required argument on aws_ecrpublic_repository. The read produces an almost-empty state, so the emitted block has no repository_name and validation fails outright.
  • A region attribute that breaks the whole plan. The scanned region is stamped onto ECR Public resources, but ECR Public exists only in us-east-1. Provider 6.x resolves its endpoint from that attribute and tries to reach a hostname that does not exist, and the error takes down the entire plan rather than one resource.

There is a second class of problem that validates cleanly and then behaves badly:

  • Destroy-and-recreate on a resource nothing touched. Legacy flatmap state leaves some required, force-new attributes empty even after a real refresh, so the first plan reads it as a change from nothing to something and proposes replacement. On the wrong resource that is an outage produced by an export tool.
  • Attributes the AWS API never returns. Terraform-side flags such as force_destroy, skip_final_snapshot and deletion windows cannot be imported because nothing reads them back, so the first plan shows a diff for each one.
  • Provider framework migrations. The AWS provider moved some resources to a newer internal framework, and resources exported under the older assumptions need re-importing.

None of this makes the open source tools bad. It is the honest cost of reverse-engineering a cloud API into a configuration language, and anyone shipping in this space either does this work or ships output that does not plan cleanly. We are describing it because we do it, not to suggest the alternative is broken.

Where Terraformer and former2 are the better choice

  • Budget is zero. They are free and always will be. That is a real argument.
  • You need one export, once. A migration with an end date does not need monitoring.
  • You want full local control. No third party touches your credentials, and for some security postures that is decisive.
  • You want to read the source. Open source means you can see exactly what it does, which is not true of any commercial option including ours.
  • You enjoy the fixing. The problems above are all solvable by hand, and doing so teaches you a great deal about the provider.

Where InfraSync is

  • You want the fixes already applied. The output is post-correction, so the first plan is closer to clean.
  • You want an ongoing view. Scheduled scans and drift detection against an approved baseline, rather than a snapshot with no successor.
  • You want a review surface. An in-browser editor and a pull request through a GitHub App, not a directory of files on someone's laptop.
  • You want managed credentials. Encrypted storage, assumed roles with an external ID, and audit logging, rather than access keys in a shell profile.
  • You want cost analysis alongside. The same read-only access that produces the code produces findings that do not overstate.

The honest summary

Terraformer and former2 give you a screenshot of your account. That is often precisely what you need, and if it is, use them and keep the money.

If what you need is a living record, something that re-reads the account on a schedule, tells you when reality diverges from the code, and puts changes in front of your team as pull requests, that is a different product and it is what InfraSync is.

The generated Terraform is yours either way. Ours is ordinary code in your own repository with no runtime dependency on us, which means the exit cost is the same as with the open source tools: you keep the code and walk away.

Frequently asked questions

Is InfraSync just a hosted Terraformer?

No, though it does use a maintained fork of that engine for part of the generation step and says so. The difference is what surrounds it: corrections applied to the raw output, scheduled re-scans, drift detection against an approved baseline, an in-browser review surface, pull requests through a GitHub App, managed credentials and cost analysis. The export is one step of the product rather than the whole of it.

Why does Terraformer output fail terraform validate?

Several specific reasons. Quoted depends_on references are not valid HCL in Terraform 1.x. aws_kms_grant can emit an invalid constraints block. Cross-module ARN references can point at outputs that were never defined. aws_ecrpublic_repository can be emitted without its required repository_name because the read returns an almost-empty state. Each is fixable by hand, and each has to be fixed before the configuration parses.

Why does my first terraform plan want to destroy and recreate resources?

Usually because legacy flatmap state leaves a required force-new attribute empty even after a refresh, so the plan reads null changing to a value and proposes replacement. Nothing actually changed in AWS. Always read a first plan carefully rather than applying it, because on the wrong resource this produces an outage caused by the export tool.

Are Terraformer and former2 good enough for a one-time migration?

Often yes, and if that is your situation you should use them and keep the money. They are free, open source and locally run, so no third party touches your credentials. Budget for time to correct the output and to read the first plan closely.

What do I get for paying that the free tools do not provide?

Corrections already applied to the output, scheduled re-scans instead of a one-off snapshot, drift detection against an approved baseline, an in-browser review surface and pull requests into your repository, managed and encrypted credential handling with assumed roles, audit logging, and cost analysis from the same read-only access.

Am I locked in if I use InfraSync?

No. The generated Terraform is ordinary code in your own repository with no runtime dependency on us, so the exit cost matches the open source tools: you keep the code and walk away. Revoking the read-only role and removing the GitHub App installation ends all access immediately, from your side rather than ours.