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.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Related prompts
-
Terraform Removed Block Forget-Only Prompt
Use a `removed` block with `lifecycle { destroy = false }` to drop a resource from Terraform management without destroying the real infrastructure — the declarative replacement for `terraform state rm`.
-
Terraform Cross-Account Resource Migration Prompt
Plan moving Terraform-managed resources between cloud accounts or subscriptions without destroy/recreate or data loss.
-
Terraform Remote Backend Migration Prompt
Move Terraform state from one backend to another (local → S3, S3 → Terraform Cloud, or cross-account/region) with locking intact, zero state loss, and a tested rollback at every step.
-
Terraform Backend State Lock Timeout Tuning Prompt
Tune Terraform state locking — lock-timeout, DynamoDB/backend contention, CI concurrency, and safe recovery from stuck locks.
More Terraform prompts & error guides
Browse every Terraform prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.