Either nothing is written down, or what is written down is unusable
The page serves both, and they are not the same engagement.
Clicked together
Infrastructure exists and works. It was built in consoles over three years, mostly by people who have left. Nothing is reproducible, and the first person to suggest putting it in Terraform is now looking at a job nobody can size.
Terraform nobody trusts
IaC was adopted. There are now four thousand lines in one root module, a plan takes eleven minutes and proposes changes nobody ordered, and the state file frightens people. This reader needs the adoption fixed, not explained.
Six things, and most estates have four of them
If the account were lost, the honest recovery plan is several people rebuilding from memory over a fortnight.
Rebuilt from memoryStaging and production diverged gradually, through fixes applied to one and not the other.
Quietly divergedSomebody fixed an incident in the console at 2am and never went back, so every plan since contains changes nobody ordered.
Plan output untrustedA routine change takes a week, because it needs the one person who understands the codebase.
One personSomeone asked who changed the security group and when, and the answer was a log search and a guess.
A log search and a guessNobody sees what a change costs until the bill arrives.
Priced by the invoiceDrift is worth singling out, because it compounds. Once plan output stops being trustworthy, people stop reading it, so more fixes happen in the console, so the output gets noisier still.
Four engagements, and most estates need the second one
Assess and plan
A review of the estate, any code that already exists, the state, the pipeline, and how changes actually get made today. You get a written picture of the current state and a roadmap in priority order — what is dangerous, what is expensive, what can wait, and what order the work goes in. It is a real deliverable, and you can act on it without buying the build.
Bring an existing estate under code
The engagement most clients actually need. Existing resources are imported into state rather than recreated, drift is reconciled, and the clicked-together parts are converted progressively. Nothing is destroyed and rebuilt for the sake of tidiness, and nothing is destroyed at all without you agreeing to it explicitly.
Make an existing codebase maintainable
A monolithic root module restructured into modules with real interfaces, environments separated properly, state split so a plan is fast and its blast radius is small, Terragrunt introduced only where the estate justifies it, and the things that make code reviewable — tflint, terraform validate, checkov or tfsec, formatting and pre-commit hooks, and plan-time cost estimation so a change’s price shows up in the pull request rather than on the bill.
Build it
Greenfield, or a new component: module structure, environment separation, remote state with locking, a naming and tagging standard finance can use later, secrets handling that keeps credentials out of the repository, provider version pinning, and the plan and apply pipeline that runs it.
One default, with a reason
Terraform
The defaultThe default for everything, across AWS, Azure and Google Cloud.
Terragrunt
ConditionalWhere the estate justifies it — many accounts, many environments, repeated root configuration. Not by default, because it is another tool your team has to learn and it only earns that at a certain size.
Bicep
Azure-nativeFor Azure-native work where your team is already using it.
Ansible
A different layerFor configuration management, which is a different layer: Terraform provisions the infrastructure, Ansible configures what runs on it. They are not competing choices.
In your account, through your CI
State stays with you
S3 with DynamoDB locking, Azure Storage, or GCS. Encrypted, versioned, and access-controlled by your own IAM.
Runs go through your CI
Plan on pull request, so a change is reviewable as a diff. Apply on merge.
No third-party run platform
Nothing extra to buy, nothing extra to be locked into, and nothing to unpick if you stop working with us. Where you already run one, we work with it — we just do not introduce one.
Assess first, even when you have already decided
Always first, even when you have already decided what you want, because an estate is rarely what anyone remembers it being.
The agreed work, in your own repositories, in reviewable increments. Nothing recreated without explicit agreement.
Documentation, the conventions written down, and your engineers able to add a module without us.
Then we are done — this is scoped work rather than an ongoing dependency.
A module library will beat us to the first apply
A vendor with a pre-built module library will reach a first working apply faster than we will. That is true, and worth knowing before you choose. What you own afterwards is a library you cannot maintain without that vendor, on their upgrade schedule.
We compose from well-maintained public registry modules where they genuinely fit, write what is specific to you, and leave a codebase your own engineers can read. The test we hold ourselves to is whether one of them can add a module three months after we leave without calling us.
Your own team does it
They can — this is not specialist knowledge in the way a Kubernetes upgrade is. It has been on the roadmap for four quarters and lost every one to product work, because nothing breaks today if it slips again.
A vendor with a module library
Faster to a first apply, as above. Worth asking what happens to your infrastructure when you stop paying them, and whether you can read the modules you are running.
A generalist contractor
Will produce Terraform that works. Whether anyone else can extend it depends on who turned up, and that failure mode stays invisible for about six months.
Leaving it
Free until an incident, an audit or a region migration, at which point the cost arrives all at once.
Not every estate needs this yet
A small estate that genuinely never changes does not need this engagement, and we would rather say so now.
Tick the ones that are true
Four questions. Your answers stay in your browser.
The questions that come up first, answered plainly
Can you bring our existing infrastructure under Terraform without rebuilding it?
Yes — imported into state rather than recreated, drift reconciled, and converted progressively. Nothing is destroyed and re-created without your explicit agreement. This is the fear that stops most people starting, so it is worth answering plainly.
How do you handle drift?
Scheduled plan runs that report differences before they compound, alerting when reality and code separate, and — the part that actually fixes it — making the code path fast enough that engineers stop reaching for the console mid-incident. Drift is a symptom of the pipeline being slower than the emergency, and tooling alone does not solve it.
Which tools do you use, and why not Pulumi?
Terraform, and Terragrunt where the estate justifies it. Pulumi is a reasonable tool; it is not ours. One default the whole team is deep in, that engineers you hire later will already know, and with the ecosystem your next contractor will expect.
Do we need Terragrunt?
Often no. It solves repetition across many accounts and environments, and below that scale it is one more thing for your team to learn. We will tell you when we think it is not worth it.
What about OpenTofu?
We deliver Terraform, and we do not offer OpenTofu as a delivery option. If you are already on it we will say what we would advise in your situation rather than pretend the question does not come up.
Will our team be able to maintain this?
Conventions written down, modules with real interfaces, no proprietary library — and handover measured by whether your engineer can add a module without calling us.
Do you use your own module library?
No. A library is faster to start with and slower to own, and we would rather leave you something you can read.
Will you be in our cloud accounts?
Your accounts, your state, your CI. Scoped access, and it ends when the engagement does.
Talk to an engineer
Not a salesperson. You will get a read on the estate, what bringing it under code would actually involve, and in what order.
- A written picture of what exists — the estate, any code, the state, the pipeline
- A roadmap in priority order: dangerous, expensive, and can wait
- What would be imported rather than rebuilt, and what that would take
- Everything delivered into your own repositories and cloud accounts