Hello to all you Terraform Cloud users out there! We have an entire section of our website dedicated to the key features and platform differences between env0 and Terraform Cloud that make us the best Terraform Cloud Alternative. More and more customers have been migrating from Terraform Cloud to env0, and we have been asked quite a few times what the POC / Migration process looks like. The typical engineering answer is âit depends.â The good news there is that we can help answer some of the questions you may have that would help you make the right migration decisions. This blog is going to dive into the decisions that need to be made, env0âs recommendations, and then weâll get to the meat of the process. So letâs jump right in!
Questions to Answer
As with any kind of project or design, there are a bunch of questions we need to answer first. For the task of migrating a user who is all-in on Terraform Cloud to env0, these are the questions we need answers to:
What are we going to migrate? Remote Runs? State? Both?
The main feature that customers are looking to migrate is obviously going to be the remote runs. The main function of env0 and Terraform Cloud is to consolidate and manage the Terraform runs so that you donât have to do it all from each userâs laptop. If youâre not looking to migrate remote runs, then this blog doesnât really apply to you, as there really isnât any advantage to that. The real question is going to be what youâre going to do with the state.
How are you going to manage the state? S3 / Cloud Storage? env0? Terraform Cloud?
As we just mentioned, migrating applies is pretty much a given at this point. But what about the state? There are so many options. But it comes down to what youâre doing with it now. If you are doing your Terraform runs on Terraform Cloud, are you using the same platform for the state? Or are you using a solution like an S3 remote backend in your own cloud? Our recommendation for the migration procedure depends on what your answer to this question is.
env0 Recommendation
Now that weâve gotten some of the questions out of the way, letâs talk about env0âs recommendations. We talked about how if youâre not moving applies, thereâs really nothing to do. env0 does not offer remote state backend capabilitiesâŚyet (Stay tuned). We will manage your state for you if you do not have a backend configuration in the code, but it is always best practice to manage your own state in your own cloud account, due to the sensitive nature of the contents of the state file. Because of this, our first recommendation is to move your Terraform remote runs to env0. This way you can take full advantage of the env0 platform.
Second, it is a general recommendation for any Terraform user to use a backend other than Local. There is a large amount of sensitive data inside the state, so securing it inside of your own cloud environment is always best. Terraform Cloud will store state for you, as will env0 if you do not specify a backend in the code. Therefore, we recommend you set up an s3 bucket or other cloud storage bucket in your cloud account to use. You can find documentation on backend configuration here. You can find specific information on using S3 here. If you still want to use Terraform Cloud as the remote backend, or if you just want to evaluate env0 without changing the Terraform Cloud backend, you can do so by following the instructions here.
Migration Procedure
Setup: I have a deployment running in my Terraform Cloud workspace. I am using the two-tier application example from the AWS Terraform Provider repository. You can see the code here.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d5078265144bbe99b308_60d35b611e28ba8da66c1823_0*fTQ73cyAGyaxiSwy.png)
And a quick look at my variable setup for this specific Workspace:
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d5078265142d5499b30d_60d35b603c1bf082e2971032_0*FbRYN0zBWg1EZ0m6.png)
Also good to note that we want to disable the continuous deployment trigger at this point. We donât want Terraform Cloud pushing deployments any longer. You can set the Apply to manual. This is in the Settings -> General -> Manual Apply
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d5078265147ff799b311_60d35b60053adb1ed773a5f9_0*VZKm-mi_xCU2HloK.png)
Alright, we are done with all the boring paperwork and pre-work. Weâve finally made it to the fun part. Letâs talk about the actual migration process. Weâre going to assume for this guide that you are currently using Terraform Cloud for Applies and for State and that you want to migrate fully off Terraform Cloud. This is going to require some local (or jump-server) CLI work, as Terraform Cloud doesnât support the ability to migrate the state off TFC to another provider. Itâs pretty straightforward, so letâs take a look at the overall process:
- Install / Configure Terraform Locally
- Git Clone the repository to the machine
- Run [.code]terraform init[.code] against the current state configuration
- Change the Backend configuration in the code
- Run [.code]terraform init[.code] again to migrate the state
- Git Commit / Push to update the backend config change into the repo
- Create Project & Template in env0
- Deploy the environment in env0 specifying the Workspace name
- Delete the workspace from Terraform Cloud without destroying the deployment.
So letâs do it!
Install / Configure Terraform Locally
This one is pretty straightforward. Because of the inability to migrate state away from TFC to something else from the TFC interface, we just need to snag the files and do this locally. You can do this on your local machine, or from a jump server if you prefer. Just some machine you can run the terraform CLI on, and that you can Git Clone files on to execute against. To install Terraform CLI you can find the method here. (Just make sure you download the same version as youâre currently using.)
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d5078265145a2b99b30e_60d35b609f0c6695f400f372_0*TUXFOd2HtsupOo9B.png)
Youâll need to log in to Terraform Cloud with the CLI so that you can use your remote backend on TFC from your local machine. If it canât login to TFC< it canât grab the state to migrate it. Running the following command will prompt you to get an API token that you can use
[.code]terraform login[.code]/
When youâre done, it should look like this:
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514553599b313_60d35b6026cf3921c1bc491d_0*Wk1oH-hVLK42jnXA.png)
Git Clone the repository to the machine
You will need a copy of the files locally so that we can do the Terraform Init to migrate the backend to our Cloud provider. So do a Git Clone of your repository onto the machine youâll be doing the work on.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d5078265141c6899b30f_60d35b60473499cae86eacca_0*p0njtziqPWMHUAhn.png)
Run [.code]terraform init[.code] against the current state configuration
The local copy and terraform CLI need to know that there is already a copy of the deployment out there running. So weâll just run a quick command against the files
terraform init
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514456a99b304_60d35b611760297523747734_0*ChW7-ZxyLdBRldfF.png)
You should see an update in the TFC UI for your state update. This is a sign that the init / connection is successful.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d50782651455f399b303_60d35b610813848261a8f47c_0*1PCTJuvebZfm1SuM.png)
Change the backend configuration
For this, I am just going to jump into VI and change the âterraformâ code block so that it now points at my desired S3 backend. Your bucket name and all will be different, just set it to what you need it to be. Because env0 will need to Read / Write to this later, just set the âkeyâ to [.code]terraform.tfstate[.code] like so:
Run [.code]terraform init[.code] again to migrate the state
This one is a bit different than the last one. Because weâre going to be migrating the state, we need to add that flag to the command [.code]terraform init -migrate-state[.code].
Youâll be asked to confirm the state migration by typing âyesâ and hitting enter.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514e0eb99b300_60d35b6161c5453d9b1224c7_0*9kuoxLbhAS-bo13w.png)
Then itâs done!
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514f95799b301_60d35b610f273b57ee867d3e_0*x7kkMmFlFLSD0BYz.png)
We can see from the above that the state was migrated. And we can validate that in S3:
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d5078265147f9799b305_60d35b61053adbe11073a665_0*PDFKvozebX16VJxd.png)
Now weâre in a position where our Applies are hosted on TFC still, but our backend has been migrated to a 3rd-party location so that we can now shift the applies over to env0. Letâs do some quick clean-up, and get to env0!
Push to update into the repo (Git Commit)
Because we made changes to the terraform files locally so that we could migrate the backend, we need to get that code back to our repository so that when we try to execute it in env0, the new backend information is used as opposed to the old TFC backend. You can do this with a Git Commit and Git Push right from where you were, or you can use whatever method youâd like. to get that updated in the repo. Weâve validated that update in GitHub here:
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514261899b2ff_60d35b61cb64e021d0e490ea_0*87Ll2MjXBXt0WPFK.png)
Now letâs jump into env0 and get this migration finished up!
Create the Project & Template in env0
We have created a project inside the env0 platform called Terraform Cloud Migration Demo:
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514e0ee99b30a_60d35b614c7da0e035b1ef99_0*M3IQ0D91ig5MTXAc.png)
Inside this project, we have configured the AWS Cloud credentials so we can use AWS Assumed Role. This is a feature that is not available in Terraform Cloud. Check our out docs on how to do that here. Not using AWS, or just want to use regular key + secret? No problem! env0 can deploy to any cloud that there is an Infrastructure as Code provider for. Docs on cloud account credential configuration are here.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d5078265142ce899b314_60d35b6226cf391bf2bc4a8c_0*oVZ3UsLszhPJnqme.png)
For our template, weâll put some basic details on it. It is important to note that unlike setting up a Workspace in TFC when you set up a template in env0, you can use that template for multiple different projects and environments. Workspaces in TFC canât be cloned.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514a30599b310_60d35b611e3e4147ca6285e2_0*dICtLKHM_rEGzetw.png)
Weâll link our template to our repository, set our default branch, and point the template at our Terraform Folder. This structure allows us to support mono-repo and multi-repo strategies.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514efea99b309_60d35b6147349966856eadd9_0*vontE9-axGdhLWRw.png)
env0 has the ability to scope variables at the Org (global), Project, Environment, and even template level. So you donât have to keep copy/pasting variables when they will be re-used across templates or projects. But, unfortunately, weâll need to go fetch those variables somehow out of the existing Terraform Cloud Workspace, and set them up in env0. You can rest assured your secrets are safe with us. We have our SOC 2 Type II report available for the SaaS platform, and even a Self-Hosted Agent available for next-level security and control. Read more about our security here.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514fd0c99b30c_60d35b61053adbd7df73a69c_0*l4zHhILetyDQV1kk.png)
Deploy the environment in env0 specifying the Workspace name
We are set to go for our first âdeployment.â Donât worry, though. This is not going to mess up what you already have. We actually recommend doing it the first time without Cloud Credentials, if you want to be extra cautious. This will let you validate the Terraform Init step for variables, etc. Because we have the state in place already, and weâre specifying a workspace name in env0. Because we migrated the state from TFC to S3, the Terraform CLI set the workspace name as âdefaultâ for the migrated state. So weâll do our deployment with the template we created and set the Workspace Name to default. Also make sure your Destroy Environment (TTL) is set to Unlimited. And be very careful about un-checking the Approve Plan Automatically button, as we want to validate the plan before any applies are done.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514428e99b302_60d35b6127be2c457db4197b_0*8FmGQkw4jUcmg20S.png)
Because there were no changes to any of the objects in the state, env0 is going to read the state and see that we donât have anything to do. So weâll just hit Approve and finish up.
One step to point out here is the Tag Resources step. When you enable Cost Monitoring on your project, this is where our open-source project Terratag runs so that your resources are tagged so that we can collect the actual cost data for the deployment.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514871b99b30b_60d35b629ac8940b9e4e0e74_0*niZsaRq5-x2lkmbH.png)
And then we just have to check the plan out and validate it is going to work properly.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514837499b306_60d35b62fa5a3ce863eb1da5_0*neCbfCm0WKX_1EMF.png)
Done!
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514fc6799b307_60d35b6248b1a3acb6290a33_0*iyvELay9DBuWi_6a.png)
And our S3 bucket state file was updated! Confirmed with the time stamp.
Delete the workspace from TFC without destroying the deployment.
Last, but not least, we need to clean up TFC. Weâll go into the Workspace and click on Settings -> Destruction & Deletion
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514241799b312_60d35b62e5f12e593e337570_0*A7JEeFJX2aaWhw3Y.png)
We want to make sure we Delete Workspace. If you select Destroy, it will possibly reach out and nuke your cloud resources. We wanted to do this live, so select Delete. Type the workspace name, and itâs gone!
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514d48599b2fe_60d35bf1e16b22c05e6525a4_TFCM.png)
Thatâs it! Your life workloads from Terraform Cloud are still running and inherited into env0 for future management. In order to test that everything is working properly, you can make a comment update or something similar to one of your Terraform files, opening a Pull Request, and validating that the Pull Request Plan runs and generates inside your SCM.
â
To learn more about the advantages of migrating from Terraform Cloud to env0, check out our Terraform Cloud Alternative page.
â
Hello to all you Terraform Cloud users out there! We have an entire section of our website dedicated to the key features and platform differences between env0 and Terraform Cloud that make us the best Terraform Cloud Alternative. More and more customers have been migrating from Terraform Cloud to env0, and we have been asked quite a few times what the POC / Migration process looks like. The typical engineering answer is âit depends.â The good news there is that we can help answer some of the questions you may have that would help you make the right migration decisions. This blog is going to dive into the decisions that need to be made, env0âs recommendations, and then weâll get to the meat of the process. So letâs jump right in!
Questions to Answer
As with any kind of project or design, there are a bunch of questions we need to answer first. For the task of migrating a user who is all-in on Terraform Cloud to env0, these are the questions we need answers to:
What are we going to migrate? Remote Runs? State? Both?
The main feature that customers are looking to migrate is obviously going to be the remote runs. The main function of env0 and Terraform Cloud is to consolidate and manage the Terraform runs so that you donât have to do it all from each userâs laptop. If youâre not looking to migrate remote runs, then this blog doesnât really apply to you, as there really isnât any advantage to that. The real question is going to be what youâre going to do with the state.
How are you going to manage the state? S3 / Cloud Storage? env0? Terraform Cloud?
As we just mentioned, migrating applies is pretty much a given at this point. But what about the state? There are so many options. But it comes down to what youâre doing with it now. If you are doing your Terraform runs on Terraform Cloud, are you using the same platform for the state? Or are you using a solution like an S3 remote backend in your own cloud? Our recommendation for the migration procedure depends on what your answer to this question is.
env0 Recommendation
Now that weâve gotten some of the questions out of the way, letâs talk about env0âs recommendations. We talked about how if youâre not moving applies, thereâs really nothing to do. env0 does not offer remote state backend capabilitiesâŚyet (Stay tuned). We will manage your state for you if you do not have a backend configuration in the code, but it is always best practice to manage your own state in your own cloud account, due to the sensitive nature of the contents of the state file. Because of this, our first recommendation is to move your Terraform remote runs to env0. This way you can take full advantage of the env0 platform.
Second, it is a general recommendation for any Terraform user to use a backend other than Local. There is a large amount of sensitive data inside the state, so securing it inside of your own cloud environment is always best. Terraform Cloud will store state for you, as will env0 if you do not specify a backend in the code. Therefore, we recommend you set up an s3 bucket or other cloud storage bucket in your cloud account to use. You can find documentation on backend configuration here. You can find specific information on using S3 here. If you still want to use Terraform Cloud as the remote backend, or if you just want to evaluate env0 without changing the Terraform Cloud backend, you can do so by following the instructions here.
Migration Procedure
Setup: I have a deployment running in my Terraform Cloud workspace. I am using the two-tier application example from the AWS Terraform Provider repository. You can see the code here.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d5078265144bbe99b308_60d35b611e28ba8da66c1823_0*fTQ73cyAGyaxiSwy.png)
And a quick look at my variable setup for this specific Workspace:
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d5078265142d5499b30d_60d35b603c1bf082e2971032_0*FbRYN0zBWg1EZ0m6.png)
Also good to note that we want to disable the continuous deployment trigger at this point. We donât want Terraform Cloud pushing deployments any longer. You can set the Apply to manual. This is in the Settings -> General -> Manual Apply
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d5078265147ff799b311_60d35b60053adb1ed773a5f9_0*VZKm-mi_xCU2HloK.png)
Alright, we are done with all the boring paperwork and pre-work. Weâve finally made it to the fun part. Letâs talk about the actual migration process. Weâre going to assume for this guide that you are currently using Terraform Cloud for Applies and for State and that you want to migrate fully off Terraform Cloud. This is going to require some local (or jump-server) CLI work, as Terraform Cloud doesnât support the ability to migrate the state off TFC to another provider. Itâs pretty straightforward, so letâs take a look at the overall process:
- Install / Configure Terraform Locally
- Git Clone the repository to the machine
- Run [.code]terraform init[.code] against the current state configuration
- Change the Backend configuration in the code
- Run [.code]terraform init[.code] again to migrate the state
- Git Commit / Push to update the backend config change into the repo
- Create Project & Template in env0
- Deploy the environment in env0 specifying the Workspace name
- Delete the workspace from Terraform Cloud without destroying the deployment.
So letâs do it!
Install / Configure Terraform Locally
This one is pretty straightforward. Because of the inability to migrate state away from TFC to something else from the TFC interface, we just need to snag the files and do this locally. You can do this on your local machine, or from a jump server if you prefer. Just some machine you can run the terraform CLI on, and that you can Git Clone files on to execute against. To install Terraform CLI you can find the method here. (Just make sure you download the same version as youâre currently using.)
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d5078265145a2b99b30e_60d35b609f0c6695f400f372_0*TUXFOd2HtsupOo9B.png)
Youâll need to log in to Terraform Cloud with the CLI so that you can use your remote backend on TFC from your local machine. If it canât login to TFC< it canât grab the state to migrate it. Running the following command will prompt you to get an API token that you can use
[.code]terraform login[.code]/
When youâre done, it should look like this:
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514553599b313_60d35b6026cf3921c1bc491d_0*Wk1oH-hVLK42jnXA.png)
Git Clone the repository to the machine
You will need a copy of the files locally so that we can do the Terraform Init to migrate the backend to our Cloud provider. So do a Git Clone of your repository onto the machine youâll be doing the work on.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d5078265141c6899b30f_60d35b60473499cae86eacca_0*p0njtziqPWMHUAhn.png)
Run [.code]terraform init[.code] against the current state configuration
The local copy and terraform CLI need to know that there is already a copy of the deployment out there running. So weâll just run a quick command against the files
terraform init
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514456a99b304_60d35b611760297523747734_0*ChW7-ZxyLdBRldfF.png)
You should see an update in the TFC UI for your state update. This is a sign that the init / connection is successful.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d50782651455f399b303_60d35b610813848261a8f47c_0*1PCTJuvebZfm1SuM.png)
Change the backend configuration
For this, I am just going to jump into VI and change the âterraformâ code block so that it now points at my desired S3 backend. Your bucket name and all will be different, just set it to what you need it to be. Because env0 will need to Read / Write to this later, just set the âkeyâ to [.code]terraform.tfstate[.code] like so:
Run [.code]terraform init[.code] again to migrate the state
This one is a bit different than the last one. Because weâre going to be migrating the state, we need to add that flag to the command [.code]terraform init -migrate-state[.code].
Youâll be asked to confirm the state migration by typing âyesâ and hitting enter.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514e0eb99b300_60d35b6161c5453d9b1224c7_0*9kuoxLbhAS-bo13w.png)
Then itâs done!
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514f95799b301_60d35b610f273b57ee867d3e_0*x7kkMmFlFLSD0BYz.png)
We can see from the above that the state was migrated. And we can validate that in S3:
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d5078265147f9799b305_60d35b61053adbe11073a665_0*PDFKvozebX16VJxd.png)
Now weâre in a position where our Applies are hosted on TFC still, but our backend has been migrated to a 3rd-party location so that we can now shift the applies over to env0. Letâs do some quick clean-up, and get to env0!
Push to update into the repo (Git Commit)
Because we made changes to the terraform files locally so that we could migrate the backend, we need to get that code back to our repository so that when we try to execute it in env0, the new backend information is used as opposed to the old TFC backend. You can do this with a Git Commit and Git Push right from where you were, or you can use whatever method youâd like. to get that updated in the repo. Weâve validated that update in GitHub here:
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514261899b2ff_60d35b61cb64e021d0e490ea_0*87Ll2MjXBXt0WPFK.png)
Now letâs jump into env0 and get this migration finished up!
Create the Project & Template in env0
We have created a project inside the env0 platform called Terraform Cloud Migration Demo:
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514e0ee99b30a_60d35b614c7da0e035b1ef99_0*M3IQ0D91ig5MTXAc.png)
Inside this project, we have configured the AWS Cloud credentials so we can use AWS Assumed Role. This is a feature that is not available in Terraform Cloud. Check our out docs on how to do that here. Not using AWS, or just want to use regular key + secret? No problem! env0 can deploy to any cloud that there is an Infrastructure as Code provider for. Docs on cloud account credential configuration are here.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d5078265142ce899b314_60d35b6226cf391bf2bc4a8c_0*oVZ3UsLszhPJnqme.png)
For our template, weâll put some basic details on it. It is important to note that unlike setting up a Workspace in TFC when you set up a template in env0, you can use that template for multiple different projects and environments. Workspaces in TFC canât be cloned.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514a30599b310_60d35b611e3e4147ca6285e2_0*dICtLKHM_rEGzetw.png)
Weâll link our template to our repository, set our default branch, and point the template at our Terraform Folder. This structure allows us to support mono-repo and multi-repo strategies.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514efea99b309_60d35b6147349966856eadd9_0*vontE9-axGdhLWRw.png)
env0 has the ability to scope variables at the Org (global), Project, Environment, and even template level. So you donât have to keep copy/pasting variables when they will be re-used across templates or projects. But, unfortunately, weâll need to go fetch those variables somehow out of the existing Terraform Cloud Workspace, and set them up in env0. You can rest assured your secrets are safe with us. We have our SOC 2 Type II report available for the SaaS platform, and even a Self-Hosted Agent available for next-level security and control. Read more about our security here.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514fd0c99b30c_60d35b61053adbd7df73a69c_0*l4zHhILetyDQV1kk.png)
Deploy the environment in env0 specifying the Workspace name
We are set to go for our first âdeployment.â Donât worry, though. This is not going to mess up what you already have. We actually recommend doing it the first time without Cloud Credentials, if you want to be extra cautious. This will let you validate the Terraform Init step for variables, etc. Because we have the state in place already, and weâre specifying a workspace name in env0. Because we migrated the state from TFC to S3, the Terraform CLI set the workspace name as âdefaultâ for the migrated state. So weâll do our deployment with the template we created and set the Workspace Name to default. Also make sure your Destroy Environment (TTL) is set to Unlimited. And be very careful about un-checking the Approve Plan Automatically button, as we want to validate the plan before any applies are done.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514428e99b302_60d35b6127be2c457db4197b_0*8FmGQkw4jUcmg20S.png)
Because there were no changes to any of the objects in the state, env0 is going to read the state and see that we donât have anything to do. So weâll just hit Approve and finish up.
One step to point out here is the Tag Resources step. When you enable Cost Monitoring on your project, this is where our open-source project Terratag runs so that your resources are tagged so that we can collect the actual cost data for the deployment.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514871b99b30b_60d35b629ac8940b9e4e0e74_0*niZsaRq5-x2lkmbH.png)
And then we just have to check the plan out and validate it is going to work properly.
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514837499b306_60d35b62fa5a3ce863eb1da5_0*neCbfCm0WKX_1EMF.png)
Done!
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514fc6799b307_60d35b6248b1a3acb6290a33_0*iyvELay9DBuWi_6a.png)
And our S3 bucket state file was updated! Confirmed with the time stamp.
Delete the workspace from TFC without destroying the deployment.
Last, but not least, we need to clean up TFC. Weâll go into the Workspace and click on Settings -> Destruction & Deletion
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514241799b312_60d35b62e5f12e593e337570_0*A7JEeFJX2aaWhw3Y.png)
We want to make sure we Delete Workspace. If you select Destroy, it will possibly reach out and nuke your cloud resources. We wanted to do this live, so select Delete. Type the workspace name, and itâs gone!
![](https://cdn.prod.website-files.com/63eb9bf7fa9e2724829607c1/6411d507826514d48599b2fe_60d35bf1e16b22c05e6525a4_TFCM.png)
Thatâs it! Your life workloads from Terraform Cloud are still running and inherited into env0 for future management. In order to test that everything is working properly, you can make a comment update or something similar to one of your Terraform files, opening a Pull Request, and validating that the Pull Request Plan runs and generates inside your SCM.
â
To learn more about the advantages of migrating from Terraform Cloud to env0, check out our Terraform Cloud Alternative page.
â