Skip to main content

Monorepo migration for 11 microservices

Overview

I led a frontend consolidation from 11 separate service repositories into one monorepo in a multi-team enterprise environment, while simultaneously modernizing core runtime and build tooling.

Context and constraints

  • 11 frontend services, 5 teams (about 25 developers), and fragmented shared libraries.
  • 33 total servers in the previous topology (production + development).
  • No automated regression test baseline before migration.
  • Teams required independent deployment and rollback capability per service.
  • Legacy dependency graph included mixed module formats and stale build assumptions.

Technical approach

I executed the migration incrementally, onboarding services one-by-one into the monorepo to keep delivery flow active and minimize blast radius.

I moved the build layer to Webpack 5 and resolved legacy compatibility gaps explicitly, including missing Node polyfills that older libraries expected implicitly. In parallel, I coordinated runtime upgrades to React 18 and Node 22 so modernization happened in one controlled window instead of repeated disruption cycles.

I standardized shared logic into internal workspace packages (packages/ui, packages/utils) and replaced ad hoc cross-repo reuse patterns. This reduced duplication and made dependency updates traceable inside one build graph.

For CI/CD, I replaced a sequential per-service execution model with parallelized build execution and cache-aware behavior, while preserving selective service deployment paths needed by separate teams.

Results

  • Infrastructure footprint reduced from 33 servers to 3.
  • Full build cycle reduced from about 90+ minutes to about 25 minutes.
  • Cached builds reduced feedback loop to several minutes.
  • Migration-related bug commits remained below 5% in the post-migration stabilization period.
  • All 11 services moved under one delivery model with shared package boundaries.

Trade-offs and risks

  • Bundle size temporarily increased before shared chunk optimization.
  • Yarn 1 workspace limitations remained and were tracked as phase-two technical debt.
  • Zero-test starting point increased rollout risk and required stricter manual verification.
  • Team retraining and process alignment consumed significant project bandwidth.

Stack

Monorepo, React 18, Node 22, Webpack 5, Turborepo, Jenkins, Yarn workspaces

Full story

Read the full engineering narrative here: /blog/monorepo-migration