Move Terraform State Between AWS Accounts (Step-by-Step Guide)

If you need the general background on Terraform state, start with Terraform State Explained: Remote State, Locking, Backends and Best Practices. This page is intentionally narrower: it focuses on moving Terraform state between AWS accounts without breaking your workflows.

Quick Answer

To move Terraform state to a new AWS account or backend, initialise the new backend config then use terraform state pull and terraform state push. Example:

# Pull current state
terraform state pull > terraform.tfstate.backup

# Update backend config in main.tf, then:
terraform init -migrate-state

# Verify
terraform state list

Key takeaways

• Moving state between AWS accounts is usually driven by account consolidation, stronger security boundaries, compliance requirements, or a change of ownership.
• The safest approach is to back up the existing state, freeze infrastructure changes during the move, and validate the new backend with terraform plan before anyone resumes normal work.
• If your Terraform configuration can authenticate to both the old and new backends, terraform init -migrate-state is often the cleanest migration path.
• If you need more control, you can use a manual pull and copy workflow, then reinitialize Terraform against the destination backend.
• Do not forget to review downstream consumers that use terraform_remote_state.

When would you move Terraform state between AWS accounts?

Moving state between AWS accounts is common when a team reorganizes environments, splits shared services from product workloads, or tightens control around production infrastructure. The state location itself becomes part of your operational boundary, so moving it can be as important as moving the resources it describes.

• Account consolidation: reducing sprawl and centralizing operations.
• Ownership changes: handing infrastructure to a new team or business unit.
• Security isolation: placing state in a better controlled account.
• Compliance: meeting data residency or control requirements.

Prerequisites before you begin

1. Make sure no one is applying infrastructure changes during the migration window.
2. Confirm you have access to the source and destination AWS accounts.
3. Back up the current state file before touching anything.
4. Create the destination backend resources first, such as the target S3 bucket and any supporting locking or access-control setup your workflow requires.
5. Review any other projects that consume this state through terraform_remote_state.

Preferred approach: let Terraform migrate the backend

If you are changing backend configuration and Terraform can still authenticate to both the old and new locations, update the backend settings and let Terraform handle the migration.

terraform init -migrate-state

This is often cleaner than moving the file yourself because Terraform understands that the backend has changed and can walk you through the migration. It is still important to keep a backup and validate the result with a plan.

Manual migration workflow

If you cannot use backend migration directly, use a controlled manual process.

Step 1: Pull and back up the current state

# Credentials point to the source account
terraform state pull > terraform.tfstate

Keep a second copy of the file somewhere safe before you continue.

Step 2: Update backend configuration for the destination account

Adjust backend.tf or your backend configuration file so Terraform points to the new S3 bucket, key path, region, and any account-specific access settings.

bucket = "my-new-state-bucket"
key    = "networking/prod/terraform.tfstate"
region = "eu-west-1"

Step 3: Copy the state file into the destination backend

# Credentials point to the destination account
aws s3 cp terraform.tfstate s3://my-new-state-bucket/networking/prod/terraform.tfstate

Step 4: Reinitialize Terraform against the new backend

terraform init -reconfigure

Step 5: Validate before anyone resumes work

Run a plan immediately after the migration and confirm Terraform does not propose unexpected changes.

terraform plan

What can go wrong?

• Stale writes: someone changes infrastructure during the migration window.
• Permission gaps: the destination account cannot read or write the new backend path.
• Broken consumers: other stacks still reference the old backend location.
• State drift: the infrastructure changed outside Terraform before or during the move.

Review downstream consumers

If other Terraform projects consume outputs from this state, update them after the move. A common pattern is a terraform_remote_state data source that still points at the old account or bucket.

data "terraform_remote_state" "example" {
  backend = "s3"

  config = {
    bucket = var.state_bucket
    key    = var.state_key
    region = var.region
  }
}

Where possible, consider reducing cross-stack coupling by publishing selected outputs through a parameter store or another explicit interface rather than depending on broad remote-state reads.

Related Terraform guides

• Terraform State Explained: Remote State, Locking, Backends and Best Practices
• What Is a Terraform State File (tfstate)?
• AWS Vault to AWS Console
• Terraform Plan -out: Saving, Reviewing, and Applying Execution Plans

This page should rank for the AWS migration workflow. Keep your broader Terraform state questions anchored on the main hub page above.