Your costs = usage. Period.

Updated April 16, 2025 to include TV4's experience after the 1 year mark of having migrated off Terraform Cloud.
TV4 and MTV3 are Sweden and Finland's largest commercial television channels, respectively. In addition to producing original programming and operating television channels, we offer two digital services each in the form of streaming services and news sites.
The TV4 team manages the following providers with Terraform: AWS, GitHub, Akamai, Grafana, Kubernetes, and Helm. We also use AzureAD for SSO and SCIM provisioning to Scalr.
We migrated away from Terraform Cloud primarily due to cost concerns but also due to lackluster service performance.
Like many others using Terraform Cloud, we were surprised by all of the changes going on at HashiCorp, including the announced pricing changes. Based on this we decided to move our 1,000 workspaces and 50,000 resources to a more cost-effective solution and wanted to share what our experience was like.
Our main requirement when selecting a product was to provide an alternative to Terraform Cloud that did not massively impact the day-to-day operations of our users. We wanted a change but did not want a change to be so impactful that it hindered our development experience after the migration. Scalr offers some of the same core functionality we were accustomed to:
We ended up verifying that the POC met our needs by migrating all of our (the platform team’s) workspaces a week ahead of time and dogfooding the service.
We first had to determine the methods to migrate from Terraform Cloud to Scalr:
We decided to go with a big-bang approach as we were comfortable with the migration testing that was done during the POC, and the app teams were bought in. We took the existing Scalr module and transformed it fully into Python, which we were more comfortable with. You can check out our version of this here.
When it was time to migrate, we froze infrastructure deployments for around 2 hours to perform this migration. It could have been faster if the Python script had used async/multithreading, but we figured it was an unnecessary optimization for a one-off task.
We bumped into a couple of minor issues along the way regarding pagination, some IAM roles that were missing, and having to remove old TFC lockfiles, but these were all quickly resolved.
Overall, the migration was a large success, and since fully onboarding, there have been multiple comments from the app teams regarding the Scalr interface feeling more responsive and modern than TFC.
Other than a better UI experience, we also experienced:
Edited 4/16/2025 to add:
It's been over a year since we migrated away from Terraform Cloud, and another major reason we're happy we did so is the continued lack of support for OpenTofu in TFC. That alone is a pretty strong argument for us, especially considering the pace and type of new features (lots of long-standing quality-of-life improvements) being implemented in OpenTofu.
I would (and do) continue to recommend Scalr as an alternative, we’ve been very happy with the platform. Another thing that we have found much more pleasant with Scalr is the level of support. At TFC, we felt that it was difficult to get ahold of staff for feature requests. They were also not particularly communicative during their outages, which was a major annoyance for us.
Our experience with Scalr has been the opposite, they guys are very easy to get in touch with and listen to the feature requests and feedback that we give. I really mean that! My compliments especially to Ryan but also Edgar and Petro. It’s been a pleasure working with them and we feel heard, which we really didn’t at TFC.
This blog was published on behalf of TV4