Yesterday, I was planning a migration from a monolithic Terraform root module to a more decomposed, product-team-owned structure. Before writing a single line of new code or moving any actual resources, I needed a precise inventory of what was currently managed. This is where `terraform state list` and `terraform state show` became my essential planning tools.
First, `terraform state list` gave me the complete, flat list of resource addresses in the state. I piped this to a file for analysis.
```bash
terraform state list > full_state_inventory.txt
```
From this list, I could already start grouping resources by logical component or team ownership (e.g., all `aws_iam_role.my_app_*` resources together). But the addresses alone aren't enough to understand dependencies or specific configurations.
That's where `terraform state show` came in. For each resource of interest, I could get its full, current state details—attributes, IDs, and meta-arguments like `depends_on`. This was crucial for understanding the actual resource graph before attempting to split it.
```bash
terraform state show 'aws_lambda_function.my_app_api' > lambda_state_details.txt
```
My process looked like this:
* Used `state list` to get all resource addresses.
* Filtered and grouped them into potential new state file boundaries.
* Used `state show` on key, complex resources (like those with many dependencies) to document their exact configuration and relationships.
* This documentation became the migration plan and the validation checklist for the post-migration `terraform plan`.
The key takeaway: these commands let you perform a non-destructive, read-only audit of your existing infrastructure as Terraform sees it. It turns a risky, "big bang" migration into a methodical, predictable process. You know exactly what needs to be moved before you run any state `mv` or `rm` commands.
Great approach! State inspection is the unsung hero of any major refactor. Been there, done that, got the t-shirt with "I survived a Terraform state migration" on it.
One pro-tip: after you've got your inventory, run `terraform state list` with the `-state` flag pointing at a backup copy of your state file. That way you're not accidentally poking the live beast while you plan. Saved my bacon once when I fat-fingered a `show` command during a similar split.
Good luck with that split. You're putting a lot of faith in those state commands to reflect reality, but they only show you what Terraform *thinks* it manages. The real fun starts when you find a resource that was created manually five years ago and imported with missing attributes. `terraform state show` won't save you from that mismatch.
always check the last 6 months of reviews
Exactly. That's the joy of 'Terraform-managed' versus 'actually managed.' You can have a beautifully organized state list, right up until you run your first plan after the split and it wants to recreate half a database because some critical attribute wasn't captured during the import. The state commands are great for planning the move, but they won't audit your tech debt for you. You're just moving the clutter into a nicer neighborhood.
null
Right, and that mismatch is why the state list is only the first half of the audit. The real planning starts when you cross-reference `state show` output for key resources against the actual provider API. If your state says a database has no backup retention period set, but the cloud console shows one, you've found a landmine before you move anything.
This is why I treat these migrations like a data integration project. The state file is one system of record, the live infrastructure is another, and you need to map them before you build the new pipeline (the refactored code). The mapping is never 1:1.
Integration is not a project, it's a lifestyle.