Three years of clicks, and nothing you could rebuild
Every setting in production was correct at the moment someone made it. None of them were written down. The environment is now a sequence of decisions nobody recorded, made by people who have partly moved on, and the only copy of it is the one serving customers.
The honest inventory
Nobody sets out to build this way. It happens one urgent change at a time, and each one was reasonable.
Production was built by hand in a cloud console over years, and the team has realized it cannot be reproduced, reviewed or safely changed.
-
“We can't recreate our production environment if we had to.”
Disaster recovery, environment parity and onboarding all depend on a rebuild nobody can perform.
-
“It works in staging is our most-used phrase during incidents.”
Environments were built separately by different people at different times, so testing proves less than everyone assumes.
-
Some resources are in code, some were clicked, and nobody can say which is which.
A partially automated environment is harder to reason about than a fully manual one, because the automation will quietly revert or destroy what it does not know about.
-
Changes are made in the console during incidents and never backported.
The gap between the code and reality widens with every bad night, until the code stops being trusted at all.
-
Nobody knows who made the change, or why.
There is no review trail to explain intent, which makes every cleanup a risk assessment with missing evidence.
What the drift costs
Unreproducible infrastructure does not fail loudly. It fails as slowness, as inconsistency, and as one very bad day.
- Recovery that is theoretical
- If the environment cannot be rebuilt from a definition, recovery depends on the environment still existing. That is not a recovery plan.
- Change fear
- When nobody knows what depends on a setting, the safe move is to change nothing, so the platform ages while the product moves.
- Audit and review pain
- Console-built infrastructure has no change history that an auditor or a customer's security reviewer will accept as evidence.
- Onboarding
- New engineers learn production by exploring it, which means they learn it slowly and remember it wrongly.
- Cloud spend nobody can attribute
- Resources created by hand are tagged by hand, so cost reporting is an estimate and orphaned resources stay orphaned.
What we do about it
We do not try to reverse-engineer years of clicks into perfect code. We stand up a foundation that is entirely code, then move workloads onto it deliberately.
-
Build the definition first
A complete, code-defined foundation is deployed alongside what you run today: accounts, identity, network, logging, guardrails and pipelines, all in your own repositories.
-
Move one environment at a time
Development moves first, then staging, then production. Each one is verified in the new structure before anything is retired.
-
Close the console door
Access is granted through roles that make review the normal path, and the pipeline applies changes with a plan attached and an approval gate on production.
-
Detect drift and make it visible
Automated checks compare reality against the code and open an issue when they disagree. Nothing is silently reverted, and nothing quietly diverges either.
-
Refuse the shortcuts in review
Automated guards reject hardcoded network ranges, unpinned module versions, missing inputs and broken stack layout before a human reviewer has to notice them.
The outcome: Production becomes a definition in Git that can be planned, reviewed, rebuilt and explained. Console changes stop being invisible, because the system opens an issue when someone makes one.
What that is, in the portfolio
-
BuiltForProd Baseline
A multi-account cloud foundation in OpenTofu and Terragrunt, customized for your organization, deployed into your accounts by our engineers, then handed over with the repositories and the documentation.
-
BuiltForProd Managed
Experienced engineers who operate, secure and evolve production as an extension of your team, working through your own access, pull requests and pipelines.
-
BuiltForProd Assessment
A fixed-fee assessment of what you run today against the eight properties of the BuiltForProd Standard, with a prioritized gap list at the end.
What you get
-
A foundation that is entirely code
Accounts, identity, networking, logging, guardrails and delivery, written in OpenTofu and Terragrunt in your own GitHub organization.
-
A plan on every change
Pull requests carry the plan as a comment, applies run in dependency order across accounts, and production waits for a named approval.
-
Drift detection you cannot ignore
Scheduled comparisons against the code that open an issue when the environment and the definition disagree.
-
Guard scripts in the review path
Automated checks that reject the shortcuts which created the original mess, including a full mock plan so a brand-new environment can be validated before it exists.
-
A migration sequence, not a big bang
Environment by environment, with the original still running and a documented rollback at every step.
-
Documentation that matches the code
Runbooks and architecture decisions generated against your own deployment, so the written description and the running system agree.
Every repository and every cloud account stays yours. We keep no standing access after handover. See security and ownership for how that is enforced, and pricing for how an engagement is quoted.
What "infrastructure as code" means here
The phrase is used loosely everywhere. This is what it means in a delivered engagement.
| What | Figure | Where it comes from |
|---|---|---|
| Infrastructure defined in code | 100% | The AWS Enterprise Baseline is deployed entirely from OpenTofu and Terragrunt. Nothing is clicked. |
| Reusable modules and units | 34 modules, 48 units | The AWS Enterprise Baseline code base, generating 83 units across the account structure. |
| Automated review guards | 6 guard scripts | AWS Enterprise Baseline CI checks for hardcoded ranges, network map integrity, stack layout, module versions and required inputs. |
| Drift detection | Daily and weekly | Critical accounts daily, all accounts weekly, in the AWS Enterprise Baseline. Findings open an issue and nothing is auto-reverted. |
| Plan before anything exists | Full mock outputs | A guard in the AWS Enterprise Baseline lets a brand-new environment be planned end to end before any resource is created. |
| Static analysis in the pipeline | 4 scanners | Checkov, Trivy, tflint and formatting checks run on every pull request in the AWS Enterprise Baseline, with actions pinned by commit hash. |
The same evidence is documented page by page in the product documentation and measured against the BuiltForProd Standard.
How it works
Four steps from the first conversation to a platform your team owns.
-
Inventory what actually exists
We look at the real environment, not the diagram: what is in code, what was clicked, what nobody remembers creating, and what is load-bearing.
-
Decide what moves and what gets rebuilt
Some resources migrate into the new structure. Some are better recreated cleanly. Data and DNS get their own plan. Then the fee is fixed.
-
Deploy the coded foundation
Our engineers deploy the foundation into your accounts alongside the current environment, with verification checks and a signed checklist.
-
Migrate, verify, retire
Environment by environment, with the old one still available, until nothing points at the console-built infrastructure and it can be switched off on purpose.
Yes, but…
The objections we hear on the first call, answered plainly.
Can you not just import what we have into code?
Importing works for some resources and produces unmaintainable code for others, especially networking and identity. We import where it is genuinely better and rebuild where importing would encode the original mistakes.
We cannot afford downtime during a migration.
The migration is designed around that. The new foundation runs in parallel, environments move one at a time, and the cutover for each workload is planned with a rollback path.
Our team will still make console changes during incidents.
Some will, and that is realistic. The difference is that drift detection opens an issue the next morning, so the change is either backported into code or reverted deliberately rather than forgotten.
Is this just Terraform with extra steps?
It is OpenTofu and Terragrunt, structured so that account, environment and region are configuration rather than copied code. The extra steps are the ones that stop a code base from becoming the next thing nobody can reproduce.
Questions
What is ClickOps?
ClickOps is building and changing cloud infrastructure by hand in a web console. It is fast for the first change and expensive for every change after, because the resulting environment has no definition, no review trail and no way to be reproduced.
How long does moving to infrastructure as code take?
The foundation is deployed in weeks of engineering. Migrating workloads onto it depends entirely on how many there are, how coupled they are and how much downtime each can tolerate, which is scoped per engagement.
Do we lose the ability to make quick changes?
You lose the ability to make invisible ones. Routine changes go through a pull request with a plan attached, which is usually faster than the meeting that currently precedes a risky console change.
What about resources we cannot move yet?
They stay where they are and are documented as exceptions, with a note on what would have to be true to move them. An honest exception list is better than a pretend migration.
Who keeps the code current afterward?
Your team, with drift detection and guard scripts making that easy to verify. Managed engineers can carry upgrades and findings triage through your own pull requests if you want help.
More answers are in the FAQ and the support center.
Make production reproducible.
Tell us what exists today, including the parts nobody wants to describe. We will tell you what should be imported, what should be rebuilt, and in what order.