# Bring existing resources under code without recreating them

Adopting an unmanaged resource requires a matching definition and a reviewed plan. Registration alone does not prove that the next apply will preserve it.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Inventory the live resource and its dependencies

Record identifiers, configuration, data ownership and connections to other resources. Identify which team currently changes it and whether another controller owns any fields.

For a stateful resource, confirm backup and recovery appropriate to the planned work. Adoption should not begin with an assumption that replacement is harmless.

Keep sensitive configuration out of broadly shared inventory files.

## Write a definition that matches the intended state

Decide which live settings should be retained and which require a separate change. Avoid mixing initial adoption with a large redesign when that makes the plan hard to assess.

Use the tool's supported import or adoption mechanism for the resource type. Understand what it records and what configuration still needs to be written.

A resource appearing in managed state is not the same as a complete definition that reproduces its intended settings.

## Inspect the first normal plan carefully

Review every proposed update, replacement and deletion. Resolve unexpected differences before applying.

Provider defaults, omitted fields and naming choices can produce changes even when the definition looks equivalent to a human reviewer. Use the actual plan and service documentation as evidence.

For an illustrative database adoption, an unexpected replacement proposal is a stop condition for investigation, not a routine part of making the resource managed.

## Transfer operational ownership

Once the managed definition and live resource agree, move normal changes through the reviewed workflow. Restrict or document remaining external writers so they do not immediately recreate drift.

Update support procedures, ownership records and state access. The previous team may still have scripts that alter the resource directly.

Verify a small intended change through the new path and confirm service behaviour. Adoption is complete when the resource can be maintained safely under code, not simply when the import command returns success.

## Sources

- [HashiCorp: resource import](https://developer.hashicorp.com/terraform/language/import)