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

FLYR builds AI-powered revenue management and retailing technology for airlines, cargo, and hospitality businesses, and runs around 800 workspaces on Terraform. We spoke with Tinku Biswas, Senior Engineering Manager at FLYR, about the team's move from Terraform Cloud to Scalr.

Why Look Beyond TFC

Cost optimization was the primary driver. As FLYR's infrastructure footprint expanded, TFC's pricing model stopped tracking with the team's operational budget, and that mismatch is what pushed FLYR to evaluate other IaC management platforms.

That said, TFC held up operationally, this wasn't a case of the tool falling over. Any platform this deep has a learning curve, and that held as true for Scalr during onboarding as it had for TFC. What changed was the math: as FLYR's footprint grew, the pricing and architecture no longer fit the way the team wanted to run things, and that's what turned a passive evaluation into an active decision.

Choosing Scalr

Compatibility with FLYR's existing TFC workflows and a clear migration path were the deciding factors. Scalr's structural concepts mapped closely to what FLYR already had: TFC Projects translate to Scalr Environments, so the organizational hierarchy FLYR had already built out — grouping workspaces by team, product line, or environment tier — carried over almost directly instead of needing to be redesigned from scratch. Combined with Scalr's open-source migration tooling, that made a full transition realistic without rebuilding pipelines or renegotiating how teams were organized.

The Migration

Given the complexity of FLYR's setup, the migration moved faster than expected and went smoothly.

Tooling and customization. FLYR started from Scalr's open-source Python migration script and customized it for their environment, adding logic to preserve workspace lock states along with lock comments. That mattered because FLYR uses locks and their annotations to communicate why a workspace is frozen and losing that context during the move would have meant re-deriving it by hand across every affected workspace.

Execution and backups. After about two days of testing the script, the automated bulk import itself ran in roughly a day. Before running it, FLYR downloaded full backups of all state files, projects, and workspace configurations to eliminate risk. That gave the team a clean rollback point if anything in the import needed to be redone.

Validation. FLYR spent about two weeks auditing imported workspaces, adjusting provider configurations, and running speculative plans to confirm each workspace matched its pre-migration state. Most of that time went into triaging legacy or idle workspaces - ones with stale provider versions, unused variables, or configuration drift accumulated over time — that needed minor cleanup to run cleanly in Scalr rather than being carried over as-is.

With state backups in place and the script customized for FLYR's setup, the migration ran with zero data loss.

What Changed After the Move

Two changes stood out on the architecture side. First, Scalr's provider configuration model let FLYR define credentials once at the Environment level and share them across the workspaces underneath, instead of the per-workspace duplication TFC required. That cut down on how many places a credential rotation touched and made it easier to reason about which workspaces had access to what.

Second, FLYR used the migration as a forcing function to break up its largest, longest-running workspaces into smaller ones. On TFC, a handful of workspaces had grown to cover far more infrastructure than made sense for one team to own; splitting them up gave each resulting workspace a clear owner and a plan that's actually readable, instead of a diff spanning hundreds of resources across multiple teams' infrastructure.

FLYR's Advice to Other Teams

Overall, the migration from TFC to Scalr went smoothly, with no data loss.

The biggest piece of advice: map your RBAC early. TFC Projects translate to Scalr Environments, but that mapping isn't purely cosmetic — it's the boundary Scalr uses for authorization and for how provider credentials get shared down to workspaces. Get the Environment structure wrong and you either end up over-sharing credentials across teams that shouldn't have them, or fragmenting access so much that legitimate work gets blocked. Working through that mapping deliberately, before the bulk import, is what kept FLYR's access model clean and enabled teams to move faster.

Key Takeaways