⬆️ Using AI to Survive a Terraform Provider Major Version Bump

Bumping the AWS provider from v4 to v5 is the kind of chore I put off for months. You change one line in required_providers, run terraform plan, and suddenly there are 200 lines of unexpected changes, three deprecated arguments, and a resource that got split into two. The upgrade itself is five minutes; understanding the fallout is two days.

That two days is where AI helps. A major version bump is fundamentally a reading problem — cross-referencing a long changelog against your actual configuration — and reading is what models do well. Use it as a fast junior engineer who can read the entire upgrade guide in one breath, then have it tell you which parts touch your code. It never runs the upgrade; it just maps the minefield.

The upgrade that ambushes you

You start optimistic:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"   # was ~> 4.0
    }
  }
}

terraform init -upgrade
terraform plan

Then the plan shows your S3 bucket scheduled for changes you never made, because v5 moved bucket configuration into separate resources. Without context, you don’t know if that’s safe or catastrophic. The changelog explains it — but the changelog is 40 screens long and 90% irrelevant to you.

Step one: let AI filter the changelog to your surface area

Get your actual resource types:

terraform state list | sed 's/\..*//' | sort -u

That gives you the set of resource types you actually use. Paste that list plus the provider’s upgrade guide (or the relevant CHANGELOG sections) and ask:

Here are the resource types I use and the provider upgrade guide. List only the breaking changes and deprecations that affect resources I actually use. For each, give the resource, what changed, and whether it forces replacement or is in-place.

Now the 40-screen guide collapses to the 6 items that matter to you. That filtering is the single biggest time-saver, and it’s low-risk: the worst case is the AI misses one, which terraform plan will then catch anyway.

Step two: separate cosmetic from destructive

The scary part of an upgrade plan is telling apart “the provider re-organized state, no real change” from “this will replace your database.” Generate the plan as JSON and let the AI triage it:

terraform plan -out=tfplan
terraform show -json tfplan > plan.json

jq '[.resource_changes[]
     | select(.change.actions | contains(["delete"]))
     | {address, actions: .change.actions}]' plan.json

That jq pulls only the changes involving a delete. Hand that to the AI:

These are the resources my provider upgrade wants to delete or replace. Which of these are real destructive changes versus the provider migrating internal representation? For the real ones, what’s the safe handling?

The model’s strength here is pattern-matching the upgrade guide against the specific addresses. It’ll tell you “the bucket resources splitting is internal — add the new sub-resources and they’ll adopt existing config” versus “this replacement is real, you need a create_before_destroy.”

Pro Tip: Pin to an exact patch version during the upgrade (version = "5.31.0", not ~> 5.0) so the plan can’t shift under you mid-migration. Loosen the constraint back to ~> 5.0 only after the dust settles and the lock file is committed.

Step three: have it rewrite deprecated syntax

Once you know what changed, the mechanical rewrites are perfect AI work. The classic v4-to-v5 S3 example:

# v4 style (deprecated inline)
resource "aws_s3_bucket" "this" {
  bucket = "my-bucket"
  versioning { enabled = true }
}

# v5 style (separate resource)
resource "aws_s3_bucket" "this" {
  bucket = "my-bucket"
}

resource "aws_s3_bucket_versioning" "this" {
  bucket = aws_s3_bucket.this.id
  versioning_configuration {
    status = "Enabled"
  }
}

Ask: “Rewrite these blocks to v5 syntax, and tell me whether each needs a moved/import to avoid recreation.” Then — always — terraform plan to confirm 0 to destroy. The model’s rewrite is a draft; the plan is the verdict.

Step four: don’t skip the lock file

After everything plans clean, the upgrade isn’t done until the dependency lock file is updated and committed for every platform your team and CI use:

terraform providers lock \
  -platform=linux_amd64 \
  -platform=darwin_arm64

A junior engineer forgets this and CI breaks on a different architecture. Ask the AI to remind you which platforms to lock for, but run the command yourself — it touches .terraform.lock.hcl, which is real repo state.

The boundary, as always

The AI reads changelogs, triages plans, and drafts rewrites. It does not run init -upgrade against prod, does not hold cloud credentials, and does not run apply. Every change it proposes is HCL you review and a plan you inspect. A provider upgrade is high-stakes precisely because the blast radius is your whole estate — which is exactly why the model stays on the reading-and-drafting side of the wall and a human owns the execution.

For curated upgrade prompts, see the prompts library and prompt packs. Run the rewritten config through the code review dashboard before merge, and find related guides under AI for Terraform.

Conclusion

A major provider bump is a reading problem wearing an outage costume. Let the AI collapse the changelog to your actual surface area, triage the JSON plan into cosmetic-versus-destructive, and draft the deprecated-syntax rewrites — then confirm everything with terraform plan showing 0 to destroy and lock the providers yourself. The model is the fast junior who reads everything; you’re the senior who runs the upgrade.