Rewrite count as for_each and get the moved blocks the change requires. Without them the refactor destroys every existing instance and creates replacements.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Convert. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Converts, and every instance address changes, so moved blocks are required
resource "aws_subnet" "private" {
count = length(var.availability_zones)
availability_zone = var.availability_zones[count.index]
}Deliberately not converted: this is the one count that beats for_each
resource "aws_instance" "bastion" {
count = var.enable_bastion ? 1 : 0
instance_type = "t3.micro"
}Nothing to key by, so converting would mean inventing keys that carry no information
resource "aws_instance" "web" {
count = 3
}These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Every instance address changes, so Terraform destroys all the existing instances and creates replacements. The plan shows it and it is easy to approve while thinking of the change as a refactor.
Instead:Write one moved block per instance, then plan and confirm zero changes. If the plan shows destroys, stop: the moved blocks are wrong.
count = condition ? 1 : 0 becomes a set that is empty or has one member, which is more code, less readable, and adds a key nobody uses.
Instead:Leave it as a count. That is the case count is genuinely better at.
A set of objects cannot be keyed usefully, and duplicates collapse silently, so you get fewer resources than the count produced with nothing to say why.
Instead:Build the map explicitly: for_each = { for item in var.items : item.name => item }.
count instances live at [0] and [1]. for_each instances live at their key. Terraform sees one set of addresses disappear and another appear, and its default response is destroy and create.
That is the entire risk. A configuration that converts cleanly and applies without moved blocks will destroy and recreate every instance the resource manages. On a subnet that is disruptive; on a database or a volume it is data loss. The plan says so plainly, which is why the rule is to read it and stop if it shows a destroy.
This is the reason to convert at all. Remove the second element of a three-element count and Terraform renumbers the third, so it destroys and recreates something you did not touch. A for_each keyed by a region name or an environment leaves the others alone, because identity comes from the key rather than from position.
count = var.enabled ? 1 : 0 is create-or-do-not, and for_each expresses it as a set that is empty or has one member. That is longer, harder to read, and gives the instance a key nobody needs. This page deliberately refuses to convert it.
A set has neither. A list with a repeated element produces fewer instances than the count did, silently, and nothing reports the difference. For a list of objects, toset will not do at all: build the map yourself with a for expression and choose a key that means something.
aws_subnet.private[0].id has no meaning once the resource is keyed, and the error appears in whichever file holds the reference rather than in the file that changed. Terraform says the resource has no index, which does not mention that the collection type changed.
Before that, the only route is terraform state mv: one person, one state, no plan, and nothing recorded in the repository. Everyone else's state has to be moved by hand the same way. A moved block is reviewed in a pull request and applies everywhere, including in CI.