Claude/ChatGPT Prompt to Refactor Monolithic Terraform State into Modules

What this prompt does

This prompt frames the model as a senior platform engineer planning a refactor of one giant Terraform state into modular stacks, specified tightly enough to execute -- exact commands, not vague advice. You provide [state_size], [target_stacks], [backend_type], and [risk_tolerance], and it returns a carve-up plan, per-stack backends, a state-move decision matrix, dependency passing, a staged rollout, and a rollback path.

The structure works because splitting state is where you risk nuking resources mid-apply. [target_stacks] defines the ownership boundaries the resources get grouped into. [state_size] sizes the decision between terraform state mv, import, and moved blocks for each group. [backend_type] configures isolated, locked state per stack. [risk_tolerance] orders the rollout by blast radius, with a plan-equals-no-op check at each step. A pre-flight backup and a rollback path keep a botched move recoverable, which is what lets you split state without betting the whole estate on one apply.

When to use it

• Everything lives in one giant state file and you need to split it safely.
• You want an ordered runbook with exact CLI commands, not high-level guidance.
• You need a decision matrix for state mv vs import vs moved blocks per resource group.
• You want per-stack backends with isolation and locking.
• You need dependency passing between stacks via remote state or data sources.
• You require a pre-flight backup and a rollback path before touching state.
• You need drift detection after the split so a later move can't silently corrupt state.

Example output

You get an ordered runbook: a pre-flight backup step, the carve-up grouping resources into your target stacks, per-stack backend config with locking, the move decision matrix, the cross-stack dependency wiring, and a staged rollout ordered by blast radius -- each step verified by a plan that shows a no-op. The exact CLI commands are included so it reads as something you execute step by step rather than a strategy you still have to translate into commands.

Pro tips

• Define [target_stacks] by ownership (network, compute, data, shared) so the carve-up boundaries are clean.
• Give a realistic [state_size] so the matrix picks state mv vs import vs moved blocks at the right scale.
• Match [backend_type] to your setup (S3 backend with DynamoDB locking) so isolation and locking are configured correctly.
• Always force the backup and a state pull before the first mv -- recovering from a botched move is brutal otherwise.
• Verify plan = no-op at each step before moving on; a drifting plan means a move didn't land as intended.
• Order the rollout by blast radius matched to [risk_tolerance] so the riskiest moves happen last, off-hours.
• Pass cross-stack values through remote state outputs rather than duplicating IDs across [target_stacks].