Terraform to OpenTofu & Terragrunt migration

Every migration ends with someone hoping.

A senior engineer reads the plan, says it looks fine, and everyone moves on. That review misses things a person cannot reasonably catch.

A clean plan can still be wrong

A plan showing nothing but no-ops still hides a resource somebody added out-of-band last Tuesday.

Old drift becomes your fault

Drift that was already there gets blamed on the migration, or worse, silently absorbed into it.

The engine changes underneath

Terragrunt silently prefers OpenTofu when both are installed. You are running a different binary than anyone believes.

And when something breaks six weeks later, there is nothing to point at. That is the gap this closes: not a tidier repo, but evidence that survives the argument.

A Migration Certificate.

One page. It records, for every root:

the state's SHA-256 before and after, at full 64 characters
which of four mechanical checks passed
the drift that was already there before we arrived, signed and dated
the exact commands to re-derive all of it yourself

You do not have to trust us. Your auditor runs shasum -a 256 and gets the same number, or does not.

The four checks

Read from structured plan data: never from plan text, never from exit codes.

C1	every planned action is a no-op
C2	the resource address set is identical
C3	the engine version matches your pin
C4	every resource is bound to the same provider

These are not redundant. On a real estate, C1, C2 and C3 all passed while the providers had silently moved to a different registry with a different signing key. Only C4 saw it.

Plus eight supporting documents

Executive summaryReadiness assessmentRisk registerBackup manifestMigration planVerification reportHypercare planPackage index

The migrations we do.

Migration	What changes	State writes
Terraform → OpenTofu	the engine	none
OpenTofu state encryption	state at rest	one per phase
Terraform → Terragrunt	how the code is invoked	none
HCP Terraform exit	where state lives	one, reviewed

Two of these move no state at all, which makes the guarantee an identity check rather than a promise.

How it runs.

0
AssessmentRead-only, one hour, no cloud credentials. Estate inventory, complexity tier, risk register.
1
BaselineWe record what is already drifting, before touching anything. Signed. This is what settles the argument later.
2
MigrateNew files only. We never edit your .tf: the parser we read HCL with physically cannot write it back.
3
VerifyThe four checks. Certificate issued only on a pass.
4
CutoverYour engineers, your CI, a window you choose.
5
HypercareSeven days, with the rollback path armed and the checksummed backups intact.

The tool cannot break your infrastructure.

apply and destroy do not exist in it. Not disabled, not behind a flag: absent. The command allowlist cannot express them.

Every command issued against your estate is written to an audit log you keep. Read it: there is no mutating verb in it, because there is no way to produce one.

What we do not claim.

We never apply anything. We prove the planned change is a no-op. The first apply is always yours, in your CI. That boundary is deliberate.
The proof is about the plan. We cannot prove what happens if someone applies something else next week.
No customer has used this yet. It has been proven against live AWS, Azure and Google Cloud estates and four public repositories. That is not the same as a reference, and we will not pretend otherwise.
The largest estate it has run against is small. Ask us about scale and we will tell you exactly what has been measured.

A migration service that lists only what it can do is selling something else.

Start with the assessment.

Read-only. No cloud credentials. No state access. One hour. You get the estate inventory, the complexity tier that determines the price of everything after it, and a risk register derived from your actual configuration, usually including things you did not know about your own estate.

Fixed price. Yours to keep whether or not you proceed.

Book a 20-minute scoping call

This is consulting work, not software; it is a separate engagement from Cloudkeel-DD, which you can install yourself without talking to anyone. We are pre-launch: no customers yet, and no SOC 2.