Terraform State MV Resource Discovery Fix

Threat/Impact Level: HIGH | Downtime Risk: HIGH | Time to Fix: 10–20 mins

TL;DR

• What broke: terraform state mv cannot locate the source resource because the address you supplied does not match the key Terraform actually stored in state — typically caused by a manual resource rename, module refactor, or provider upgrade that changed the resource type string.
• How to fix it: Run terraform state list to dump every real address in state, find the correct source key, then re-run terraform state mv <correct_source> <destination>.
• Fast path: Use our Client-Side Sandbox above to auto-refactor this — paste your terraform.tfstate or terraform state list output and get the corrected state mv commands generated locally without sending your state file to any external server.

$ terraform state mv 'aws_instance.web' 'module.compute.aws_instance.web'

Error: Invalid target address

The given source address does not match any resource instance in the state.

Resource not found: aws_instance.web

Failed to move resource: Resource 'aws_instance.web' not found in state.

How to Fix It (The Solution)

Step 0: Back up state before touching anything

# Remote backend — pull a local copy first
terraform state pull > terraform.tfstate.backup.$(date +%Y%m%d%H%M%S)

Do not skip this. State corruption without a backup is unrecoverable.

Step 1: Discover the real address

# List every resource address currently in state
terraform state list

# If you suspect a module path or index issue, grep for partial name
terraform state list | grep -i 'web'

# Inspect the full attributes of a candidate resource
terraform state show 'module.compute.aws_instance.web["prod"]'

The output of terraform state list gives you the exact string you must use as the source address in state mv.

Basic Fix

Once you have the correct source address from state list:

- terraform state mv 'aws_instance.web' 'module.compute.aws_instance.web'
+ terraform state mv 'module.legacy.aws_instance.web' 'module.compute.aws_instance.web'

For a count-indexed resource:

- terraform state mv 'aws_instance.web' 'aws_instance.web[0]'
+ # First confirm the exact index in state:
+ # terraform state list | grep aws_instance.web
+ terraform state mv 'aws_instance.web' 'aws_instance.web[0]'

(The command may be identical — the fix is confirming the source address matches exactly what state list returns before running it.)

For a for_each migration from count:

- terraform state mv 'aws_instance.web[0]' 'aws_instance.web["prod"]'
+ terraform state mv 'aws_instance.web[0]' 'aws_instance.web["prod"]'
# Verify with: terraform state show 'aws_instance.web["prod"]' after the move

Enterprise Best Practice: Scripted Bulk State Moves with Validation

For module refactors affecting dozens of resources, never run state mv commands manually one-by-one. Use a validated script:

- # Manual, error-prone one-liner with hardcoded addresses
- terraform state mv 'aws_instance.web' 'module.compute.aws_instance.web'
- terraform state mv 'aws_security_group.web' 'module.compute.aws_security_group.web'

+ #!/usr/bin/env bash
+ # enterprise_state_mv.sh — validate before move, log every operation
+ set -euo pipefail
+
+ BACKUP="terraform.tfstate.backup.$(date +%Y%m%d%H%M%S)"
+ echo "[INFO] Pulling state backup to ${BACKUP}"
+ terraform state pull > "${BACKUP}"
+
+ declare -A MOVES=(
+   ["aws_instance.web"]="module.compute.aws_instance.web"
+   ["aws_security_group.web"]="module.compute.aws_security_group.web"
+ )
+
+ for src in "${!MOVES[@]}"; do
+   dst="${MOVES[$src]}"
+   # Validate source exists before attempting move
+   if terraform state list | grep -qxF "${src}"; then
+     echo "[MOVE] ${src} -> ${dst}"
+     terraform state mv "${src}" "${dst}"
+   else
+     echo "[SKIP] Source not found in state: ${src}" >&2
+   fi
+ done
+
+ echo "[INFO] Post-move state list:"
+ terraform state list

For Terraform 1.1+, prefer moved blocks in HCL over imperative state mv — they are version-controlled, reviewable, and automatically applied during plan/apply:

- # Imperative, untracked, not in version control
- terraform state mv 'aws_instance.web' 'module.compute.aws_instance.web'

+ # In versions.tf or a dedicated moved.tf — tracked in Git, applied automatically
+ moved {
+   from = aws_instance.web
+   to   = module.compute.aws_instance.web
+ }

💡 Tired of pasting proprietary infrastructure configs into public LLMs? Generic AI interfaces log your company's ARNs, connection strings, and private keys. StackEngine enforces client-side zero-trust boundaries—the sandbox above executes 100% locally in your browser. Drop your broken manifest above to redact secrets locally and synthesize deterministic patch drafts with your own API key.

(For CI/CD pipeline automation, install via npm i -g stackengine).

# .github/workflows/terraform.yml
- name: Validate state addresses match config
  run: |
    terraform init -backend=false
    # Fail if any resource in state has no corresponding config block
    # (signals a missing moved{} block or accidental state rm)
    terraform plan -detailed-exitcode 2>&1 | grep -E '^  # .* will be destroyed' && \
      echo '::error::Destroy detected — verify moved{} blocks are present' && exit 1 || true

# sentinel/no-mass-destroy.sentinel
import "tfplan/v2" as tfplan

max_destroys = 2

destroy_count = length(filter tfplan.resource_changes as _, rc {
  rc.change.actions contains "delete"
})

main = rule {
  destroy_count <= max_destroys
}

# In your S3 backend config
terraform {
  backend "s3" {
    bucket         = "my-tf-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "tf-state-lock"
    encrypt        = true
    # Require MFA delete on the S3 bucket at the bucket policy level
    # to prevent accidental state wipes
  }
}