You inherit a Terraform project managing about 60 live resources whose state is a local terraform.tfstate file. How do you move it onto an S3 backend without destroying or recreating anything?

## The order of operations Migration is mechanically simple and unforgiving about sequence, so it is worth being explicit about each step. **1. Create the backing store first.** Terraform cannot create the bucket that holds its own state in the same run that starts using it. The standard resolutions are: create the bucket manually or with the cloud CLI; or keep a tiny separate "bootstrap" root module that creates the bucket and deliberately keeps its own state local and committed nowhere important. Whichever you choose, enable object versioning on the bucket at creation time — that is your only recovery path if state is later corrupted — and enable encryption at rest. **2. Declare the backend.** Add the block to the `terraform` block in the root module: ```hcl terraform { backend "s3" { bucket = "acme-tfstate" key = "prod/network/terraform.tfstate" region = "eu-west-1" encrypt = true } } ``` The `key` is the object path inside the bucket, and it is worth choosing a convention now — one key per root module, namespaced by environment — because moving it later means another migration. **3. Re-initialise with migration.** Run `terraform init -migrate-state`. Terraform detects that the previously recorded backend (cached in `.terraform/terraform.tfstate`, which stores the *backend configuration*, not your resources) differs from the one in the configuration, and prompts: ``` Do you want to copy existing state to the new backend? ``` Answering yes uploads the local state to the new location. In automation, `-force-copy` accepts that prompt non-interactively. Without `-migrate-state`, newer Terraform versions error out rather than guess what you meant. **4. Verify with a plan, not with a feeling.** `terraform plan` must report "No changes. Your infrastructure matches the configuration." That single line proves the 60 resources are still mapped to their real IDs at the new location. If instead you see 60 creates, the remote state is empty — stop immediately and do not apply, or you will build a duplicate estate alongside the real one. **5. Clean up deliberately.** Keep the local `terraform.tfstate` and `terraform.tfstate.backup` files until you have had a successful apply through the new backend, then remove them, and make sure `*.tfstate*` and `.terraform/` are gitignored so nothing drifts back. ## The failure modes worth naming **Answering "no" to the copy prompt.** You get a fresh, empty state in the bucket. Every subsequent plan proposes creating the whole estate. The recovery is to re-run init pointed back at the local state and migrate again properly — but if someone applied in between, you now have duplicated resources to reconcile by hand. **Someone else applying during the window.** Migration is not atomic across humans. Announce it, and make sure no other engineer is mid-apply with their own copy of the local state, or their write lands nowhere anyone will look again. **Wrong key, silently.** If the `key` points at an object another root module already uses, migration will happily overwrite it. One key per root module is a rule, not a style preference. **Confusing `-migrate-state` with `-reconfigure`.** `-reconfigure` tells Terraform to discard the recorded backend configuration and initialise fresh *without* copying state. Running it here gives you an empty remote state and a local file Terraform no longer looks at. Use `-migrate-state` when you want the data to move; use `-reconfigure` only when you are deliberately re-pointing at a state that already exists. ## What migration is not Migration copies the state document byte-for-byte to a new home. It does not touch real infrastructure, does not renumber resource addresses, and does not need `import` — the resource-to-ID mappings are already in the file. If you also want to *reorganise* addresses, that is a separate concern and a separate change; doing both at once makes it impossible to tell which step caused a surprise diff. The same procedure works in reverse and sideways: removing the backend block and re-running `terraform init -migrate-state` pulls state back down to local, and pointing the block at a different bucket moves it again. It is one mechanism, not a one-way door. ## How to say it in an interview "Bucket first with versioning on; add the backend block; `terraform init -migrate-state` and accept the copy; then `terraform plan` must say no changes. If it says sixty creates, the state did not come with me and I stop."