Production was built in the console, and now it has to be defined as code
The estate works. That is exactly what makes this hard — an import that replaces a running resource is a worse day than the one you are trying to avoid.
Usually raised by: Platform lead or engineering manager with established production.
What normally triggers it: A handover, an audit finding, a second environment that has to match the first, or a new engineer who cannot tell what is deployed.
- AWS
- Terraform
- CloudFormation
- AWS CDK
- Pulumi
You probably recognise some of these.
Not all of them, and not in this order. If three or four land, this is the page you want.
- Changes get made in the console because that is faster, and the code drifts a little further behind each time.
- Some of the estate is defined as code, some is not, and nobody can say precisely which.
- The person who built it is the only one who can explain why a resource is configured the way it is.
- A previous attempt at importing stalled, or was abandoned after a scare.
What is different afterwards.
You get a stated, agreed boundary between what your infrastructure as code owns and what it does not, and a change path your engineers can use for the part inside it. The estate stops being something only its author can reason about.
The work itself
- Inventory the resources in scope and map their dependencies, including the ones nothing references and nobody has claimed.
- Agree the tool and the boundary in writing — Terraform or OpenTofu, CloudFormation, the AWS CDK or Pulumi; which resources the code governs, which stay manual for now, and why.
- Import incrementally, workload by workload, with a reviewed plan at each step.
- Modularise what repeats, so the second environment is a module call and not a copy.
- Wire the plan into CI so a drifted resource shows up as a diff rather than as a surprise.
Who does it: an InfraEdge engineer, who walks your team through what was found and answers your reviewer on each change.
A boundary you agree, and a plan that proves it.
Terraform owns
- The workload’s compute and networking
- RDS, S3 and the IAM roles it depends on
- Imported in reviewed, incremental steps
Stays manual — for now
- Resources another tool’s abstraction created
- Types that do not import cleanly
- Each named in the decision record, with why
$ terraform plan No changes. Your infrastructure matches the configuration.
The boundary is agreed in writing before the first import. The empty plan, running in CI on a pull request, is the completion test.
One agreed workload, imported and reviewable
A single resource group or workload that you nominate — typically one service and the network, identity and data resources it depends on.
Done when
The workload is under infrastructure as code, a plan shows no unexpected changes against the live resources (terraform plan, a CloudFormation change set or pulumi preview), the plan runs in CI on a pull request, and a short decision record states what was imported, what was left out and why.
What you receive
- Infrastructure as code in your repository — Terraform modules, CloudFormation or CDK stacks, or a Pulumi program — reviewed through your normal process
- State layout and backend configuration, with the boundary documented
- A CI job that runs plan on a pull request
- A decision record covering scope, exclusions and anything found that we did not change
What we need from you
- A scoped read-only role to discover the estate, and a named reviewer for the import pull requests
- A decision on where state lives and who may apply
- An agreed maintenance window for the first import, in case a plan has to be abandoned and retried
What makes it larger or smaller for you.
The variables that drive the size, judged against your own estate.
Larger if
- More accounts, and more resource types, than one workload needs
- Resources created through another tool’s abstraction, which should usually stay out rather than be adopted
- A second environment that has to end up matching the first
- No existing module convention, so one has to be agreed before anything repeats
Smaller if
- A single account, and a workload built mostly from resource types that import cleanly
- An existing module layout to follow
- A non-production copy to rehearse the import against
For a sense of elapsed time on work of this shape, the phased timeline on a comparable engagement is published with it. We do not quote a duration for your estate before seeing it, and the scope you receive after the call names the package rather than an hourly rate.
What this does not include.
Stated here rather than discovered later.
- We do not promise that every resource can be imported. Some resource types do not support it cleanly, and some are cheaper to replace than to adopt — we say which is which before starting, not after.
- Importing does not change how a resource behaves. If the current configuration is wrong, fixing it is a separate, visible change with its own approval.
- This is not a rebuild. If what you actually want is a new estate, that is a different and usually larger piece of work.
What stops an import destroying something that is currently working?
The plan output, read before anything is applied. An import writes the resource into state, then shows the difference between code and live; a destroy or replace in that plan means stop and reconcile the code. That is why the work is scoped one workload at a time with a named reviewer, and why done means an empty plan, not a completed migration.
What we can point at.
Anonymised prior delivery, described by technical shape. No client names, no logos, and no figures we did not measure.
Evidence — anonymised prior delivery
- Infrastructure as codeA scale-up’s hand-built AWS estate, discovered and imported into Terraform state resource by resource, with future changes moved behind pull requests.
- Platform baselineA growing SaaS company’s hand-built AWS account, mapped, split into a multi-account structure, and moved into Terraform behind a reviewed pipeline.
Problems that tend to arrive together.
Deploying depends on manual steps, or on one person being available
The goal is not more pipeline stages. It is that a release is the same event every time, that it can be undone, and that it does not need a particular person awake.
A new platform engineer or owner needs an estate worth inheriting
Making an estate legible to somebody who has never seen it is a different objective from making it correct, and it does not happen as a by-product. It has to be the thing being worked on.
Describe the project
Twenty minutes, no charge, with the engineer who would do the work. We work out whether this is the work you need and whether we are the right people — which is sometimes us and sometimes not. Nothing is priced on the call; if there is work worth doing, a written scope and a price reach you within 24 hours.