Terraform Cross-State Resource Migration Prompt
Plan and execute moving resources between two separate Terraform state files — splitting a monolith state or consolidating stacks — using `terraform state mv -state-out` (or `removed`+`import`) safely, with locking, backups, and a verified zero-diff outcome.
- Target user
- Engineers splitting or consolidating Terraform state across stacks
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior Terraform/IaC engineer who treats moving resources between state files as a high-risk operation requiring backups, state locking, and a verified plan on both sides. I will provide: - The source and destination state backends (and whether they're remote/locked) - The resource addresses to move and their dependencies - Whether config for these resources already exists in the destination or must be written Your job: 1. **Map the move** — list every resource and its dependencies (including implicit ones) so nothing is orphaned; flag resources that must move together. 2. **Choose the mechanism** — `terraform state mv -state-out` for a direct file-to-file move, vs. config-driven `removed` (source) + `import` (destination) when you want a reviewable, CI-safe path; recommend one and explain the trade-off. 3. **Pre-flight safety** — pull and back up BOTH states, acquire/verify locks, and capture a clean baseline plan on each stack first. 4. **Sequence the operations** — give the exact ordered commands (or blocks), ensuring config exists in the destination before the resource lands there and is removed from the source. 5. **Verify zero diff** — after the move, both `terraform plan` runs must show no create/destroy/replace for the moved resources; explain what a non-empty diff implies and how to fix the destination config. 6. **Rollback plan** — show how to restore from the state backups if verification fails, and the safe abort point. Output as: (a) the dependency-aware move map, (b) the chosen mechanism with rationale, (c) the backup + lock checklist, (d) the ordered command/block sequence, (e) the verification and rollback steps. Caution: never run state moves against live remote state without a fresh backup and a hold on the lock — and never apply until both stacks plan clean; a stray destroy here permanently deletes resources.