Why Big Migrations Stall — and How Spotify Unsticks Them
Large-scale technology upgrades tend to follow a familiar curve: strong early momentum, then a long grind that leaves a trailing set of systems on outdated versions. That "long tail" is how fragmentation creeps into an infrastructure. Spotify has spent the last year and a half working against that pattern, and the approach it landed on comes down to three things: ruthless prioritization, product management discipline, and automation.
From Email Overload to a Single Plan
Before 2017, Spotify's Platform Mission organization handled migrations the way many companies do: every infrastructure team sent out its own deprecation notices, often with short deadlines. With hundreds of engineering squads spread across the globe, the result was a flood of confusing, sometimes documentation-light emails that left teams unsure what to prioritize — or what the migration actually required.
Culture matters here. Spotify leans on autonomy, so it favors persuasion over mandates. The fix wasn't going to be a stricter decree; it was going to be a better system for deciding what actually needs to happen and communicating it clearly.
Prioritize, Product-Manage, Automate
A Single Source of Truth
The first piece was creating one company-wide migrations map, with priorities negotiated through Spotify's technical architecture group (TAG). The map functions as a contract with engineering teams: it estimates cost, names who's impacted, and sets deadlines. Consolidating all migration communication into one place — visible through the Backstage developer portal — means engineers no longer have to track a scattered pile of emails.
Getting alignment across more than 45 infrastructure product managers took time. The persuasive data point: migrations that should have taken weeks were stretching into months, largely because the teams doing the work were overwhelmed by competing demands and information.
Migrations as Products
Spotify treats platform work with a product management mindset, and migrations are no exception. Every migration gets a dedicated product manager accountable for its success. That involves more than shepherding a timeline:
- Test before launch. Migrations go through alpha and beta phases with small groups before wider rollout. This keeps trust high — no one wants to invest effort in a half-baked tool.
- Train where needed. For migrations that introduce unfamiliar technology, Spotify's internal Tech Learning function builds training to reduce the anxiety of moving off systems engineers have used for years.
- Make the value case. Product marketing managers help articulate why a migration matters from productivity, cost, and scalability angles — not just to engineers but to engineering managers and leadership, making it easier to get tech-health work onto team sprints.
- Know the customers. A one-size-fits-all rollout doesn't work. PMs segment their user base and drive targeted plans for different teams.
- Show progress. A Backstage plugin called Tech Insights displays migration progress by tribe and squad, adding a light gamification element that shows teams where they stand relative to others.
Critically, PMs drive each migration to 100% completion — including hands-on work with the last remaining teams in the long tail. That's tedious but necessary to actually reduce fragmentation instead of just declaring victory at 90%.
Automation and Higher Abstraction
Where possible, Spotify automates the underlying infrastructure change entirely, so teams may not even notice a component like a Puppet version has moved. When a migration can't be fully invisible, automated pull requests are generated for teams to review and merge.
The Steady March Up the Stack
The longer-term goal is to insulate engineering teams from most migrations entirely by moving platform tooling higher up the stack, where underlying components aren't directly exposed. Spotify's experience suggests that consolidating priorities, applying product discipline, and pushing automation can go a long way toward finally clearing that long tail of technical debt.



