Terraform 1.5: Migrating from Local State to S3 Backend—Uncertain Lock Behavior

Implications for concurrent modifications without locking

When the S3 backend is configured without a DynamoDB table for state locking, Terraform 1.5 skips lock acquisition entirely. This means multiple terraform apply or terraform plan operations can write to the same state simultaneously. The backend’s eventual consistency model does not prevent last-write-wins overwrites, which can result in state corruption or lost updates. Terraform does not detect or resolve these conflicts automatically on unlocked backends.

Locking behavior during migration

The terraform init -migrate-state command transfers the existing local state into the new S3 backend configuration. It does not automatically enable or disable locking; the locking behavior is determined entirely by the backend configuration that Terraform writes to .terraform.lock.hcl and the underlying S3 bucket setup. If no DynamoDB table is referenced in the backend configuration, Terraform treats the backend as unlocked and proceeds without lock coordination. To enable locking, you must add a dynamodb_table_name block to your S3 backend configuration before or after migration, ideally before any concurrent runs.

Migration safety and recovery

While Terraform permits migration without an explicit local backup, the recommended practice is to preserve a copy of the current state file before running terraform init -migrate-state. If the migration fails midway, the local state may remain unchanged, but the backend configuration could be left in a partial state. Recovery typically involves restoring the original local state file and re-running the initialization with the -reconfigure flag, or using a prior backup to re-import state.

To proceed with a safe migration path, I need to know: does your S3 bucket already have a DynamoDB table configured for Terraform state locking?