How do organisations decide whether to import existing cache resources or recreate them under Terraform?

When a Cache Already Exists, What “Under Terraform” Really Means

For infrastructure teams, the import-versus-recreate decision is not really about Terraform mechanics alone. It is about whether an existing cache can be placed into a predictable, reviewable lifecycle without disturbing production traffic. Import is the safer choice when the live object already carries business value and the main problem is lack of management discipline. Recreate is only justified when the current cache is too inconsistent, too opaque, or too risky to keep.

That distinction matters because cache layers often sit in the path of latency-sensitive workloads, session data, or temporary application state. If a team recreates casually, it can trigger avoidable outages, data loss, or a sharp performance regression. If a team imports without first checking what is actually configured, it can preserve hidden drift and make the automation model look safer than it is. Guidance on infrastructure control and change discipline is well covered in NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, many teams only discover the real cache dependency after a refresh, failover, or state reconciliation exposes it.

How Organisations Decide Between Import and Rebuild

The practical question is whether the current cache is already serving a workload that should not be disturbed. If the answer is yes, import usually gives the better control outcome because the team can attach the resource to Terraform state, define the intended configuration, and begin measuring drift without replacing the live service. That is especially useful when the cache has stable endpoints, established connection patterns, or surrounding applications that assume continuity.

Recreate becomes the better option when the cache is effectively unrecoverable from a governance standpoint. Common examples include inconsistent manual changes, undocumented parameters, unsupported settings, or a deployment pattern so ad hoc that the team cannot confidently predict the result of importing it. In those cases, importing may preserve bad configuration and leave operators managing technical debt through code instead of eliminating it.

• Import when the resource is production-live, business-critical, and worth preserving as-is.
• Recreate when the existing cache cannot be described cleanly or is too far from the desired standard.
• Prefer import when replacement would disrupt sessions, warm data, or application performance.
• Prefer recreate when the team needs a clean, repeatable baseline more than continuity.

The decision also depends on whether the surrounding application can tolerate a cold cache. Some systems recover quickly after recreation because the data is fully rebuildable, while others suffer noticeable latency spikes or operational instability until the cache warms again. That is where cache architecture, not Terraform preference, should drive the choice. Where the cache is tightly coupled to customer experience or peak-load behaviour, import is usually the conservative path; where it is disposable and easy to rehydrate, recreate can be cleaner. The guidance breaks down when teams assume every cache is disposable, because not all caches are functionally interchangeable.

Edge Cases That Change the Decision

Tighter infrastructure control often increases change-management overhead, so organisations have to balance speed of remediation against the cost of preserving technical debt. That tradeoff becomes sharper when the cache is managed by another platform team, created by an autoscaling workflow, or partially controlled outside the Terraform module.

One common edge case is a cache that exists, but only some settings are safe to manage declaratively. In that situation, importing the resource may be appropriate while leaving certain operational attributes to the platform’s native lifecycle. Another edge case is a cache that must be replaced for architectural reasons, such as a major version change, a broken topology, or a configuration that cannot be reproduced safely. The judgement here is not about whether Terraform can describe it, but whether the existing object is still worth preserving.

There is also a governance distinction between “can import” and “should import.” Teams sometimes import an object simply to avoid doing the harder analysis. That creates a false sense of control if the cache still depends on manual intervention, undocumented overrides, or outside-of-band changes. The more critical the cache, the more important it is to verify that state, ownership, and rollback expectations are actually aligned before either path is chosen.

Risk and Threat Considerations

Cache resources introduce operational and governance risk because they often support performance, availability, and transient data handling at the same time. A poor import decision can lock unmanaged drift into the infrastructure model, while an unnecessary rebuild can create avoidable downtime, cache-warmup degradation, or loss of temporary state that other services quietly depend on.

Failure mechanism: The risk materialises when teams treat the cache as a simple disposable component and miss hidden dependencies such as session affinity, warm data, rate-limiting behaviour, or application assumptions about continuity. Import without reconciliation can preserve unknown settings; recreate without impact analysis can break workloads that rely on the existing instance’s identity, locality, or contents.

Impact: The result can be service interruption, degraded application performance, inconsistent behaviour across environments, or a management model that looks controlled while still containing unmanaged configuration risk.

Practitioner Guidance

What to prioritise: Decide first whether the cache is operationally disposable. If application behaviour, warm state, or continuity matters, treat import as the default unless there is a clear governance reason to replace the resource.

What to verify: Confirm the resource’s actual dependencies, ownership, and configuration drift before trusting either option. A cache that appears simple in documentation may still carry application-specific assumptions that make recreation riskier than it looks.

Decision rule: If the existing cache is stable enough to preserve and the team can bring it under repeatable control, import it. If the object is too inconsistent to govern confidently, recreate it only after validating that the workload can tolerate reset and rehydration.

Practitioner takeaway: The best choice is usually the one that reduces uncertainty without creating unnecessary disruption, and in cache management that often means preserving a live, working dependency until the team has proved it can be replaced safely.

Related resources from NHI Mgmt Group

• How do organisations decide whether to import existing CI/CD resources before rebuilding them?
• How should organisations decide whether existing identity controls are enough for agentic AI?
• How can organisations decide whether to automate identity workflows before replacing existing IGA tools?
• How do organisations decide whether to replace an existing IGA platform or improve it?