I need to start managing an existing production environment with Terraform without disrupting anything. The environment includes a VPC with roughly 30 subnets, four EKS clusters, Route 53 records, load balancers, and other related resources. For anyone who has handled a migration like this, what process worked best? I'm especially interested in importing many resources efficiently, organizing the Terraform configuration, and validating that production will not be changed or recreated unexpectedly.
3 Answers
Do this incrementally rather than importing the whole environment at once. A sensible order is networking first, then EKS, Route 53, load balancers, and the remaining supporting resources. For every group, use the cycle: import, inspect the state, configure the HCL, and run terraform plan until there are no unexpected changes. Aim for 0 to add, 0 to change, and 0 to destroy before applying anything. Be especially careful with EKS, VPC resources, listener rules, target groups, Route 53 zone IDs, and record types because small configuration differences can result in replacements or unwanted updates. Test the process in a non-production account or representative environment first, and consider separate modules or state files for major components.
Use Terraform imports, preferably with import blocks for a repeatable workflow. Importing dozens of subnets and other resources manually can become tedious, so you can inventory the resources with the AWS CLI and generate the import blocks or commands with a script. After each logical group is imported, inspect it with terraform show or terraform state show and write the matching HCL. Importing state does not automatically produce clean, maintainable configuration.
That makes sense. I’ll look into generating the import blocks from an AWS inventory instead of doing every resource by hand.
Use the AWS CLI or another inventory tool to discover the existing resource IDs, then have a script generate Terraform configuration templates and corresponding import commands. Treat the generated files as a starting point rather than blindly applying them, since computed values and AWS defaults may not belong in the final configuration. Also avoid editing the state file manually; use Terraform’s import and state commands instead. Start with a low-risk resource or a test environment so you can confirm the workflow before touching production.
Understood. I’ll split the migration into logical components and require a clean plan before allowing any apply operation.