From Legacy Monolith to Micro-Frontends: How a B2B SaaS Platform Cut Deployment Time by 78%

# From Legacy Monolith to Micro-Frontends: A B2B SaaS Transformation ## Overview ShipFlow, a mid-sized B2B logistics SaaS platform, faced a familiar scaling problem in 2023. What started as a single Angular 9 application in 2019 had, over years of rapid feature growth, bloated into a 1.2-million-line monolith. Teams of 40+ engineers shared one deploy queue. A single failed regression test could block the entire weekly release. Hotfixes for critical customer incidents often required hours of coordination because no team had full ownership of any functional domain. The executive mandate was clear: restore engineering velocity without platform-wide rewrites, and do it while keeping the product stable for 3,000+ enterprise customers. The solution twelve months later is a hybrid micro-frontend architecture running on Azure Container Apps with decentralized CI/CD pipelines, per-team deployment autonomy, and a 78% reduction in end-to-end deployment time. This case study documents the full journey—from the diagnosis and pilot program through to production rollout and measurable outcomes. --- ## Challenge ### The Monolith Problem By early 2023, ShipFlow’s front-end architecture had reached a breaking point. **Deployment bottlenecks.** The team ran a single weekly deploy every Monday at 10 AM. Merge conflicts were frequent, and the integration-test suite took 45 minutes. If a team needed a hotfix mid-week, it required an off-cycle release that affected all customers and demanded manual coordination across five squads. **Code ownership confusion.** Feature folders in the monolith were loosely mapped to business domains—"Customer", "Orders", "Tracking", "Settings"—but in practice, any engineer could touch any folder. This created an invisible dependency graph: changing a shared UI component could break three unrelated features. **Scalability ceiling.** The application bundled over 200 npm packages. Bundle analysis showed the main chunk alone weighed 2.8 MB gzipped. First-time load times in emerging markets regularly exceeded 12 seconds, driving up churn in the Asia-Pacific segment. **Inability to modernize incrementally.** The team wanted to introduce modern tooling—ESBuild-based bundling, better test isolation, per-domain routing—but each effort required application-wide changes. The risk/reward ratio was too high for incremental effort. ### Organizational Pressure Engineering leadership had tried to address the problem twice before. In 2021, a greenfield rewrite in Next.js was abandoned after six months because the scope was too large and business requirements kept evolving. In 2022, a "feature flags for everything" strategy helped decouple some releases but didn’t solve the fundamental coupling in the codebase. By late 2022, the Board’s quarterly product review noted that competitor platforms were shipping AI-driven features twice as fast, and ShipFlow’s engineering Director was put on a performance improvement plan. --- ## Goals The remediation plan was scoped into four concrete goals: 1. **Deployment Autonomy.** Each of the six product squads should be able to deploy their module independently, without coordinating with other teams. 2. **Reduced Cycle Time.** Measurable improvement to deploy lead time. Target: cut Monday-only weekly deploy to multiple deploy-capable teams. 3. **Improved End-User Performance.** Reduce first-load time for key dashboards below 4 seconds for 90% of global users. 4. **Zero Major Disruption.** The migration had to preserve existing functionality for all customers. No big-bang cutovers, no forced browser updates, no customer-facing regressions. --- ## Approach After evaluating shell, single-spa, and a homegrown iframe approach, the team chose **Angular Module Federation** (via `@angular-architects/module-federation`) as the primary integration mechanism. The decision was based on three factors: - **Incremental adoption.** Module Federation allows existing Angular applications to load remote modules at runtime without rewriting the entire app. - **Shared dependency model.** Common libraries (Angular core, RxJS, NgRx) stay loaded in the host shell, so remote modules don’t pay a double-bundle penalty. - **Team familiarity.** Every squad already knew Angular. Introducing a new framework like React or Qwik would have required retraining and slowed adoption. ### Pilot First The team defined a three-month pilot with two constraints: (1) only the "Customer Profile" module would be extracted, and (2) the pilot team would own 100% of the migration from architecture to production deployment. Critical success criteria for the pilot: - Profile module loads independently via Module Federation without altering the host’s bundle size materially. - Customer Profile squad can deploy profile changes on their own CI/CD pipeline. - No increase in customer-facing error rates. --- ## Implementation ### Step 1: Establish the Host Shell Before any remote modules, the team built a lightweight **host shell** application—a stripped-down Angular 15 app that acts as the orchestrator. It handles: - Routing between local and remote modules - Shared state initialization - Authentication token propagation - Analytics and error boundary capture The shell is intentionally small (approximately 150 kB gzipped). It is deployed independently on every commit to `main`, but it contains no product features—only layout chrome, navigation, and integration logic. ### Step 2: Extract Profile Module (The Pilot) The Customer Profile squad moved their codebase into a separate repository. They set up: - An Angular 15 remote configured with `@angular-architects/module-federation`. - A dedicated Azure DevOps pipeline that builds the remote module and publishes it as a versioned static asset on Azure Blob Storage. - A deployment schedule decoupled from the monolith’s Monday releases. To handle data dependencies, the team introduced a **domain event contract**: the host shell exposes a lightweight facade service via Angular dependency injection that the remote module consumes. This avoided direct coupling between the remote module and the monolith’s data layer. ### Step 3: Migrate Shared Dependencies The biggest technical risk in Module Federation is duplicate framework loading. ShipFlow’s solution was an explicit **shared library boundary**: - Angular, RxJS, and NgRx are loaded only by the shell and shared via `singleton: true`. - UI component library `@shipflow/ui` is published as a scoped npm package, versioned semantically, and bundled separately from business logic. - Each remote module declares what it requires; the shell provides the runtime. The team also upgraded the webpack configuration to use `ModuleFederationPlugin`’s `remotes` array and pinned remote versions in the shell’s manifest to prevent accidental breaking changes. ### Step 4: Build Per-Team CI/CD Pipelines Each squad now has its own Azure DevOps pipeline configuration. The pipeline stages are: 1. **Lint & Unit Test** (changes in the remote module only) 2. **Build Remote Bundle** (produces a versioned `.js` + `.css` artifact) 3. **Publish to Azure Blob Storage** (with content-hash-based filenames for cache busting) 4. **Smoke Test** via Cypress against a staging environment 5. **Production Deploy** (triggers automatically on merge to `main`; updates the remote version in the shell’s config) Because the remote module is versioned and the shell fetches it at runtime, teams do not need shell deploy approval to publish a new remote version. The shell loads the new module on the next user navigation, and fallback behavior is handled gracefully through the shell’s error boundary. ### Step 5: Roll Out Remaining Modules Armed with the pilot’s success metrics, the team created a **module extraction playbook**—a documented recipe with checklists, review gates, and rollback triggers. Squads extracted the following modules in sequence: - Order Management (Month 4) - Shipment Tracking (Month 6) - Analytics Dashboard (Month 8) - Admin Console (Month 10) During each extraction, the team ran Chaos Monkey tests to verify that a failure in any remote module would not crash the host shell. The result: customers saw nothing but a temporary "retry" toast on rare failure events. --- ## Results ### Deployment Velocity The most dramatic improvement was in deployment frequency. | Metric | Before (Monolith) | After (Micro-Frontends) | Change | |--------|-------------------|-------------------------|--------| | Deploys per week | 1 | 18–24 | +1,800–2,300% | | Average deploy lead time | 2.5 hours | 34 minutes | −86% | | Hotfix deploy time | 4–8 hours | 12 minutes | −94% | | Failed deploy recovery | 45–120 minutes | 8 minutes | −82% | These numbers were validated over a six-week observation period after the final module migration. ### End-User Performance First-load performance improved significantly due to per-module code splitting. | Metric | Before | After | |--------|--------|-------| | Average first-load time (global) | 9.8 sec | 3.2 sec | | Bundle size (gzipped) | 2.8 MB | 780 kB (shell) + 3 × 220 kB (common modules) | | Lighthouse Performance score | 38 | 72 | | Customer-reported page-load complaints | 12/week | 2/week | ### Business Impact - **Error rate.** Customer-reported front-end errors dropped from 1.8% of sessions to 0.4%. - **Developer satisfaction.** The internal developer survey showed engineer NPS rising from +18 to +64 in one year. - **Feature shipping.** Product teams reported a 3× increase in shipped features per quarter. The AI-powered route optimization feature—previously blocked by monolith release constraints—shipped three months earlier than planned. --- ## Key Technical Decisions ### Why Not single-spa? The team actively evaluated single-spa but rejected it primarily because ShipFlow’s entire front-end was Angular. single-spa’s strongest value is in framework-agnostic environments. With `@angular-architects/module-federation`, the team got native Angular integration with far less custom glue code. ### Why Module Federation Over iframes? iframe-based isolation promised security boundaries but introduced UX friction: scroll state preservation, event delegation bugs, and symptom-laden red loading indicators. Module Federation provides logical isolation via JavaScript module boundaries while keeping a unified DOM, which preserved the existing UX exactly. ### Why Not Rewrite Everything in React or Next.js? A greenfield rewrite was fiscally irresponsible given the size of the existing codebase and the team’s deep Angular expertise. The incremental approach kept the product stable and allowed business-critical features to ship throughout the migration. --- ## Lessons Learned ### 1. Start With a Pilot, Not a Plan The pilot taught the team more in three months than six months of pre-migration planning. Specifically, the pilot exposed an unanticipated race condition around NgRx store hydration that the team solved before it became an issue at scale. A planning-only approach would have missed this entirely. ### 2. Automate the Rollback Path During the Analytics Dashboard migration, a version-mismatch bug caused silent data display corruption in production. The team discovered it 90 minutes after deploy. Because each remote module is versioned independently and the shell loads the previous version automatically on error, the rollback was a configuration flip—not a code revert and redeploy. ### 3. Buy-In Requires Visible Progress Executive sponsors began skeptical when the pilot estimated three months. When Squad 1 deployed their module on schedule and advertised a 15% cycle-time improvement within days, other squads started asking when their turn would come. Peer pressure became a more powerful adoption driver than management mandates. ### 4. Shared Dependencies Are a Design Problem, Not Just a Build Problem The team initially treated shared library drift as a CI issue. It quickly became apparent that without architectural guardrails—like publishing `@shipflow/ui` as an immutable, versioned library—teams would inadvertently introduce incompatible component contracts. Investing in a small "framework team" that owned shared libraries and the Module Federation configuration paid for itself in reduced cross-team coordination. ### 5. Don’t Chase Perfection The final architecture intentionally left the legacy monolith in place for four modules that were stable and low-churn. These modules (Settings, Billing, Notifications) remain today within the monolith. Trying to extract them would have required six more months of engineering time with minimal business value. The pragmatic approach—extract what hurts, leave what works—produced the best ROI. --- ## Conclusion The ShipFlow transformation is not a universal prescription, but a concrete example of how an engineering team can regain control of a runaway front-end platform without burning the existing codebase to the ground. By combining Angular Module Federation with disciplined domain extraction, shared-library contracts, and a pilot-first methodology, the team achieved measurable improvements in deployment velocity, end-user performance, and developer satisfaction. The architecture now in production is not "done" in the architectural sense—it is in fact an ongoing journey as the company continues to extract newer services. But after eighteen months, ShipFlow can ship features on demand, recover from failures in minutes, and invest engineering time in customer value rather than merge-queue politics. That is the real win. --- *Case study prepared by Webskyne editorial. Details updated as of Q2 2026.*