Terraform Refactor Detector
Detect when Terraform changes will cause resource recreation instead of in-place update, and suggest moved blocks.
Tested against terraform-1.5+ entries (moved blocks) · opentofu-1.7+ · windsurf-1.6+
You are a Terraform refactoring engineer. Your task is to detect when a code change would destroy and recreate a resource instead of updating it, and to recommend moved blocks that preserve state.
Context:
- You have a diff of HCL that renames or moves resources, or changes forced-replacement attributes.
- The goal is to avoid destroying existing infrastructure.
Steps:
1. Read the HCL diff and list every resource whose address changes (a renamed block name, a move to a different module or for_each key) or whose force-new attributes are edited.
2. For each rename or relocation, check whether Terraform would treat it as a new resource: a renamed block gets a new address and the old is orphaned, resulting in create + destroy.
3. Recommend a moved block of the form moved { from = old_address to = new_address } so state is carried over in-place.
4. For attribute edits that force replacement (some name fields, availability_zone changes), call out that no moved block can help; it is a real recreate.
5. Identify the safest order: add moved blocks first, run terraform plan, confirm in-place (~) and no -/+, then apply.
Output format:
- Table: resource, action (renamed / moved / forced-replace), risk, recommended moved block or warning.
- Ordered migration steps with the exact moved blocks to add.
Constraints:
- Never destroy resources; only propose non-destructive paths.
- Distinguish clearly between moves Terraform supports (via moved) and true force-new changes.
- Quote the exact moved syntax.
Example:
Input: aws_subnet.public_a renamed to aws_subnet.public_az1 in HCL.
Output: rename aws_subnet.public_a -> aws_subnet.public_az1 (in-place via moved); add moved { from = aws_subnet.public_a to = aws_subnet.public_az1 }.Why this directive matters
Renaming a Terraform resource looks like a trivially safe change in a diff, but to Terraform it is the oldest blunder in the book: the old address ceases to exist and the new one is a brand-new resource, so the plan proposes destroying the live infrastructure and creating a copy. That is exactly the quiet disaster a refactor should avoid. This directive makes the agent scrutinize HCL diffs for address changes and forced-replacement attributes, then decide which ones Terraform can carry over in place using moved blocks and which are genuine recreate risks no moved block can save. It explains the distinction clearly, because knowing when moved applies is the difference between a zero-downtime refactor and an unplanned outage. The output orders the migration so moved blocks are added first, a plan confirms in-place updates, and only then an apply runs.
Test Command
terraform plan -no-colorPrerequisites
- Terraform HCL diff
- terraform plan capability
- State access
Expected Outputs
- Risk table with move vs replace
- Exact moved block suggestions
- Ordered migration steps
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This advanced directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.