Converging Imported Configuration

Scenario: Immediately after import, the plan proposes changing ten attributes that were omitted and filled by provider defaults.

After binding identity, run a plan and classify every difference: required desired change, provider default to represent explicitly, computed read-only value, or field intentionally managed elsewhere. Iterate until the plan matches adoption intent—often no change for the first apply. Do not blindly copy every state attribute into HCL; state includes computed and legacy details that are not valid configuration.

Analogy: Adoption is interviewing a long-running employee and writing an accurate job description before changing their responsibilities.

A worked configuration

terraform plan
terraform state show fakecloud_server.legacy
# edit configuration, plan again, repeat until understood

Freeze manual changes during convergence and peer-review the final plan with the service owner. The safest first Terraform action on a critical imported object is frequently an empty apply.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

Goal: Reinforce this lesson in the tf-import-existing-resource Terraform lab. Open /labs/terraform and choose slug tf-import-existing-resource; the lab runs real Terraform against the offline FakeCloud provider.