Monorepo Migrations:
How to Move (and What It Will Cost)
Migration in both directions is common and well-documented. The cost varies enormously: a web-stack polyrepo can consolidate in a weekend; 450 JVM services took two years to feel the win. Here is how to tell which applies to your team.
Four Questions Before You Start
What is the real pain?
If the pain is code sharing, a private npm registry might be cheaper. If it is atomic cross-service changes weekly, that is a monorepo trigger. If it is slow CI, that might be a build script problem, not a repo layout problem.
How many services, what languages?
JS/TS only + under 30 services = weekend project with Turborepo or Nx. Polyglot + 50+ services = multi-month Bazel or Pants project. Language mix is the most underestimated variable.
What does your CI look like today?
A monorepo migration almost always requires a full CI rewrite. If you have 40 separate CI pipelines, unifying them into one intelligent pipeline (Nx affected, Turbo filter) is as much work as the repo consolidation.
What is your deployment cadence?
Teams with fully independent per-service deployment cadences sometimes find monorepo makes deployments harder, not easier. Monorepo is strongest when multiple services need to ship together frequently.
Migration Guides
Polyrepo to Monorepo
The 8-step migration playbook. git subtree + tool setup + CI rewrite + cutover pattern. Real stories from Proton and Cash App.
Read the playbook →Monorepo to Polyrepo
When and how to split. Acquisition, spinout, regulatory boundaries, scale failures. git filter-repo extraction playbook.
Read the guide →Migration Cost (Real Numbers)
Proton: Saturday cutover. Cash App: ~450 services, 2 years. Aggregate CI build time improvement data. All cited to source.
See the numbers →