ClickOps to Terraform Migration

Problems we solve

• AWS or Azure infrastructure built entirely via Console, nobody knows what exists or why
• Attempts to write Terraform for existing resources create drift and state conflicts
• Fear of running terraform apply, last time it destroyed a resource group by accident
• Security groups and IAM policies cannot be version-reviewed before changes go live
• Duplicated environments: staging was "copied" from production manually 6 months ago

Our approach

1. 01

   Infrastructure discovery

   We run Steampipe or AWS Config queries to produce a resource inventory. We identify which resources are safe to import, which need recreation, and which should be excluded from Terraform.

2. 02

   Code generation

   Terraformer (AWS) or aztfexport (Azure) generates initial Terraform HCL from existing resources. The output is raw and needs review, but it gives a starting point for every discovered resource.

3. 03

   Code refinement

   Generated code is cleaned up: magic strings replaced with variables, resources grouped into logical modules, naming conventions applied, and unnecessary attributes removed. This is the most labour-intensive phase.

4. 04

   State import

   We run terraform import or use import blocks to bring existing resources into state. We verify the state matches reality with terraform plan, a clean plan (no changes) confirms a successful import.

5. 05

   Drift detection and CI

   A scheduled GitHub Actions or Atlantis job runs terraform plan on a schedule and alerts on any drift between state and actual infrastructure. New resources must be created via Terraform only, ClickOps can be restricted by policy.

Results