The Terraform Mistakes Survival Guide: How I Migrated a Monolith State Without Destroying a Single Resource

I migrated a monolith Terraform state without destroying a single resource. Here is how I approached it. There might be better ways to do this, but this worked for me. The Problem We had one massive state file managing all our GitHub resources. Teams. Members. Admins. Permissions. Everything in one place. Every change touched everything. Risky. Slow. Hard to review. If someone needed to add a new team member, the plan would show changes across the entire state. One wrong move and you could accidentally destroy resources that had nothing to do with your change. I was asked to break it into smaller modules. Teams in one state file. Members in another. Each piece moving independently. Sounds simple, right? It was not. The Danger: State Drift During Refactor Here is the problem with splitting state: When you move resources to a new module with its own state file, Terraform does not automatically know those resources already exist. So this happens: New module tries to CREATE the resources (