We are migrating our monolithic frontend to a micro-frontend architecture.

A safe way to approach this is as an incremental extraction, not a big-bang rewrite. The strangler-fig pattern is specifically intended to let the old and new systems coexist while routes/capabilities move gradually.AWS Documentation+1

Suggested target architecture

                    ┌──────────────────────┐
                    │       Web / CDN      │
                    └──────────┬───────────┘
                               │
                     ┌─────────▼─────────┐
                     │   Shell / Host    │
                     │                   │
                     │ • routing         │
                     │ • auth bootstrap  │
                     │ • layout          │
                     │ • error handling  │
                     └───────┬───────────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
        ┌─────▼─────┐  ┌─────▼─────┐  ┌─────▼─────┐
        │  Catalog  │  │   Cart    │  │  Profile  │
        │  Remote   │  │  Remote   │  │  Remote   │
        └───────────┘  └───────────┘  └───────────┘
              │
        ┌─────▼──────────────────────────────┐
        │       Existing Monolith            │
        │  remaining routes/features          │
        └────────────────────────────────────┘

A shell/host owning top-level routing and lazily loading remote applications is a common composition model; Module Federation is one established implementation option.AWS Documentation+1

Migration sequence

1. Map the monolith by business capability, not by technical folders.

• Catalog
• Search
• Cart
• Checkout
• Orders
• Account/Profile
• Admin, etc.

2. Identify ownership and boundaries. A micro-frontend should correspond to something a team can genuinely own and deploy independently. AWS similarly recommends clearly encapsulated responsibilities and explicit integration contracts.AWS Documentation
3. Introduce the shell while keeping the monolith intact. Initially, almost every route can still resolve to the monolith.
4. Extract one relatively self-contained capability. For example, /account/* might become the first remote while /checkout/*, /orders/*, etc. remain in the monolith.
5. Route the extracted path to the remote.

/account/*   → Account MFE
/catalog/*   → Monolith
/cart/*      → Monolith
/checkout/*  → Monolith

1. Run both systems in production. Keep the old implementation available long enough to make rollback straightforward.
2. Measure and stabilize. Watch error rates, page-load performance, deployment failures, navigation behavior, and cross-MFE integration issues.
3. Repeat extraction one domain at a time until the monolith has shrunk sufficiently to retire.

This incremental approach avoids making the migration itself a single high-risk release.AWS Documentation+1

The most important architectural rule

Don't recreate the monolith as a distributed global state system.

Avoid having every MFE depend on:

global Redux store
global React context
shared business objects
direct imports between MFEs

Prefer explicit contracts:

MFE A ──event──> Shell
MFE A ──API────> Backend
MFE B ──event──> Shell
URL ────────────> shared navigation state

For example:

window.dispatchEvent(
  new CustomEvent("cart:item-added", {
    detail: { productId, quantity }
  })
);

The exact mechanism can vary, but the principle is to share signals and contracts rather than internal implementation details.

Be conservative with shared dependencies

Share truly foundational dependencies such as the framework runtime when necessary, but don't turn every internal library into a shared runtime dependency. Shared dependencies introduce versioning and compatibility constraints; AWS explicitly calls out dependency management and versioning as important governance concerns.AWS Documentation

I'd establish a small platform contract covering:

• React/framework version
• TypeScript target
• authentication interface
• routing conventions
• design tokens
• event naming/schema
• API conventions
• error boundaries
• observability
• security/CSP
• deployment and rollback rules

What I would not extract first

I'd generally avoid starting with the header, navigation, design system, or authentication. They tend to have extremely high coupling and become dependencies for almost everything else. An incremental migration guide similarly recommends extracting self-contained capabilities before the heavily shared layer.Micro-Frontend Guide

A useful first candidate has:

high business ownership
+ clear route boundary
+ few inbound dependencies
+ limited shared state
+ meaningful deployment value

A practical migration plan

The key success criterion isn't simply "we have 10 micro-frontends." It's that teams can independently change, test, deploy, monitor, and roll back their domain without requiring coordinated releases. Micro-frontends also add real complexity—dependency coordination, integration testing, communication, and performance overhead—so the migration should demonstrate that the organizational benefits outweigh those costs.AWS Documentation

If you tell me your frontend stack (React/Angular/Vue/Next.js/etc.), current build system, number of teams, and whether you need SSR, I can turn this into a concrete migration architecture and phased implementation plan.

That’s a substantial architectural migration, and the safest approach is usually incremental strangler migration, rather than rewriting the frontend all at once.

A practical target architecture looks like:

                    ┌──────────────────────┐
                    │       Shell / Host   │
                    │ routing · auth · UX  │
                    └──────────┬───────────┘
                               │
          ┌────────────────────┼────────────────────┐
          ▼                    ▼                    ▼
     ┌─────────┐          ┌─────────┐          ┌─────────┐
     │ Account │          │ Orders  │          │ Reports │
     │   MFE   │          │   MFE   │          │   MFE   │
     └─────────┘          └─────────┘          └─────────┘
          │                    │                    │
          └────────────────────┼────────────────────┘
                               ▼
                       Shared API layer

Recommended migration strategy

1. Define boundaries around business capabilities, not technical layers. For example, Account, Orders, and Reporting are better boundaries than Header, Forms, or Components. Good boundaries minimize cross-MFE communication and dependencies.AWS Documentation+1
2. Keep the existing monolith running while introducing a shell. Have the shell route some paths to the existing application and others to newly extracted micro-frontends. This gives you a reversible migration path instead of a risky cutover.Micro-Frontend Guide
3. Choose the first extraction for low coupling. A self-contained settings page, admin area, help section, or similar capability is generally a better migration candidate than the global header or a highly interconnected checkout flow.
4. Make each MFE independently buildable and deployable. A common client-side approach is Module Federation, which supports independently compiled/deployed modules and dependency sharing.module-federation.io

Other viable approaches include single-spa, Web Components, import maps, and server/edge composition; the right choice depends heavily on your current framework and deployment model. AWS Documentation 5. Keep the shell thin. The shell should generally own things such as:

• top-level routing
• authentication/session integration
• global navigation
• application-level error handling
• shared visual conventions

Business logic should remain inside the MFE that owns the business capability. 6. Avoid creating a distributed global state store. Shared Redux/MobX/etc. state can recreate the coupling you're trying to eliminate. Prefer URL state, APIs, and asynchronous events/custom events for cross-MFE communication. AWS Documentation AWS Documentation 7. Be extremely deliberate about shared dependencies. Sharing React, Angular, design-system packages, etc. can reduce duplication, but excessive runtime sharing creates version and deployment coupling. Establish explicit versioning and compatibility rules. AWS Documentation 8. Leave highly shared infrastructure until later. The header, navigation, and design system are tempting first candidates but are often among the most highly coupled parts of the application. Keeping them in the monolith initially can make the first extractions substantially easier.Micro-Frontend Guide

A useful migration sequence

Phase 0
Monolith
   │
   ▼
Phase 1
Monolith + Shell
   │
   ├── Existing routes ──► Monolith
   └── New route ────────► MFE #1
                              │
                              ▼
Phase 2
Shell
   ├── MFE #1
   ├── MFE #2
   └── Monolith
         │
         ▼
Phase 3
Shell
   ├── MFE #1
   ├── MFE #2
   ├── MFE #3
   └── Small remaining legacy surface
         │
         ▼
Phase 4
Shell + independent MFEs

The important part is that every extraction should produce a working production state. Don't wait until the entire monolith has been dismantled before deploying the new architecture.

The architectural contracts I'd establish first

Before extracting the first MFE, write down contracts for:

This is important because micro-frontends don't merely move complexity around—they add distributed-system complexity to the frontend. AWS's current guidance explicitly calls out additional integration, dependency-management, testing, coordination, and performance complexity.AWS Documentation+1

If you tell me your current stack—e.g. React + Webpack/Vite, Angular, Vue, Next.js, how many teams you have, and how the monolith is currently deployed—I can propose a concrete target architecture and phased migration plan, including the shell, routing, Module Federation setup, shared dependencies, CI/CD, and the first 2–3 extraction candidates.

That’s a substantial architecture change. A good migration strategy is usually incremental rather than a big-bang rewrite: keep the monolith running, extract one well-defined domain at a time, and progressively route traffic to the new micro-frontends. This is essentially the Strangler Fig approach.AWS Documentation+1

A practical migration plan

1. Map your current frontend

• Identify business domains/routes: e.g. catalog, checkout, account, orders.
• Document dependencies between domains.
• Identify shared state, APIs, authentication, design-system components, and routing.
• Map each domain to a clear team owner.

2. Choose the first extraction carefully Start with a domain that has:

• clear ownership,
• relatively few dependencies,
• an independently meaningful user journey,
• enough value to justify the migration.

Avoid starting with highly shared pieces such as the global header, authentication, or foundational UI libraries. 3. Introduce a shell

A useful target shape is:

                ┌─────────────────────┐
                │      Shell/Host     │
                │ routing / auth / UI │
                └──────────┬──────────┘
                           │
         ┌─────────────────┼─────────────────┐
         ▼                 ▼                 ▼
    Catalog MFE       Checkout MFE       Account MFE
         │                 │                 │
         └─────────────────┼─────────────────┘
                           ▼
                     Backend APIs

The shell should stay relatively thin. It can own top-level routing, authentication boundaries, layout, and composition rather than business logic. AWS's micro-frontend guidance similarly describes a shell that loads independently deployed remote modules. AWS Documentation 4. Run old and new code side-by-side

For example:

example.com/catalog/*   → Catalog MFE
example.com/checkout/*  → Monolith
example.com/account/*   → Monolith

Then later:

example.com/catalog/*   → Catalog MFE
example.com/checkout/*  → Checkout MFE
example.com/account/*   → Account MFE

A routing/proxy layer makes this coexistence possible and gives you a straightforward rollback path. Microsoft Learn 5. Define contracts before extracting

Be explicit about:

• API contracts
• routing/deep-link behavior
• authentication/session handling
• events between MFEs
• shared design tokens/components
• dependency versions
• error handling
• observability
• deployment and rollback

One important principle is to avoid turning your micro-frontends into a distributed monolith through a giant shared state store. Prefer stable APIs, URL state, and narrowly defined events. 6. Treat shared dependencies carefully

If you're using Module Federation, establish rules for shared dependencies early. Sharing everything can create version coupling; sharing too little can create unnecessary duplication. AWS specifically recommends standardized contracts and dependency/versioning strategies between independently evolving micro-frontends. AWS Documentation 7. Make every extraction reversible

A deployment should be able to switch:

/catalog → new MFE

back to:

/catalog → monolith

without rebuilding the entire application. Feature flags, routing configuration, manifests, or edge/proxy configuration can provide that control. 8. Measure the migration

Don't measure success simply by "number of micro-frontends." Track things such as:

• deployment frequency by team
• build/CI duration
• rollback time
• runtime JavaScript size
• page-load/Core Web Vitals
• cross-MFE failure rates
• dependency conflicts
• number of coordinated releases required

A sensible end state

The architecture should evolve roughly like this:

BEFORE

                 ┌─────────────────────┐
                 │   Frontend Monolith  │
                 │                     │
                 │ Catalog             │
                 │ Checkout            │
                 │ Account             │
                 │ Orders              │
                 │ Shared State        │
                 └─────────────────────┘

MIGRATION

                 ┌─────────────────────┐
                 │       Shell         │
                 │ routing / auth      │
                 └──────────┬──────────┘
                            │
             ┌──────────────┼──────────────┐
             ▼              ▼              ▼
        Catalog MFE    Checkout MFE    Monolith
                                        ├─ Account
                                        └─ Orders

END STATE

                 ┌─────────────────────┐
                 │       Shell         │
                 │ routing / auth      │
                 └──────────┬──────────┘
                            │
       ┌────────────┬───────┼────────┬────────────┐
       ▼            ▼       ▼        ▼            ▼
    Catalog      Checkout Account  Orders      Other
      MFE          MFE      MFE      MFE         MFE

The key architectural decision isn't actually Module Federation vs. another integration technology. It's finding boundaries that allow teams to own, test, deploy, and roll back capabilities independently. The technology should support those boundaries rather than dictate them.StackAuthority+1

If you tell me your current stack (for example React + Webpack/Vite, Angular, Next.js, etc.), number of teams, and roughly how your monolith is divided, I can turn this into a concrete target architecture + phased migration plan.

Absolutely. For a migration like this, I’d avoid treating “micro-frontends” as the goal. The goal should be independent ownership and deployment with controlled migration risk.

A strong approach is an incremental Strangler Fig migration: keep the monolith running, extract one business capability at a time, and route users between the old and new implementations. This avoids a risky big-bang rewrite.AWS Documentation+1

Recommended target architecture

                         ┌─────────────────────┐
                         │       Browser       │
                         └──────────┬──────────┘
                                    │
                              ┌─────▼─────┐
                              │   Shell   │
                              │ / Router  │
                              └─────┬─────┘
                                    │
              ┌─────────────────────┼─────────────────────┐
              │                     │                     │
        ┌─────▼─────┐         ┌─────▼─────┐         ┌─────▼─────┐
        │  Catalog  │         │ Checkout  │         │  Profile  │
        │    MFE    │         │    MFE    │         │    MFE    │
        └───────────┘         └───────────┘         └───────────┘
              │                     │
              └──────────┬──────────┘
                         │
                 ┌───────▼────────┐
                 │ Legacy Monolith │
                 │   (temporary)   │
                 └─────────────────┘

The shell owns things that genuinely need to be global—authentication/session bootstrap, top-level routing, error boundaries, telemetry, and perhaps the design-system foundation. Individual MFEs should own their business domain, UI, domain state, and deployment lifecycle.

Migration sequence

1. Map the monolith before splitting it

Identify:

• Business domains and routes
• Team ownership
• Dependencies between domains
• Shared state
• Shared UI components
• API dependencies
• Authentication/authorization boundaries
• Performance-critical paths
• Areas with few inbound dependencies

Don't start by asking “What should become a micro-frontend?” Ask “Where are the natural ownership boundaries?”

Prematurely choosing boundaries can create more coupling rather than less.AWS Documentation

2. Introduce a shell without migrating everything

Initially:

Shell
 └── Monolith

Then:

Shell
 ├── New Catalog MFE
 └── Monolith
      ├── Checkout
      ├── Profile
      └── Orders

Then progressively:

Shell
 ├── Catalog MFE
 ├── Checkout MFE
 ├── Profile MFE
 └── Monolith
      └── Orders

Eventually the monolith disappears.

This route-by-route approach is specifically suited to incremental modernization.Vercel+1

3. Pick the first extraction carefully

I'd choose something that is:

• Clearly owned by one team
• Relatively self-contained
• Valuable enough to validate the architecture
• Not deeply coupled to global state
• Easy to route independently
• Easy to roll back

I would not start with the header, navigation, global state, or another highly shared component. Those tend to have enormous coupling and provide little proof that independent deployment works.

4. Establish the integration contract

If you're using something such as Module Federation, define the contract before extracting several MFEs.

For example:

Shell owns:
  - Routing
  - Authentication bootstrap
  - Global error handling
  - Telemetry
  - Design-system primitives

MFE owns:
  - Domain routes
  - Domain UI
  - Domain state
  - Domain API interaction
  - Domain-specific tests

Communication:
  - Prefer URL parameters
  - Prefer explicit events for cross-domain interactions
  - Avoid shared mutable global state

Be particularly deliberate about shared dependencies such as React, React DOM, and routing libraries. Sharing them incorrectly can create runtime/version problems across independently deployed applications.Micro-Frontend Guide

The biggest architectural trap

Don't recreate the monolith as a distributed monolith:

MFE A ──┐
MFE B ──┼──► Global Redux Store
MFE C ──┤
MFE D ──┘

That's technically multiple applications but architecturally still one tightly coupled frontend.

Prefer:

          ┌───────────────┐
          │     Shell     │
          └───────┬───────┘
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
   Catalog     Checkout    Profile
    state        state       state

Cross-domain communication should be explicit and minimal.

Make every migration reversible

For each extracted domain, have:

                 ┌──► New MFE
Request ─► Router│
                 └──► Legacy

Initially, the legacy version remains available as the fallback. Keep it for at least a release cycle rather than deleting it immediately; that gives you a practical rollback path.Micro-Frontend Guide

Use feature flags/canary rollout where appropriate:

0%   → legacy
5%   → new MFE
25%  → new MFE
50%  → new MFE
100% → new MFE
       ↓
    remove legacy

Don't forget the operational side

Micro-frontends move complexity from the codebase into the runtime and organization. You'll need:

• Independent CI/CD pipelines
• Versioned MFE artifacts
• Runtime health checks
• Error boundaries
• Centralized logging/tracing
• Frontend performance monitoring
• Contract/integration tests
• Clear ownership/on-call responsibility
• Rollback capability
• Dependency/version governance

Otherwise you'll end up with independently deployable applications that are actually impossible to operate independently.

A sensible migration roadmap

Phase 1
Monolith
  ↓
Introduce shell + routing boundary

Phase 2
Shell + Monolith
  ↓
Extract one low-coupling domain

Phase 3
Shell + MFE + Monolith
  ↓
Standardize deployment, observability, contracts

Phase 4
Shell + multiple MFEs + shrinking monolith
  ↓
Remove migrated code and dependencies

Phase 5
Shell + MFEs
  ↓
Retire monolith

The key principle is “extract capabilities, not technical layers.” A business domain with clear ownership is usually a much better MFE boundary than something like “all forms,” “all shared components,” or “the React components folder.”

If you tell me your current stack (React/Angular/Vue, Webpack/Vite, monorepo/polyrepo, routing, state management, and how many teams), I can propose a concrete target architecture and step-by-step migration plan for it.

Otherwise you'll end up with independently deployable applications that are actually impossible to operate independently.

A sensible migration roadmap

Phase 1
Monolith
  ↓
Introduce shell + routing boundary

Phase 2
Shell + Monolith
  ↓
Extract one low-coupling domain

Phase 3
Shell + MFE + Monolith
  ↓
Standardize deployment, observability, contracts

Phase 4
Shell + multiple MFEs + shrinking monolith
  ↓
Remove migrated code and dependencies

Phase 5
Shell + MFEs
  ↓
Retire monolith

The key principle is “extract capabilities, not technical layers.” A business domain with clear ownership is usually a much better MFE boundary than something like “all forms,” “all shared components,” or “the React components folder.”

If you tell me your current stack (React/Angular/Vue, Webpack/Vite, monorepo/polyrepo, routing, state management, and how many teams), I can propose a concrete target architecture and step-by-step migration plan for it.

I'd choose something that is: