I am working on migrating our project which is AWS resources that are created by TF v0.10, after migrating TF v1.0.1, there are a ton of syntax changes.
I am trying to find an efficient way to verify the changes are expected.
Currently, I am writing a script to compare two TF state files created by Terraform Apply command.
is there any best practice to verify changes for TF version migration
I tried to use Terraform show -json to generate two human-readable TF files unfortunately, show command in tf 0.10 does not support option -json.
That’s a weird choice of version to migrate to now - you should at least pick the last 1.0.x version, 1.0.11, but why not move straight to 1.4.2?
There were very major changes to the AWS provider between major versions. You don’t mention whether you are changing provider version too - if possible, try to change one component (Terraform core, vs the provider) at a time.
Are you implying you will deploy a whole new environment to AWS from scratch using the newer Terraform, and then try to compare the results? And not migrate an existing environment?
The state file format has changed over time, and also there will no doubt be lots of generated IDs, so I’m not sure that any approach based on state files is going to work out that well.
Generally people would attempt to run a plan operation on some existing state, and confirm that the new version doesn’t plan any unexpected changes.
I would consider two sings to check:
apply completed with successfully; jq '.terraform_version' terraform.tfstate shows expected version.Hi @maxb
Thank you for the question and suggestion, please see my answer as below:
That’s a weird choice of version to migrate to now - you should at least pick the last 1.0.x version, 1.0.11, but why not move straight to 1.4.2?
if I choose 1.4.2 or higher version, it requires additional work such as install Terraform 1.4.2 for our devops agent machines. there is a hard deadline that I have to finish TF version migration of existing project end of March.
To align the deadline, I wanner to leverage existing Terraform 1.0.1 for TF version migration of existing project.
There were very major changes to the AWS provider between major versions. You don’t mention whether you are changing provider version too - if possible, try to change one component (Terraform core, vs the provider) at a time.
In fact, I want to upgrade Nodejs version of AWS lambda to Nodejs18, but this requires higher AWS provider version, a higher AWS provider version requires a higher Terraform version. so I use TF 1.0.1 and AWS provider 4.58.0 to support Nodejs18 upgrade
refer: Lambda runtimes - AWS Lambda
Are you implying you will deploy a whole new environment to AWS from scratch using the newer Terraform, and then try to compare the results? And not migrate an existing environment?
The state file format has changed over time, and also there will no doubt be lots of generated IDs, so I’m not sure that any approach based on state files is going to work out that well.
Yes, I will deploy a whole change to a new environment in AWS cloud. and try to compare results between existing environment and new one.
I understood there are a lot of generated IDs that are difficult to compare, for generated IDs, I will ignore them.