Terraform and OpenTofu Support for Platform Teams

1. 01

   The engineer who wrote the modules has left, and a plan that used to be quiet now proposes changes nobody can explain

2. 02

   A module refactor renamed resource addresses, and the plan shows a database and its volume being destroyed and created again

3. 03

   Providers float on loose version constraints, so the plan CI runs differs from the one a laptop ran last week

4. 04

   The whole platform sits in one state file, a plan takes minutes, and a crashed pipeline leaves the lock held

5. 05

   Nobody has decided whether the estate stays on Terraform after the BSL change and the IBM acquisition or tries OpenTofu, and the question returns every quarter

6. 06

   A resize of a broker or database node is about to replace the node, and the lifecycle rules that should prevent it were never written

7. 07

   Cluster settings for RabbitMQ, Kafka or PostgreSQL live in Terraform in one repository, Ansible in another and a wiki page in a third

Plan after a module refactor

One refactor, one apply, three resources

Illustrative

Module refactor

plan and apply

database node

data volume

load balancer

1. 01Stable

   Addresses match the state. The plan reports no changes, and the database node, its volume and the load balancer are all tracked where the code says they are.

2. 02Plan wants to replace

   The module is renamed. By default Terraform reads a changed address as a destroy and a create, so the plan lists the database node and its volume for replacement. The load balancer is untouched. Applying would delete a database.

3. 03Moved and verified

   Moved blocks tell Terraform the objects now live at new addresses. The plan shows resources moved and nothing destroyed, a prevent_destroy rule guards the database as a second check, and the apply goes ahead. Is this happening on your Terraform? Get a quote

Terraform stores each object under an address in state, and a rename changes the address, not the infrastructure. A moved block maps the old address to the new one so the existing object is renamed in state rather than replaced. HashiCorp documents moved blocks from Terraform 1.1 for module refactoring, and advises keeping historical moved blocks in modules other people use. The review before apply is what catches this: a plan that lists a database for replacement is read by a person, a prevent_destroy lifecycle rule makes Terraform refuse any plan that would destroy the resource, and the pipeline does not auto-approve changes to anything holding data. Provider upgrades have the same shape. A provider major version can change a default, and only a plan run on a copy shows it.

• 01

  Terraform Estate Health Check

  The fixed-scope entry engagement: a written inventory of what is deployed by Terraform or OpenTofu, in what versions, from where, with ranked findings your team can act on with or without AceMQ.

  • Root modules, state backends, providers and versions
  • Loose constraints and uncommitted lock files
  • Modules with no owner and resources outside state
  • Pipelines that apply without a reviewed plan
• 02

  Version and Provider Upgrades

  Upgrades across Terraform 1.x minors and provider major versions, planned from HashiCorp's per-minor upgrade guides and rehearsed with plan-only runs before anything is applied.

  • Upgrade path read against each minor's upgrade guide
  • Provider constraints and lock file brought under control
  • Plan-only rehearsal on non-production stacks first
  • Breaking changes listed per provider before the change
• 03

  State Splits and Moves

  Splitting a monolithic state, renaming and moving resources without replacing them, and moving state between backends, including to or from HCP Terraform.

  • Moved blocks and state moves for renames and module refactors
  • A split plan that keeps dependencies between stacks explicit
  • Backend migration with a backup and a verification plan
  • Lock handling for crashed or parallel runs
• 04

  Terraform or OpenTofu Decision

  A written comparison of staying on Terraform, trialling OpenTofu and using HCP Terraform, built from your configurations and the public facts. AceMQ gives no license advice, so the license question stays with your counsel.

  • Your configurations run through OpenTofu in a scratch copy
  • Provider, backend and pipeline differences recorded
  • Revert path written before the trial starts
  • Recommendation with the evidence behind it
• 05

  Infrastructure as Code for Data Platforms

  Module layout and review rules for the infrastructure under RabbitMQ, Kafka, Redis and PostgreSQL clusters, with cluster settings documented as code rather than as a wiki page.

  • Where Terraform stops and Ansible or Helm starts
  • Lifecycle rules that protect brokers, volumes and databases
  • Resize and upgrade changes reviewed before apply
  • Hand-off runbook for the platform on-call
• 15 MIN SLA

  24/7 Terraform Support

  Senior engineers on your account, a 15-minute emergency response, no ticket routing and no junior triage.

  • 15-minute emergency response SLA
  • Senior engineers, no first-line triage layer
  • Proactive CVE & health monitoring
  • Quarterly deployment reviews

  Compare the four Terraform support tiers

• Read-only review before any change
• No apply without a reviewed plan
• Your engineers in the room
• Ad hoc engagements or an annual contract

AceMQ gives no license advice: read the license and ask your counsel. For the dates, the facts and a way to decide, read Terraform license, OpenTofu and the platform team decision.