When Surgery Is Too Risky
terraform state mv is precise and powerful, but it requires that your existing code and state are coherent enough to work with. Sometimes they are not. You might be migrating from Terraform 0.12-era code with no consistent naming conventions, hundreds of manually-imported resources with missing tags, or a state file that has drifted so far from reality that every plan shows dozens of phantom changes.
In these cases, attempting in-place state surgery is like performing open-heart surgery on a patient who is also running a marathon. The risk of making things worse is high. The better strategy is to build a new, healthy system in parallel and cut over.
The Blue/Green Infrastructure Pattern
Blue/Green Infrastructure applies the same concept as blue/green application deployments to entire infrastructure stacks. The old environment (Blue) keeps running while you build and validate the new environment (Green) from scratch.
Phase 1 — Build Green
Create a brand-new Terraform project using current best practices: Terraform 1.5+, consistent naming, proper tagging, a clean layered hierarchy. Deploy it to a parallel set of infrastructure in the same (or a new) AWS account.
Green environment:
green/vpc/ → new VPC (10.1.0.0/16)
green/rds/ → new RDS instance
green/eks-cluster/ → new EKS cluster
green/app/ → new application deployment
Phase 2 — Validate Green
Run your full test suite against the Green environment. Perform load testing. Verify monitoring and alerting are functional. This is the validation gate that Blue/Green makes possible — you cannot validate in-place migrations until after the cutover.
Phase 3 — Sync Data (if applicable)
For stateful workloads like databases, set up replication from Blue to Green. AWS RDS supports read replicas that can be promoted; DynamoDB supports global tables. The goal is to reach a point where Green is receiving all writes and Blue is read-only.
Phase 4 — Cutover
Switch DNS records (Route 53 weighted routing or a simple record update) to point to the Green load balancer. Monitor error rates and latency for 15–30 minutes. Keep Blue running as a rollback target.
Phase 5 — Destroy Blue
Once Green has been stable for your defined confidence window (typically 24–72 hours), run terraform destroy on the old Blue project. The legacy state file and all its complexity disappear cleanly.
When to Choose Each Approach
| Situation | Recommended approach |
|---|---|
| Moving 5–20 resources between stacks | terraform state mv |
| Splitting a monolith into shards, same codebase | terraform state mv + refactor |
| Migrating from Terraform 0.12 to 1.x | Blue/Green |
| Moving between AWS accounts | Blue/Green |
| State file is corrupted or heavily drifted | Blue/Green |
| Re-platforming to a different cloud provider | Blue/Green |
Key Point: Blue/Green infrastructure migration is safer than in-place state refactoring because it separates the concerns of building the new system from validating it. The old environment remains a live rollback target until you have high confidence in the new one. The cost is running duplicate infrastructure during the transition window — a cost that is almost always worth paying for critical production systems.