Back to Discover

#refactoring

1 prompt found

Terraform Config Driven Refactor Planner: moved, import, and removed Blocks for Module Extraction, count to for_each Conversion, and Adopting Unmanaged Resources Without state mv
๐Ÿ’ป Coding

Terraform Config Driven Refactor Planner: moved, import, and removed Blocks for Module Extraction, count to for_each Conversion, and Adopting Unmanaged Resources Without state mv

PpromptstudioยทOct 6, 2026
No rating

Plan a Terraform refactor that ends in a zero change plan: an address map from old to new resource addresses, moved blocks for module extraction and count to for_each keys, import blocks with generated config for resources created by hand, removed blocks with destroy set to false for resources you are handing off, the plan output you should expect, and a cleanup schedule for module consumers.

Act as a Terraform platform engineer who refactors live state with config driven blocks instead of terraform state mv, so every change is reviewed in a pull request and proven by a plan that shows moves and imports with nothing to destroy. Inputs: - Terraform CLI version and provider versions from the lock file: [TerraformVersion] - Current resource addresses from terraform state list: [StateList] - The target layout (new modules, new resource names, new for_each keys): [TargetLayout] - Resources that exist in the cloud account but not in state, with their real IDs: [UnmanagedResources] - Resources to stop managing here without deleting them (handed to another team or stack): [HandOffResources] - Who consumes these modules (only this root, or other teams pinning versions): [ModuleConsumers] - Output format: [Format] Generate: 1. A version check: moved blocks need 1.1 or later, import blocks 1.5 or later, removed blocks and for_each inside import 1.7 or later. If TerraformVersion is older, say which steps must wait or fall back to state commands. 2. An address map table: every StateList address, its new address from TargetLayout, and the block that handles it (moved, removed, or none). 3. moved blocks for module extraction (from = aws_x.name to = module.child.aws_x.name) and for count to for_each conversion with explicit index to key pairs. Never guess which index maps to which key; derive it from the attributes in StateList or ask. 4. import blocks for UnmanagedResources with to and id, plus the command terraform plan -generate-config-out=generated.tf and a note to review and trim the generated config before merging. 5. removed blocks for HandOffResources with lifecycle { destroy = false }, and a reminder to delete the matching resource blocks. 6. The expected plan summary: each move listed as has moved to, each import as will be imported, and 0 to add, 0 to change, 0 to destroy. List any line that would mean stop and fix before apply. 7. A cleanup schedule: when each block can be deleted, based on ModuleConsumers. Blocks in the root can go after a clean apply; moved blocks inside a shared module stay for at least one released module version when other teams pin it. Constraints: - Do not use moved to change a resource type unless the provider documents support for it. - Do not invent resource IDs, ARNs, or attribute values. Mark unknowns as FILL FROM CONSOLE. - Assume remote state with locking; never suggest editing the state file by hand. No em dashes.