# Diagnosing a moved block misfire: plan still wants destroy/create
## Symptom
You added `moved { from = ... to = ... }` but the plan still shows destroy of the old address and create of the new one.
## Cause
The moved block did not match: the `from` address does not exist in state, the `to` address is wrong, or the move crosses a boundary moved blocks cannot express.
## Confirmation
1. `terraform state list | grep` for the `from` address. If it is not in state, there is nothing to move; the plan is correct and your `from` is wrong.
2. Check the `to` address against the actual config. Typos in resource names or module paths are the most common misfire.
3. Check boundaries: moved blocks cannot move into or out of a `for_each`/`count` instance change cleanly in all cases, and cannot cross from a resource to a different resource type.
## Fix
1. Correct the `from`/`to` addresses and re-plan. The plan should flip from destroy/create to a no-op move (shown as a move in the plan output).
2. If the move is genuinely inexpressible with moved blocks, do it with `terraform state mv` (same effect, imperative), then codify with a moved block afterwards for the record.
3. Never "fix" a misfired move by letting the destroy/create happen unless you have verified the resource is safe to recreate (stateless, no data).
## Verification
1. The plan shows the move (Terraform reports moved objects explicitly), with no destroy and no create for that resource.
2. After apply, `terraform state list` shows only the new address.
3. Keep the moved block in config as history. Removing it later is safe once every collaborator has applied past the move.