How to Use the Terraform Config Driven Refactor Planner Prompt to Restructure Live Infrastructure With a Zero Change Plan

Refactoring Terraform used to mean running terraform state mv by hand, hoping you typed every address right, and explaining later what happened in a state file nobody could review. Modern Terraform lets you describe the refactor in configuration with moved, import, and removed blocks, so the change goes through a pull request and a plan proves it. The 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 prompt builds that refactor for you: an address map, the blocks, the plan you should expect, and a cleanup schedule.

What the prompt produces

1. A version check that confirms your Terraform version supports each block type, and tells you what has to wait if it does not.
2. An address map listing every current state address, its new address, and the block that handles it.
3. moved blocks for module extraction and for converting count to for_each with explicit index to key pairs.
4. import blocks for resources created by hand, with the command to generate config and a note to review it.
5. removed blocks with destroy set to false for resources you are handing to another stack.
6. The expected plan summary and the lines that mean you should stop before apply.
7. A cleanup schedule for when each block can be deleted.

How to fill the inputs

TerraformVersion comes from terraform version and your lock file. Block support depends on it, so do not skip it.

StateList is the output of terraform state list. For count resources, add the attribute that tells instances apart, such as a user name, so the index to key mapping is not a guess.

TargetLayout describes where things should end up: new module names, new resource names, and for_each keys.

UnmanagedResources lists anything that exists in your cloud account but not in state, with its real ID from the console.

HandOffResources lists resources another team or stack will own from now on.

ModuleConsumers says whether other teams pin your modules. That changes how long some moved blocks must stay.

Reading the example output

The example moves two S3 resources into a logging module, converts IAM users from count to for_each, imports a bucket made in the console, and hands a security group to the network team:

• Every address is accounted for. The map shows each old address, its new home, and whether moved, import, or removed handles it.
• The count to for_each mapping uses real attributes. Index 0 maps to the user named priya and index 1 to marco because the state list said so, not because of their order in a list.
• The import gets generated config. The prompt runs plan with the generate config flag and tells you to trim computed arguments before merging, which is where most surprise updates come from.
• The removed block keeps the resource alive. With destroy set to false, Terraform simply forgets the security group, and the network team can import it.
• The plan has a clear pass condition. Moves and an import, with nothing to add, change, or destroy. Anything that says replaced or destroyed means stop.
• Cleanup depends on where blocks live. Blocks in the root can go after a clean apply. Moved blocks inside a shared module stay for a release because other teams pin it.

Tips for better results

• Run the refactor in its own pull request with no other changes, so the plan only shows moves and imports.
• Paste the real plan output back into the conversation if it differs from the expected summary and ask the prompt to explain each line.
• Take a state backup through your backend before the first apply, even though the blocks are safer than manual commands.
• Apply in a lower environment first if you have one with the same layout.

Mistakes to avoid

• Do not use moved to change a resource type unless your provider documents support for it.
• Do not merge generated config without reading it. It often includes arguments that cause updates on the next plan.
• Do not delete moved blocks from a shared module right away. Teams who upgrade later still need them.
• Do not edit the state file by hand. The point of this approach is that every change is reviewable.

Who it is for

Platform engineers, DevOps teams, and developers who maintain Terraform for a growing codebase and need to split a monolith, rename resources, or bring hand made resources under management without downtime.

Related PromptDig links

Open the 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 prompt and paste your state list and target layout. For more infrastructure and developer prompts, Browse more prompts. If you have a Terraform or DevOps prompt your team relies on, Share a prompt.