Case Study: Primer's Migration from Terraform Cloud to Scalr

We run around 150 workspaces on Terraform. Like a lot of teams, we didn't set out looking for Scalr specifically. We set out looking for an answer to a renewal that had gotten too expensive, and a platform decision we'd been putting off.

The Trigger Was Cost. The Real Question Was Bigger.

Our Terraform Cloud contract was up for renewal, and the price increase attached to it was significant enough to force a real evaluation. At that point nothing was fixed: we looked at building our own pipeline logic in-house and evaluated several alternative TACO (Terraform Automation and Collaboration) providers alongside Scalr.

There wasn't friction with TFC as a platform. But staying meant continuing to commit to Terraform by default rather than making an active choice. We'd reached the point where we needed to decide, and OpenTofu looked like the right direction. It avoided vendor lock-in and kept our options open as the ecosystem kept moving.

Two Things Made the Decision Straightforward

Two factors stood out above everything else in our evaluation.

Pricing transparency. Scalr's pricing was clear enough that we could work through most of the evaluation without needing a call to figure out what something would actually cost. On top of that, it was the most price-competitive option on the table and matched our pipeline model better than the alternatives.

The quality of the technical conversation. From the first call, the discussion went straight into the details rather than following a standard sales script. Our requirements were understood immediately, and the conversation stayed focused on solving for them.

The Migration: About a Month, With Room to Redesign

Moving roughly 150 workspaces from TFC to Scalr took us about a month, and Scalr provided a free migration window to cover it. We used Scalr's TFC migration script, which handled most of the heavy lifting, though we made some adjustments to fit our setup.

Rather than a straight 1:1 mapping from TFC, we used the migration as a chance to redesign our environment and workspace structure. One detail worth flagging for anyone in the same spot: at the time we migrated, the script didn't support different workspace names between source and destination, so that's something to plan around.

A few other things stood out along the way:

• The real surprise wasn't Scalr-related. Adopting the job-based agent required bumping our Kubernetes version to 1.35, since that's a prerequisite for Scalr's agent job Helm chart.
• The hardest part wasn't the platform migration itself. It was internal work: defining and codifying an RBAC model so our engineers could do exactly what their role required, and nothing more.
• The easiest part was secrets. TFC exposes secret HCL variable values in the JSON output of its runs. Scalr's migration script picked those up and stored them as secret variables in the destination workspace automatically, which saved us from having to track down anything that wasn't already vaulted elsewhere.

What Changed After the Move

With run-based pricing in place, we built monitoring to flag anomalous run counts, and use Scalr's dashboard for a real-time view of consumption against our account limit. There's no guessing about usage and no risk of a surprise overage.

The migration also became an opportunity to improve pipeline performance. Scalr's documentation on provider, module, and binary caching was specific enough to our cloud provider that implementation was straightforward.

Moving to self-hosted job-based runners removed concurrent run restrictions entirely, so queue wait times aren't a concern anymore. There's a security upside too: every run is fully isolated, authenticates dynamically to our cloud environment, and terminates on completion. That's a meaningfully stronger posture than a persistent runner model.

Would I Recommend It?

Scalr have been excellent throughout, from the technical depth of the initial conversation and their transparent pricing, to their support during the migration and beyond. Their ability to turn around minor bug fixes quickly has also been a standout.

If you're sitting on the fence, the one thing I'd encourage you to validate is whether the run-based pricing model suits your usage patterns, since other TACO providers charge on different metrics. If it fits, the decision is pretty straightforward.

Key Takeaways

Metric	Detail
Trigger	Terraform Cloud renewal price increase
Migration Time	~1 month for ~150 workspaces
Migration Approach	Scalr's TFC migration script, plus a free migration window; used as a chance to redesign workspace structure
Decision Drivers	Pricing transparency and technical depth of the sales conversation
Hardest Part	Codifying an internal RBAC model
Easiest Part	Secret variable migration (handled automatically by the migration script)
Result	No concurrency limits, isolated per-run execution, real-time cost visibility

About Primer

Primer builds unified payments infrastructure for ambitious merchants, connecting payment service providers, fraud tools, digital wallets, and other commerce services through a single platform. Retail, travel, ticketing, and fintech businesses use Primer to manage the full payment lifecycle, from routing and monitoring to reconciliation, without stitching together separate integrations for each provider.