Infrastructure as Code vs. ClickOps: A Pragmatic Brownfield Migration Guide
When startups and growing companies launch their initial products, speed is everything. An engineer logs into the AWS or Google Cloud console, clicks a few buttons, spins up a load balancer, allocates a PostgreSQL instance, and launches the application.
This approach—affectionately called ClickOps—is fantastic for prototyping. But as the engineering team expands, ClickOps turns into an operational minefield: nobody knows why a security group rule was added, who created an orphaned disk, or how to recreate the infrastructure in an alternate region during an outage.
The solution is Infrastructure as Code (IaC), but rewriting an entire cloud footprint from scratch is unrealistic and dangerous. Here is how to migrate safely without downtime.
ClickOps vs. Infrastructure as Code
| Capability | ClickOps (Console UI) | Declarative IaC (OpenTofu / Terraform) |
|---|---|---|
| Execution Speed (Initial) | Fast (minutes to prototype) | Slower (requires code & state planning) |
| Auditability & History | Relies on retention of audit logs | Complete git commit history and PR reviews |
| Repeatability | Error-prone human re-entry | 100% deterministic recreation across regions |
| Disaster Recovery RTO | Days (reconstructing lost topology) | Minutes (tofu apply) |
| Permission Risk | Engineers require broad console admin | Engineers modify code; pipelines execute with scoped roles |
Step-by-Step Brownfield Import Roadmap
1. Freeze Console Access for Target Workloads
Before touching a line of code, establish an agreement with the team: no more manual changes in the cloud console for the specific tier being migrated (e.g., networking or database).
2. Scaffold Remote State and Backend Storage
Store your state file in an encrypted, versioned object store with distributed state locking (e.g., S3 with DynamoDB or GCS).
# backend.tf
terraform {
required_version = ">= 1.8.0"
backend "s3" {
bucket = "company-tfstate-prod"
key = "networking/terraform.tfstate"
region = "ap-south-1"
encrypt = true
dynamodb_table = "terraform-locks"
}
}
3. Use Native Declarative Import Blocks
Historically, engineers had to run complex CLI commands like terraform import. Modern versions of OpenTofu and Terraform support declarative import blocks, which allow you to specify the target cloud resource ID directly in your code:
# imports.tf
import {
to = aws_security_group.web_tier
id = "sg-01a2b3c4d5e6f7g8h"
}
Then generate the corresponding HCL configuration automatically:
tofu plan -generate-config-out=generated_sg.tf
4. Review and Clean Generated Code
Review the generated code, remove hardcoded account IDs, extract reusable variables, and ensure tags adhere to company naming standards.
5. Verify a Clean Zero-Diff Plan
Run a plan against live infrastructure. It must report zero modifications:
tofu plan
# Output: No changes. Your infrastructure matches the configuration.
Once you achieve zero-diff state alignment, remove the temporary import block and commit the resource definition to your repository.
Learn how our engineering team delivers repeatable environments with DevOps services and read our insights on why manual deployments go wrong.
