The tooling, review and release cost of each – and the team size where the answer flips.
Executive Summary
- The choice is a tooling and review cost, not a philosophical one - both models ship the same software.
- A monorepo trades per-repo autonomy for atomic cross-package changes, and needs build caching before it scales.
- The answer usually flips somewhere around the point where more teams depend on a package than own it.
Where teams usually start
Most teams arrive at this problem from the same direction: something that worked at one scale stopped working at the next, and the fix that used to be obvious no longer is. This guide walks the path we take with clients, in the order we take it.
The approach
Work in slices that can each ship on their own. A slice that cannot be deployed independently is not a slice, it is a phase – and phases are where migrations go to die.
What to measure
Decide the numbers that say it worked before you start, and instrument them first. Retrofitting measurement onto a finished migration tells you nothing about what the migration changed.
Conclusion
None of this is exotic. It is the discipline of small, reversible steps applied to a problem large enough that skipping the discipline is tempting.
