Terraform terraform_data vs null_resource in 2026

If you are still reaching for null_resource every time Terraform needs a lifecycle container for a command, you are carrying an older habit into a newer Terraform world. HashiCorp introduced the built-in terraform_data resource in Terraform 1.4, and by 2026 it is the better default for most of the jobs people used to give to null_resource.

That does not mean null_resource is useless. It means the burden of proof flipped.

The clean comparison

That first row matters more than it seems. terraform_data comes from Terraform’s built-in provider at terraform.io/builtin/terraform. No provider setup. No extra dependency just to model lifecycle behavior.

What terraform_data is really for

HashiCorp describes terraform_data as a resource that implements the standard resource lifecycle without directly taking any other actions. That sounds abstract, but in practice it covers two common needs:

1. store values that should follow resource lifecycle semantics
2. trigger replacement or provisioner execution when plain values change

This is the point many teams miss. terraform_data is not just a prettier null_resource. It is the cleaner built-in object for “Terraform needs this value or action to behave like a resource even though it is not cloud infrastructure.”

Why null_resource stuck around for so long

Because it solved a real problem.

For years, null_resource was the escape hatch for awkward tasks:

• bootstrap script runs
• local configuration generation
• one-off CLI integration
• dependency bridging between Terraform-managed resources and external commands

That is why the old Terraform Null Resource guide still gets traffic. Plenty of real configurations grew around it.

But 2026 is not 2022. If you are starting fresh on Terraform 1.4 or later, using null_resource by default is usually a sign that the configuration has not caught up with the language.

The migration pattern

The straightforward migration is:

For example, if you were using null_resource to rerun a local command whenever specific upstream resource IDs changed, terraform_data is now the cleaner container for that logic.

The important caution is this: migration is not only a syntax swap. It is also a chance to ask whether the provisioner should exist at all.

Provisioners are still the bigger smell

This is where teams get distracted by the wrong comparison.

The real hierarchy looks like this:

1. best: avoid provisioners entirely
2. acceptable: if you truly need one, prefer terraform_data
3. fallback: keep null_resource only when older compatibility or existing module contracts force it

A configuration that relies heavily on provisioners is still fragile whether the wrapper is null_resource or terraform_data. The modern resource just gives you a cleaner wrapper. It does not make imperative steps suddenly elegant.

When I would still keep null_resource

There are a few legitimate cases:

• the module must support older Terraform versions
• changing the resource type would cause more churn than value right now
• the configuration already works and the team has more important refactors queued

That is fine. Not every upgrade needs to be ideological.

But if you are publishing new internal templates, teaching Terraform patterns to newer engineers, or updating platform modules, use terraform_data as the baseline. That is the part that matters long-term.

How this fits with the rest of your Terraform stack

This article is easiest to understand as part of a broader cleanup:

• older “how Terraform worked” habits from articles like Terraform Data
• newer language and testing practices from Terraform Testing in 2026
• multi-environment structure from Terraform Stacks
• ecosystem tradeoffs in Terraform vs OpenTofu 2026

If your team is modernizing modules anyway, this is a low-drama improvement to make along the way.

My recommendation

Use terraform_data by default in Terraform 1.4+ whenever you need a lifecycle-aware helper resource. Keep null_resource only when backward compatibility or existing module contracts make it the pragmatic choice.

That is the right 2026 rule. Not because null_resource is broken, but because Terraform finally gave you a cleaner built-in answer.