Terraform state removal: hand off an object without deleting it

Last updated: 5 Oct 20266 min read

tutorial

Deleting a Terraform resource block usually plans to destroy the remote object still recorded in state. If another team or tool must take ownership while the object remains, the exit needs an explicit state-removal action. A removed block with destroy set to false expresses that intent in configuration. It does not transfer policy, credentials, monitoring, or backup responsibility by itself; the receiving owner must be ready before the old state stops managing the object.

Operational decision

A central platform team takes over an archive bucket used by a receipt service. Before removing the old resource block, record the bucket identifier, region, policies, retention, backup, alerts, and the new team's state address or management system. Freeze edits during the handoff. Replace the old resource declaration with the reviewed removed block below, plan and confirm it says the object will be forgotten without remote deletion, then apply under the state lock. The receiving owner adopts the object, runs a no-op plan or equivalent inventory check, and verifies that old automation no longer writes it. Keep the handoff record and a safe recovery path in case neither manager sees the object. Do not run both writers while they each believe they are authoritative. Test the procedure on a disposable bucket, including a failed receiving import, before scheduling a production handoff.

removed {
  from = aws_s3_bucket.receipt_archive

  lifecycle {
    destroy = false
  }
}

Cost and verification

Removing an address reduces the old state's scope but creates a short period in which the object may have no active configuration owner. Coordinated freeze time and duplicate inventory checks cost more than a direct delete, but they prevent accidental data loss. State snapshots can still contain historical attributes after removal, so retention and access policy remain relevant. Measure orphaned objects, overlapping writers, and time between old-owner release and new-owner adoption. If the plan contains destruction, stop and correct it before apply.

Common Mistakes

Do not delete the resource block and assume the remote object will remain.
Do not release the old owner before the receiver can adopt the object.
Do not forget historical state copies when transferring sensitive infrastructure.

Connected lessons

Practice and check

devops

operations