Suppose you rename a Terraform resource or move it into a child module. Its configuration now has a new address, but its existing state still uses the old one. Without a migration, Terraform can plan to destroy the old resource and create a replacement. A `moved` block tells Terraform to associate that existing resource with its new address instead. section 6.5.2
Listing 6.15 moved and removed blocks and resources
resource "random_password" "main" { #1
length = 12
}
moved { #2
from = random_password.my_password #3
to = random_password.main #4
}
removed {
from = aws_s3_bucket.bucket #5
lifecycle { #6
destroy = false #7
}
}
For a rename, set `from` to the address already in state and `to` to the address of the renamed resource in the configuration. The listing moves `random_password.my_password` to `random_password.main`. section 6.5.2
Listing 6.16 moved block and modules
module "password" { #1
source = "./modules/password"
}
moved { #2
from = random_password.my_password #3
to = module.password.random_password.main #4
}
The destination can also be inside a child module. Here, the existing password resource moves from the root module to `module.password.random_password.main`. section 6.5.2
Terraform processes a move only while the `from` address exists in state. After migration, the block does nothing; in a new environment with no old resource, Terraform can create the configured destination normally. Keep moved blocks in shared modules so users upgrading from older versions can still migrate without an unexpected replacement. Unlike an `import` block, a moved block relocates an address within one Terraform project rather than bringing an external resource under management. section 6.5.2 section 9.5.4 section 2.9
