Context
Importing a resource into Terraform state does not automatically make the surrounding configuration correct. State records an association; configuration still describes what Terraform should manage. If those two views disagree, the next plan may propose changes to a resource that was working before the import. The important decision is ownership, followed by a carefully reviewed plan.
Consider an illustrative cloud estate with a manually created load balancer. Two teams both believe they should manage it. One imports it into a new workspace while the other still has automation changing its listeners. The resulting drift is not a Terraform bug. The organization has given two controllers conflicting authority over the same resource.
Establish one management boundary
HashiCorp documents workflows for importing existing infrastructure and associates remote objects with Terraform resource addresses. Import support and identifiers depend on the provider and resource type. Importing state and writing or generating configuration are related but distinct tasks, and the result still needs review. 1
Before running an import, identify the resource owner, intended workspace, backend, module address, and competing automation. Agree which system will manage which attributes. Do not assume a resource is unmanaged simply because the current team cannot find it in its own repository.
Capture the live baseline and recovery context
Record resource identifiers, important configuration, dependencies, current provider version, and the state backend's recovery procedure. Restrict access to state because it can contain sensitive values. Keep a protected state snapshot using the backend's supported controls rather than placing raw state in a general ticket.
Confirm the working directory and workspace before any state operation. A correct resource address in the wrong workspace can create a difficult ownership conflict. Use the same review discipline as a production infrastructure change, even when the intended import does not modify the remote resource directly.
Build configuration that expresses intent
Write or review the resource configuration and related references. Distinguish values that are intentionally managed from provider-computed attributes. Include dependencies the module needs, and avoid copying every observed value into configuration without understanding its meaning.
Generated configuration can be a useful starting point, but it still needs human review for defaults, conflicts, sensitive values, and organization conventions. A syntactically valid file is not necessarily a stable configuration. Keep provider versions controlled so the plan is evaluated against known schema and behaviour.
Review the first plan as a change proposal
After import, inspect the full plan. Separate expected normalization from unexpected updates, replacement, or destruction. Investigate any change to identity, network attachment, encryption, or data lifecycle before applying. A plan is the place to discover that the configuration describes a different resource, not a hurdle to bypass.
If the target is a no-change adoption, do not apply merely because most differences look harmless. Resolve the unexplained differences or document the intended changes as a separate reviewed operation. Preserve the plan evidence without exposing sensitive values in a public artifact.
Treat drift as information about ownership
A later difference may come from a manual emergency change, another controller, a provider default, or a legitimate external process. Identify the source before deciding whether to restore configuration or adopt the live change. Terraform cannot determine the business intent from a changed field alone.
An emergency security fix may need to be incorporated into code rather than reverted. Conversely, an unauthorized manual edit may need to be removed. Record that decision explicitly. Repeatedly applying a plan without understanding why drift returns can create an endless contest between systems.
Use ignore_changes only with a named owner
Ignoring an attribute can be appropriate when another system intentionally manages it, but the ownership contract should be documented. Explain which controller is responsible, what Terraform still manages, and how the external value is monitored. An ignore rule should not become a blanket way to hide unexplained plan differences.
Review the rule after architecture changes. If the external controller is removed, the ignored attribute may become unmanaged. If a security-sensitive field is ignored, ensure the responsible control still checks it. Quiet plans are not the same as complete infrastructure governance.
Test adoption on a representative low-risk resource
Exercise the import workflow in an appropriate nonproduction context before a large batch. Verify addresses, module structure, backend access, and plan review. Include a deliberate live change so the team can demonstrate how drift is detected and resolved through the agreed ownership process.
For an illustrative migration of many similar resources, import a small sample and inspect the first plans before automating the rest. Batch automation should preserve per-resource results and stop on unexpected mapping or destructive changes. A script that reports only a final exit code can hide partial adoption.
Finish with an operating record
Document the resource-to-address mapping, owner, provider version, final reviewed plan, and any attributes delegated to another controller. Update runbooks so future emergency changes return to the same source of truth. Keep the state recovery procedure available to authorized operators.
A focused operator exercise: A one-resource adoption exercise
Choose a low-risk test resource with a known owner and import it into the intended workspace and module address. Inspect the first plan and account for every proposed difference. If no remote change is intended, the acceptance result should show that the reviewed configuration adopts the resource without unexplained updates or replacement.
Then make one authorized, reversible live change and demonstrate the team's drift decision: restore the declared value or adopt the approved new intent in code. Record the owner and reasoning. This small exercise validates resource mapping, state access, provider behaviour, and the operational process before a larger adoption script touches important production infrastructure.
Quick diagnostic map
| Evidence | Review | Acceptance boundary |
|---|---|---|
| Resource identity | Match the live object to one state address | Avoid duplicate ownership |
| Declared intent | Compare imported state with configuration | Explain every proposed change |
| Adoption plan | Review a one-resource plan before wider import | Stop before unintended replacement |
Frequently asked questions
Does import mean Terraform will recreate the resource? Import itself associates management state; later configuration and plans determine proposed changes.
Clouvenix can review existing infrastructure adoption and drift resolution, helping teams establish clear ownership before their first automated apply touches a live resource.
For a scoped review of this workflow, discuss the relevant Clouvenix engineering service.