Raise your hand if you’ve ever inherited a mess of manually created cloud resources.
Maybe your team has been clicking around in cloud consoles for years, and now your infrastructure is an unmanageable, undocumented monster. Or perhaps you have hundreds of resources, and nobody knows exactly how they were configured.
Sound familiar? Don’t worry—Terraform can bring order to the madness!
In this post, we’ll cover:
- Why you should migrate legacy infrastructure to Terraform.
- How to import existing cloud resources into Terraform.
- How to avoid downtime and disasters during migration.
- Tips for making the transition as painless as possible.
Let’s get your infrastructure under control!
1. Why Migrate Legacy Infrastructure to Terraform?
If your infrastructure was built manually, you might be thinking:
“If it ain’t broke, why fix it?”
Here’s why moving to Infrastructure as Code (IaC) with Terraform is worth it:
No Documentation – If your infrastructure only exists in a cloud portal, good luck figuring out what’s running where.
Inconsistent Configurations – Without Terraform, different environments can drift apart over time.
Manual Mistakes – Manually provisioning resources leads to errors and inconsistencies.
No Version Control – You can’t track changes, roll back mistakes, or collaborate effectively.
With Terraform, you get repeatable, version-controlled infrastructure that just works.
2. Preparing for Migration: Don’t Skip This Step!
Before jumping into Terraform, take some time to audit your current infrastructure.
Step 1: List All Existing Resources
Run cloud provider commands to get an inventory of what’s currently deployed:
Azure:
az resource list --output table
AWS:
aws resourcegroupstaggingapi get-resources
GCP:
gcloud compute instances list
Why It’s Important: You need to know what exists before you start migrating.
3. Importing Legacy Infrastructure into Terraform
The easiest way to bring existing resources under Terraform’s control? Use terraform import.
Example: Importing an Azure Storage Account
terraform import azurerm_storage_account.example /subscriptions/xxxx/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/mystorage
Example: Importing an AWS EC2 Instance
terraform import aws_instance.example i-1234567890abcdef0
What This Does:
- Terraform adds the resource to its state file.
- Terraform won’t try to recreate the resource—it will just start managing it.
4. Generating Terraform Configuration (No Manual Writing!)
Manually writing Terraform for hundreds of resources? No thanks!
Luckily, you can auto-generate Terraform configs with:
- Terraformer (supports AWS, Azure, GCP)
- Azure Resource Manager (ARM) to Terraform Converter
Example: Using Terraformer to Export AWS Infrastructure
terraformer import aws --resources=ec2,s3,vpc
Now, Terraform will generate HCL code for your existing resources!
- Why It’s Important: Saves time and prevents human error when writing Terraform configs.
5. Avoiding Downtime: The Safe Migration Plan
DO NOT just start applying Terraform blindly—you might accidentally delete or overwrite production resources.
Step 1: Plan & Test in a Dev Environment
- Import a small subset of resources first (e.g., one VM).
- Validate the Terraform plan before applying any changes.
Step 2: Use terraform plan to Check for Changes
terraform plan
If Terraform tries to replace existing resources, you may need to:
- Update the Terraform configuration to match real-world settings.
- Use lifecycle policies to prevent Terraform from touching certain resources:
resource "azurerm_storage_account" "example" {
name = "mystorage"
location = "East US"
lifecycle {
ignore_changes = [tags]
}
}
Why It’s Important: Terraform won’t overwrite or delete resources accidentally.
6. Enforcing Terraform-Managed Infrastructure
Once your infrastructure is managed by Terraform, block manual changes to prevent configuration drift!
Option 1: Use Terraform Cloud Policy Enforcement
Terraform Cloud allows you to enforce security & compliance rules:
policy "enforce_terraform_changes" {
rule {
main = if resource_changes.aws_instance.any then
error("All changes must go through Terraform.")
}
}
Option 2: Restrict Console Access
Lock down cloud console access so people can’t manually edit resources.
Why It’s Important: Keeps Terraform as the single source of truth.
7. Automating Terraform with CI/CD
Once your infrastructure is in Terraform, automate deployments using Azure DevOps, GitHub Actions, or Jenkins.
Example: Azure DevOps Terraform Pipeline
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
steps:
- script: terraform init
displayName: "Terraform Init"
- script: terraform plan -out=tfplan
displayName: "Terraform Plan"
- script: terraform apply -auto-approve tfplan
displayName: "Terraform Apply"
Why It’s Cool: No more manual terraform apply—Terraform runs automatically when you push changes!
Wrapping Up
Migrating legacy infrastructure to Terraform isn’t just a nice-to-have—it’s a game-changer for automation, security, and scalability.
Quick Recap:
- Import existing resources using
terraform import. - Generate Terraform configs automatically with Terraformer.
- Avoid downtime by using
terraform planbefore applying changes. - Block manual changes to enforce Terraform as the single source of truth.
- Automate deployments with Terraform CI/CD pipelines.
Now, go Terraform your legacy infrastructure into a modern, code-driven system!
What’s Next?
Migrating to Terraform is great, but what if you want to manage infrastructure across AWS, Azure, and GCP? In the next post, “Multi-Cloud Deployments with Terraform,” we’ll explore how to create portable, cloud-agnostic Terraform configurations—so you can deploy infrastructure anywhere, anytime.