Will importing existing infrastructure cause downtime?

Importing into Terraform state does not modify running resources, it only records their configuration in state. The risk is in subsequent plans showing unintended changes if the codified configuration doesn't exactly match reality, which is why we validate every import against a zero-diff plan before any apply is run.

What if some resources can't be imported?

Some resources (certain manually configured legacy services, or resources without Terraform provider support) can't be cleanly imported. We document these explicitly in the migration report rather than forcing a fragile workaround, and recommend a path to replace or retire them over time.

Terraform, OpenTofu, or something else?

We default to Terraform for its ecosystem maturity unless there's a specific licensing or organizational reason to prefer OpenTofu. The module design and workflow are largely portable between the two if you need to switch later.

How do you prevent people from going back to console changes?

Restricting console write access for the resources under Terraform management, combined with drift detection that alerts on out-of-band changes, closes the loop. Peer review in the CI/CD pipeline also makes the code path faster than the console for anything beyond a one-off change.

Solution

Infrastructure Automation & IaC

Infrastructure changes are made by hand in the cloud console, nobody has a reliable record of what's actually deployed, and every incident investigation starts with 'what changed and who changed it.'

Approach

How we tackle it

We import existing resources into Terraform state rather than recreating infrastructure from scratch, which avoids risky rebuilds of production systems. Modules are structured around your actual usage patterns (a standard service, a standard database tier, a standard network segment) instead of generic examples, so the codebase stays maintainable as it grows rather than becoming a monolith of copy-pasted resources.

Current-state pain points

No single source of truth for what infrastructure exists or how it's configured
Manual console changes cause drift between environments
No peer review process for infrastructure changes
Onboarding new engineers to infrastructure takes weeks due to tribal knowledge
Compliance audits require manually reconstructing change history

What is in scope

Import and codify existing infrastructure into Terraform state
Module design for reusable, composable infrastructure patterns
CI/CD pipeline for plan/apply with mandatory peer review
State management, locking, and remote backend setup
Drift detection and remediation process
Multi-environment and multi-account structure via workspaces or repos

Who it is for

Teams whose infrastructure exists only in the cloud console, not in code
Organizations that inherited infrastructure from departed engineers with no documentation
Companies needing audit trails for compliance but relying on manual change processes
Teams that adopted IaC partially and now have a messy mix of managed and unmanaged resources

Prerequisites

Administrative access to the cloud accounts being codified
A code hosting platform and CI/CD runner already in use or being adopted
Willingness to freeze manual console changes once import is underway
A designated owner for the resulting Terraform codebase

Deliverables

What you end up owning

Artifacts land in your repositories and cloud accounts, with documentation to match.

Terraform codebase covering existing infrastructure, organized into reusable modules
Remote state backend with locking and access controls
CI/CD pipeline enforcing plan review before apply
Drift detection job with alerting on out-of-band changes
Module documentation and contribution guidelines
Migration report noting any resources that could not be safely imported

Implementation

How the work is sequenced

Inventory & Import Planning

Catalog existing resources across environments and determine which can be safely imported into Terraform state.

Module Design

Design reusable modules around your actual infrastructure patterns rather than generic templates.

Import & Validation

Import resources into state and validate that plans show zero unintended changes before enabling apply.

CI/CD & Guardrails

Wire up plan/apply pipelines with mandatory review, policy checks, and remote state locking.

Drift Detection & Handover

Implement scheduled drift detection and hand over module ownership and contribution process to the internal team.

Technologies

What we typically use

IaC Tooling

TerraformTerragruntOpenTofu

State & Backends

Terraform CloudS3 + DynamoDBAzure Storage backend

CI/CD

GitHub ActionsAtlantisGitLab CI

Policy & Validation

OPA / ConftesttflintCheckov

Outcomes

What changes when this is done

Qualitative outcomes only. Any figures depend entirely on your estate, and we will not quote them before measuring.

A version-controlled, reviewable record of every infrastructure change
Faster onboarding since infrastructure is documented in code, not tribal knowledge
Reduced drift between environments
Audit-ready change history for compliance requirements
Reusable modules that speed up provisioning of new services

FAQ

Common questions

Related service

DevOps

Talk to the engineers who would do the work

Bring your current architecture, constraints and the problem you are trying to solve. We will tell you what we would change first, what it depends on, and where we would start.

Book a Technical Consultation See how we work