Files
magnus919_agent-skills/terraform/references/06-upgrades-and-refactors.md
T
Magnus HedemarkGitHubfactory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
00abbf90a4 feat(skill): add Terraform operational skill (#263)
* feat(skill): add Terraform operational skill

Add a single tool skill for Terraform and OpenTofu operations: module
structure, state backends and locking, plan/apply workflow, drift detection,
remote state, upgrade and refactor flows, and evidence-based diagnostics.
Ships the agent-first tfops wrapper (JSON output, direct state-file analysis,
--dry-run/--yes/--force mutation gate), a fixture-tested suite, six eval
cases, dated references, and routing up to platform-engineering. Closes #243.

Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>

* fix(skill): clarify missing-binary report in tfops doctor

When the TERRAFORM env override names a binary that cannot be found,
doctor now reports the env value with a (not found) marker instead of
falling back to the generic default name.

Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>

---------

Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
2026-08-03 17:38:46 -04:00

2.9 KiB

Upgrades and refactors

Upgrades change the tool/provider contract; refactors change the module structure. Do them one at a time, in a controlled order, with a plan review between every step.

Version upgrades

  1. Read the upgrade guides for the whole span — each minor version from current to target (Terraform upgrade guides; OpenTofu publishes its own). Collect deprecations, default changes, and behavior changes.
  2. Validate in place first: terraform validate / tofu validate and a plan show whether the current config is compatible with the current binary before you change anything.
  3. Stage: upgrade the tool in a non-production environment (or a clone workspace), run plan, apply, and verify before touching production.
  4. Provider migrations within an upgrade: terraform state replace-provider handles provider source/version moves (e.g., moving to a namespaced provider); run it with the state backed up and a lock held.
  5. Rollback: the tool binary can be downgraded within supported bounds, and the state file is version-agnostic at the format level — keep the previous binary available until the new version has applied cleanly.

Refactors (renames and restructures)

  • Prefer moved blocks: they make the plan show pure renames (no destroy/create), keep the state change explicit, and are reviewable in the diff. This is the default for renaming resources or modules.
  • Fall back to reviewed terraform state mv only when moved does not fit (e.g., migrating between backends/workspaces); each state mv is a state mutation and needs a backup and a held lock.
  • Never delete state entries to force recreation of a resource that exists; that loses the resource's data and identity.
  • Sequence: upgrade first, then refactor — two change classes compounding is the classic trap (a failed refactor is then blamed on the upgrade and vice versa).

Verification

  • After each step: terraform validate, a clean plan (renames show as renames, not replaces), apply in staging, and a drift-free re-plan.
  • tfops plan --state FILE --json gives a quick state-level sanity check (serial, lineage, resource inventory) before and after refactors.

Sources

Last Updated: 2026-08-03