Rewrite, hybrid or micro-frontends: how to choose

There is no single right way to leave a legacy frontend. The right path depends on the size of the app, the number of teams and how much risk you can take. Here is how to decide.

The three paths

• Rewrite. Build the app again on modern Angular, then switch over once.
• Hybrid migration. Old and new frameworks run in the same app; screens move one at a time.
• Micro-frontends. The app is split into independently built and deployed parts, composed by a host. Each team migrates and ships its own part.

They are tools for different situations, and large migrations often combine them.

The criteria that actually matter

1. Size of the app. Count screens and modules; lines of code say less. Ten screens and a hundred screens are different problems.
2. Number of teams. One team can coordinate in a stand-up. Five teams sharing one deploy cannot.
3. Release coupling. If every release needs everyone's sign-off, the frontend architecture is already a bottleneck.
4. Risk tolerance. A back-office tool and a customer-facing revenue product can't afford the same failures.
5. Roadmap pressure. Can feature work stop for three months? Almost never.
6. Test coverage. Without tests, every big switch-over is a bet.
7. Budget shape. One large upfront payment, or phases that can be approved one at a time?

Rewrite

Best for: small apps (roughly under ten screens), a single developer or a small team, low integration complexity.

Why it works there: the result is clean, there is no compatibility layer to maintain, and the whole thing takes weeks rather than months.

Why it fails elsewhere: feature work freezes; the new app has to reach parity with years of undocumented behavior before anyone can use it; the switch-over is a single high-risk event; and if priorities change midway, you are left with two half-products. Rewrites also tend to become redesigns, which doubles the scope.

Hybrid migration

Best for: mid-size apps owned by one team, where the product has to keep evolving during the migration.

Why it works: both frameworks run inside one application, so every screen can be migrated, released and rolled back on its own. Users never notice a switch-over. The team keeps shipping. You can stop after any phase and still have a working product.

Costs: a compatibility layer that must be set up well (shared session, routing coexistence, shared services), a larger bundle during the hybrid phase, and engineering discipline to actually delete the old code as you go. A hybrid that lives forever is the failure mode here.

See the step-by-step in How to migrate AngularJS to Angular without downtime.

Micro-frontends

Best for: large platforms where several teams own different business areas and need to release independently.

Why it works: a host application handles routing, login and the shared layout, and loads each area at runtime. Each team has its own repository, its own pipeline and its own release schedule. A migration can then proceed area by area, at each team's pace, without a platform-wide freeze.

Costs, and they are real: shared infrastructure (host, module loading, versioning), a shared design system so the product still looks like one product, cross-team contracts for navigation and events, and performance work to keep several bundles fast. For a single team, all of this is cost without benefit.

Side by side

Mixed strategies are normal

The most common real-world plan for a large platform is: micro-frontends across business areas, and a hybrid migration inside each area. Small isolated tools next to the platform get rewritten outright. The architecture decision is made per area.

Seven questions to ask before deciding

1. How many screens does the app have, and how many are actually used?
2. How many teams change the frontend, and how often do they block each other?
3. Can the product roadmap tolerate a feature freeze? For how long?
4. Which flows would hurt most if they broke for an hour?
5. Do we have tests for those flows?
6. Do we need the option to stop after a first phase?
7. Who will own the compatibility layer or the host, and for how long?

A rule of thumb

Small and isolated: rewrite. Medium and one team: hybrid. Large and many teams: micro-frontends, with hybrid inside. When in doubt, run a one- or two-week assessment before committing budget. Choosing the wrong path is far more expensive than two weeks of analysis.