Terraform "Cannot import non-existent ... already managed" State Mismatch

By Kaveh Alemi·Latchkey

Terraform’s state and your configuration disagree about which resource address maps to which real object. An import collides with an existing entry, or a moved/renamed resource leaves state pointing at the wrong address.

What this error means

An import fails because the resource is "already managed by Terraform", or a plan shows a destroy-and-recreate for a resource you only renamed. State records an address that no longer matches the config.

terraform output

Error: Resource already managed by Terraform

Terraform is already managing a remote object for aws_s3_bucket.logs. To import
to this address you must first remove the existing object from the state.

Common causes

Importing an address already in state

Trying to import a resource that Terraform already tracks at that address collides with the existing state entry.

Resource renamed without moving state

Renaming a resource in config without terraform state mv makes state still reference the old address, so Terraform plans to destroy and recreate.

How to fix it

Move state for renamed resources

Use state mv (or a moved block) so a rename does not become a destroy/recreate.

main.tf

terraform state mv aws_s3_bucket.logs aws_s3_bucket.audit_logs
# or, declaratively:
moved {
  from = aws_s3_bucket.logs
  to   = aws_s3_bucket.audit_logs
}

Reconcile import collisions

If an import says the address is already managed, the resource is already in state - do not import.
Run terraform state list and terraform state show <addr> to see what is tracked.
Only terraform state rm an entry when you intend to detach it from management, and understand the consequence.

How to prevent it

Use moved blocks or state mv for renames instead of editing addresses directly.
Inspect terraform state list before importing.
Keep one shared state so addresses do not diverge across pipelines.

Frequently asked questions

What causes "state/resource mismatch"?