# Diagnosing count-based resources recreating on every change: migrate to for_each
## Symptom
Changing a list variable (removing or reordering one element) makes the plan destroy and recreate many `resource[n]` instances that should be untouched.
## Cause
`count` addresses instances by index: `aws_instance.web[0]`, `[1]`, `[2]`. Removing element 0 shifts every later element down one index, so Terraform sees every shifted instance as a different object: destroy and recreate.
## Confirmation
1. The plan shows destroys and creates in index order, with the changes cascading from the removed/reordered position downward. That cascade pattern is the signature of index shift.
2. Check the config: the resource uses `count = length(var.list)` and indexes into the list. Confirmed.
## Fix
1. Migrate to `for_each` with a stable key: `for_each = toset(var.names)` or a map keyed by name. Instance addresses become `resource["name"]`, stable across reordering.
2. The migration itself needs `moved` blocks, one per instance: `moved { from = aws_instance.web[0] to = aws_instance.web["a"] }`, or `terraform state mv 'aws_instance.web[0]' 'aws_instance.web["a"]'` per instance.
3. Do it in a dedicated change: migrate addressing first (plan should show only moves), then change the list contents.
## Verification
1. After the migration, `terraform plan` is clean: moves recorded, no destroys.
2. Remove one element from the list and re-plan: only that instance is destroyed, the rest untouched. That is the proof the fix worked.
3. Never use `count` for resources addressed by meaningful identity again. count is for N identical disposable things; for_each is for named things.