Terraform moved block behavior when renaming a resource and changing its arguments

The Short Answer

No, not every argument change forces a replacement. A moved block only handles the address of the resource in the state file; it does not protect the resource from the standard lifecycle rules of the provider. If you change an argument that is marked as ForceNew (immutable) in the provider schema, Terraform will trigger a destroy‑and‑recreate cycle, regardless of the moved block.

How Terraform Processes Combined Changes

When you combine a moved block with argument updates, Terraform processes the logic in two distinct stages:

1. State Migration: Terraform reads the moved block and updates the resource’s address in the state file from the source to the destination.
2. Diff Evaluation: Terraform compares the current state (now at the new address) against the new configuration. It then determines if the argument changes require an update in‑place or a replacement based on the provider’s schema.

Identifying ID‑Influencing (ForceNew) Arguments

Terraform does not have a universal list of "ID‑influencing" arguments because these are defined by the individual provider (AWS, Azure, GCP, etc.). To determine if an argument will trigger a replacement, you can use these methods:

• The Plan Output: Run terraform plan. If the output shows +/- or -/+ (replacement), the change is immutable. If it shows ~ (update in‑place), it is safe.
• Provider Documentation: Look for notes stating "Forces new resource" next to the argument description in the official provider documentation.

Safe Implementation Steps

To ensure zero downtime when renaming a resource and updating its arguments, follow this scoped workflow:

# 1. Implement the moved block and the argument change in your code
# 2. Run a plan to verify the action
terraform plan

Verification Logic:

Plan Result	Meaning	Action
~ update in-place	Argument is mutable.	Safe to apply.
+/- replacement	Argument is ForceNew.	Stop. Split the move and the update into separate PRs or find an alternative.

One diagnostic detail needed: Which specific provider and resource type are you using? This allows for verification of the specific argument’s immutability in the provider schema.