Case Study: TV4's Migration from Terraform Cloud to Scalr
Scalr is a cost effective, drop-in replacement for Terraform Cloud, with feature parity and many quality of life improvements.
- TV4, Sweden's largest commercial TV channel, migrated 1,000 workspaces and 50,000 resources from Terraform Cloud to Scalr, driven by cost concerns and slow TFC performance.
- TV4 used a big-bang cutover automated with a Python version of Scalr's migration module, freezing infrastructure deployments for around 2 hours during the migration.
- Scalr's usage-based pricing charges only for runs that executed, which made the math work for an estate of TV4's size compared to TFC's RUM pricing.
- After migrating, TV4 reported faster, more responsive runs, a more modern UI, flexible month-to-month then annual billing, and better organizational structure across environments.
- A year on, TV4 still recommends Scalr, citing responsive support and native OpenTofu support, which Terraform Cloud lacked.
Business Overview
TV4 and MTV3 are Sweden and Finland's largest commercial television channels, respectively. In addition to producing original programming and operating television channels, they offer two digital services each in the form of streaming services and news sites.
Technical Overview
The TV4 team manages the following providers with Terraform: AWS, GitHub, Akamai, Grafana, Kubernetes, and Helm. They also use AzureAD for SSO and SCIM provisioning.
TV4 migrated away from Terraform Cloud primarily due to cost concerns but also due to lackluster service performance.
The Challenge
Like many others using Terraform Cloud, TV4 was surprised by the changes at HashiCorp, including the announced pricing changes. Based on this, they decided to move their 1,000 workspaces and 50,000 resources to a more cost-effective solution.
The deeper issue isn't just TFC's RUM pricing, where every managed resource compounds the bill regardless of activity. Concurrency-based pricing, used by some alternatives, has its own distortion: you pay for a fixed number of parallel run slots whether or not you use them. Too few and engineers queue during releases. Too many and you're renting idle capacity. Scalr's usage-based pricing charges only for runs that actually executed, which is what made the math work for an estate the size of TV4's.
Discovery & POC
TV4's main requirement was an alternative to Terraform Cloud that wouldn't upend the day-to-day work of their users. They wanted the switch to be invisible once the migration was done.
Key similarities that made Scalr a good fit:
- Ability to use the native Terraform CLI
- A Scalr workspace is the equivalent of a Terraform Cloud workspace
- A Scalr environment is very similar to a Terraform Cloud organization
- Scalr can be fully automated through their Terraform provider
TV4 verified the POC by migrating all of their platform team's workspaces a week ahead of time and dogfooding the service.
The Migration from TFC to Scalr
TV4 had to determine the best migration method:
- Allow application teams to migrate their own workspaces by giving them a deadline.
- Go with the "big-bang" approach and completely automate it with a quick cutover.
They went with the big-bang approach, comfortable with the testing done during the POC. The app teams were bought in. TV4 took the existing Scalr migration module and transformed it fully into Python, which they were more comfortable with. Their version is available on GitHub.
When it was time to migrate, they froze infrastructure deployments for around 2 hours to perform the migration. It could have been faster with async/multithreading, but they figured it was an unnecessary optimization for a one-off task.
They 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.
Improvements Since Moving to Scalr
Other than a better UI experience, TV4 also experienced:
- Performance Improvements: Terraform Cloud was frustratingly slow at times when starting jobs after changes were pushed to GitHub, whereas Scalr has consistently been responsive and has started runs within a few seconds.
- Pricing: They are not locked into any billing plan. They decided to start month-to-month to make sure they were happy with the choice and then migrated to an annual plan for larger discounts when they were ready.
- Organizational Structure: The main benefit from breaking the one large Terraform Cloud organization into multiple Scalr environments was that it's much easier to assign credentials to workspaces and manage automation such as Slack notifications when changes are made to production workspaces.
- Helicopter Views: The admin team now has more oversight into overall operations through the run dashboard at the account scope, making it easier to identify issues in the pipeline.
One Year Later: Terraform Cloud vs Scalr
It's been over a year since TV4 migrated away from Terraform Cloud. One more reason they're glad they did: TFC still has no OpenTofu support. Given how fast OpenTofu has been shipping new features, that's reason enough on its own.
TV4 continues to recommend Scalr as an alternative. Other highlights from the first year:
- Support Quality: At TFC, it was difficult to get ahold of staff for feature requests. HashiCorp was also not particularly communicative during outages. Scalr's team has been very easy to get in touch with and responsive to feature requests and feedback.
- OpenTofu Support: Native OpenTofu support in Scalr was an important advantage as the OpenTofu ecosystem matured.
"Scalr is much faster than Terraform Cloud, and executes runs with almost no latency." — David Stevens, DevOps Engineer @ TV4
Key Takeaways
| Metric | Detail |
|---|---|
| Workspaces Migrated | 1,000 |
| Resources Managed | 50,000 |
| Migration Downtime | ~2 hours |
| Migration Approach | Big-bang, fully automated via Python script |
| Primary Drivers | Cost reduction, performance improvement |
| Result | Faster runs, better pricing, improved organizational structure |
