Angular Monolith to Federated Frontends
A comprehensive guide to migrating a 150K-line Angular monolith to Module Federation microfrontends with mixed framework support.
Executive Summary
A financial services company's Angular monolith had 150K lines of code, 30-minute builds, and 12 teams blocked by merge conflicts. Using Angular's Module Federation support, they decomposed it into 12 federated frontends over 12 months, allowing teams to migrate to React incrementally. Build time dropped to 8 minutes, and teams gained framework independence.
Why Migrate from Angular Monolith
The Angular monolith was slowing down 12 teams. Builds took 30 minutes, deployments required full regression testing (6 hours), and teams couldn't adopt React for new features without a complete rewrite.
- → 30-minute build time (developers waiting 2+ hours daily)
- → 6-hour regression test suite for every deployment
- → Inability to adopt React (blocking modern features)
- → High developer turnover (Angular skills scarce)
Angular Migration Readiness
The team spent 2 months preparing: upgrading to Angular 13 (Module Federation support), building the shell application, and establishing shared authentication and state patterns.
- • Angular 13+ for Module Federation support
- • Shell application (host) with routing
- • Custom Elements (Angular Elements) for React interop
- • Event bus (RxJS Subject) for cross-federation communication
- • CI/CD pipeline for federated module deployment
Angular Monolith Assessment
The monolith had 150K lines of TypeScript, 300 components, 50 NgRx stores, and 20 feature modules. The biggest bottlenecks were the trading dashboard (complex, high-traffic) and the reporting module (low traffic, good candidate for pilot).
Technical Debt
- • 50+ NgRx stores with duplicated selectors (maintenance nightmare)
- • 30-minute production builds (unoptimized Angular CLI config)
- • No module boundaries—any feature could import any component
- • Mixed Angular versions (9 → 12 migration incomplete)
Risks
- • Angular-to-React interop performance overhead
- • Shared NgRx state across federated modules
- • Federated module version mismatches (Angular 12 vs 13)
- • Team resistance to learning both Angular and React
Target Federated Frontend Architecture
The target had 12 federated modules: shell (Angular host), auth (Angular), trading-dashboard (Angular), reporting (React), settings (React), analytics (React), etc. The shell loaded federated modules at runtime via Module Federation.
12-Month Angular Migration Plan
Step 1: Phase 1: Foundation (Months 1-3)
Upgraded to Angular 13, built shell application, established Module Federation config, trained teams on microfrontends.
Step 2: Phase 2: React Pilot (Month 4)
Extracted reporting module as first React federated module—proved React interop worked.
Step 3: Phase 3: Angular Modules (Months 5-8)
Extracted auth, settings, and analytics as Angular federated modules.
Step 4: Phase 4: Core Trading (Months 9-12)
Extracted trading dashboard (most complex) as federated module—final cutover.
State Management Migration
The team replaced NgRx global store with event bus for cross-module communication. Each federated module maintained its own local state (NgRx within Angular modules, Redux within React modules).
- • Event bus (RxJS Subject) for cross-module events (user logout, cart update)
- • Local state only within each federated module (no shared NgRx stores)
- • SessionStorage for user authentication and preferences
- • Event replay for modules loaded after events occurred
Common Angular Microfrontend Mistakes
Sharing NgRx store across federated modules
Impact: Action collisions and state corruption (weekly production bugs)
Prevention: Event bus instead of shared store; local state only
Not upgrading Angular version before migration
Impact: Module Federation unavailable; migration blocked for 3 months
Prevention: Upgrade to Angular 13+ as first step
Overusing Angular Elements for React components
Impact: Performance overhead (50ms per component instantiation)
Prevention: Use React for entire modules, not individual components
No version strategy for Angular dependencies
Impact: Incompatible Angular versions crashing shell (Angular 12 vs 13)
Prevention: Single version of Angular shared across all modules
Success Metrics for Angular Migration
Who Should Lead Angular Microfrontend Migration
Recommended Roles
Required Experience
- • Successfully led 1+ Angular microfrontend migration
- • Deep expertise in Module Federation and Webpack 5
- • Experience with Angular Elements and custom elements
- • Cross-framework integration (Angular + React)
Related Roles
Frequently Asked Questions
- Can Angular and React microfrontends share the same DOM?
- Yes, via Angular Elements wrapping React components. Each microfrontend has its own root element; the shell mounts them dynamically.
- How do you handle routing across Angular and React modules?
- Shell handles top-level routing; each module handles its own nested routes. Module Federation loads module when route matches.
- What about bundle size with Angular and React together?
- Module Federation shares common dependencies (zone.js, React). Initial bundle increased from 500KB to 800KB (acceptable for functionality gain).