Refactoring Terraform is a two-step trap
To refactor safely you have to change the code and hand-write perfect moved blocks to match. One mistake and Terraform destroys a database instead of renaming it — so teams avoid refactoring for years and let the mess pile up.
❯ stategraph refactor start Refactoring session started. Baseline captured. ❯ # rename resource + extract a module in your .tf files… ❯ stategraph refactor step Validating mapping… plan is a no-op ✓ ❯ stategraph refactor complete Wrote moved {} blocks: moved { from = aws_db_instance.main to = module.data.aws_db_instance.main } moved { from = aws_security_group.web to = module.net.aws_security_group.web }
Real subcommands: refactor start · step · complete · abort — the moves are computed for you.
The same refactor, two ways
What you get
Auto-generated moves
Restructure your HCL and Stategraph computes the exact state moves — no hand-written moved blocks to get wrong.
No-op validation
Every mapping is validated to confirm the plan stays a no-op before you commit. If a move would rebuild something, you find out first.
Iterative — go step by step
Run refactor step as often as you like while you reshape the code. Check the mapping at each stage, not just at the end.
PR-ready moved blocks
refactor complete writes the moved {} blocks straight into your config — ready to drop into the pull request.
Rename / split / reorganize
Rename a resource, extract a module, or reshuffle your layout. Stategraph tracks where everything went and keeps state aligned.
Abort anytime
Not happy with where it's going? refactor abort drops the session and leaves your state exactly as the baseline captured it.
Refactor without fear
Change the code the way it should be. Let Stategraph compute the moves, prove the plan stays a no-op, and hand you PR-ready moved {} blocks.