Platform Migration at Scale: Lessons from Spotify’s Mobile Engineering Effort
As codebases and organizations grow, platform teams face a familiar tension: how to roll out new technologies and architectural standards quickly, without disrupting squads that are busy shipping features. Spotify’s mobile engineering group recently drove a multi-year migration initiative involving roughly 2,200 Android and iOS components and over 100 squads. The effort moved most of the mobile codebase to Bazel, Google’s open source build system, as part of a broader push toward isolated component development similar to backend microservices.
What follows are four recurring challenges the team hit, with the symptoms that signal each one, common missteps to avoid, and approaches that worked.
Defining the Scope
Large migrations often feel unbounded at the start. It’s hard to know where to begin when there’s a pile of tech debt, a wide range of use cases, and stakeholders who aren’t sure what’s expected of them. The instinct may be to enumerate every possible scenario before building anything — resist that. Likewise, don’t launch into a big migration without an estimated roadmap or a definition of success, and don’t approach stakeholders without clearly explaining their part.
Instead, ground the effort in a clear product brief: what you’re doing, why, and how. Start small with a proof of concept, validate it early, and move through alpha, beta, and GA lifecycles, layering in the most common use cases first. Revisit and reframe goals as needed — values change slowly, but alignment matters more than stubbornness. Know your audience’s mental models so you can speak to what’s relevant to them, and find early adopters who are willing to pilot the solution. Those initial collaborators often become advocates who help you scale later.
Scaling Up Across Squads
When a migration affects more than a hundred squads, progress can feel glacial. There’s a risk of concluding that large infrastructure changes are simply impossible in a big organization. That’s the wrong lesson. The right response is deliberate stakeholder management: identify which teams matter most, in priority order, and maintain regular contact through channels like Slack or email groups. Communicate progress constantly via newsletters and internal posts to keep the effort visible.
Invest in automation up front. If a refactoring step is repetitive, ask whether a script can handle it instead of each squad doing it by hand. Consider dedicated “spike weeks” where platform engineers partner with specific tribes to focus solely on migration work. Education programs also help teams learn new concepts and immediately apply them. And bake recommended engineering practices into onboarding so new hires start with the right habits rather than needing to unlearn them later.
Competing Priorities
Squads are rarely idle. When stakeholders are deep in high-priority bets, platform migrations fall to the bottom of the backlog. Don’t assume anyone fully grasps the importance of your work on their own — they have their own pressures. And don’t accept “we’re too busy on a higher-priority project” as a conversation ender. Metrics and goals also shouldn’t be treated as fixed; they should evolve as you learn more.
Keep stakeholders motivated by showing them the positive impact of the migration. Hold regular checkpoints, quarterly or more often, to measure pace against your targets. If things are moving too slowly, look for ways to adjust: streamline the process, add engineers, bring in contractors, or work with other tribes to get the work into their backlogs. Where possible, absorb the pain on the platform side and make the necessary changes centrally so squads can focus on user-facing value. Also watch for changes that contradict migration KPIs and open direct channels with the teams responsible to support them.
Maintaining Accountability
Without ownership, migrations drag on with no clear end in sight. It’s tempting to think alignment will magically persist across a long, multi-quarter effort, or that progress can’t be measured. Both assumptions are wrong.
Define a precise “definition of done” and use data to back it up. Trend graphs that show where you started and how fast you’re moving let you project a realistic completion date — and signal when you need to accelerate. Own the definition of success and communicate it often to keep people engaged. Build dashboards that track progress and impact; these not only demonstrate value but help you prioritize work at scale. Keep your roadmap current, since team members and stakeholders will change over time. An up-to-date timeline supports transparency, invites feedback, surfaces roadblocks, and ensures newcomers understand the arc of the migration.
Making Migration the Baseline
Migrations of this magnitude aren’t a one-off exception. As new technologies emerge, platform teams will repeatedly need to drive large-scale changes. Treating migration as an unusual burden forces disruption on squads every time. Instead, it should be considered a routine part of the software development lifecycle, alongside testing and design. The Spotify mobile team’s experience shows that with deliberate scoping, scaled communication, automated tooling, and clear accountability measures, even org-wide infrastructure changes can be executed smoothly for everyone involved.
