We migrated 40 services to a monorepo. Here is the honest ledger.

Eighteen months ago we moved a client from 40 independently-versioned services across separate repos into a single monorepo, as part of a broader platform rebuild. We tracked the costs and the benefits deliberately from day one, because migrations like this are usually sold as an unambiguous win, and ours was not.

The genuine wins

Cross-service refactors that used to require coordinating six separate pull requests and a release calendar now ship as one commit. Dependency drift, previously a constant low-grade problem, effectively disappeared because there is only one version of everything to reason about.

The costs nobody mentioned to us beforehand

CI time for the full test suite grew from under 4 minutes per service to 22 minutes for the whole repo, before we invested in selective test running based on changed paths. That investment took three weeks we had not budgeted.

Build tooling that assumed one service per repository (parts of our deployment pipeline, some IDE integrations) needed real rework, not configuration. This was the single most underestimated line item in our original migration plan.

Where we landed, honestly

• Deploy frequency per service is roughly unchanged; the monorepo did not make releases faster on its own.

• Time to resolve cross-service bugs dropped noticeably — engineers stopped needing repo access requests to even see the other side of an integration.

• New engineer onboarding time improved because there is one place to clone and one set of conventions, not forty.

If your services are genuinely independent and rarely change together, we would not recommend this migration; the tooling cost is real and the benefit will be marginal. If cross-service changes are a weekly occurrence, as they were for this client, it was worth the three months it took.