The release of OpenTofu 1.7.0-alpha, particularly the `refactoring` subcommand for its CLI, represents a significant step towards mitigating one of the most labor-intensive and error-prone aspects of IaC migrations: restructuring state files to align with refactored code. Having spent considerable time manually manipulating state via `terraform state mv` during a recent large-scale migration from a monolithic root to a decomposed module structure, I am keenly interested in empirical data on its efficacy.
Initial examination of the documentation suggests the tool operates by analyzing the diff between a current state file and a proposed refactored configuration, then generating a move plan. The critical questions from a methodological standpoint are:
* **Accuracy & Edge Cases:** How robust is the graph analysis in complex, real-world scenarios with nested modules, `count`/`for_each` resources, and external dependencies (e.g., `depends_on`)? Does it correctly identify and propose moves for `terraform_data` resources or other non-standard provider resources?
* **Integration with Workflow:** The process appears to require a `tofu state pull` first. How does this integrate with remote state backends (e.g., S3, Terraform Cloud)? Is the generated plan a simple list of `tofu state mv` commands, or does it offer a more atomic application mechanism?
* **Risk Assessment:** What validations are performed to ensure proposed moves do not violate provider-specific constraints or cause destructive actions? The documentation mentions a "safety check" – what is its coverage?
I have not yet been able to conduct controlled benchmarks due to the alpha status. I am seeking reviews from anyone who has performed a comparative analysis, ideally against a manual baseline. Specific points of interest:
* A comparison of time-to-completion and error rates for a given refactoring task (e.g., moving 50 resources across module boundaries) using the assistant versus manual `state mv` operations.
* Any observed limitations with complex state structures (e.g., modules using `for_each`).
* The clarity and safety of the generated move plan. Does it provide sufficient context for review?
A preliminary, hypothetical code block for the command structure as I understand it:
```bash
# Pull current state for analysis
tofu state pull > current_state.tfstate
# Generate a move plan by comparing current state to new configuration
tofu state refactoring -state=current_state.tfstate -config=./new_config_dir move-plan.json
# Review and then apply the generated plan
tofu state refactoring apply move-plan.json
```
Concrete data on these points would greatly inform its suitability for inclusion in a production migration pipeline, or if it remains a convenience tool for simpler use cases.
Test it yourself.
Good questions. I tested it on a dev stack last week. It caught most moves for our basic modules, but stumbled on a nested `for_each` where the value came from a resource attribute. The plan missed that link and wanted to delete the resource.
Workflow wise, yes you pull first. It feels a bit manual, but that's likely because it's alpha and they need a clean local state copy to analyze. I'd want it to integrate with remote state backends directly in a future version.
Automate the boring stuff.