Summary
The Strangler Fig pattern lets you migrate a legacy frontend without a big-bang rewrite: a router or proxy sits in front of both apps and forwards each path to whichever app owns it. New routes go to the modern app; old routes stay on the legacy app until you port them. The surface exposed to users never changes.
Jump to the interview angleStrangler Fig
A strangler fig vine grows around an existing tree, eventually replacing it. Applied to frontends, a proxy layer — Next.js rewrites, a CDN rule, or a reverse proxy — routes each URL to one of two apps in parallel: the legacy app and the replacement.
Migrate one route at a time. The legacy app never knows it lost a path. Once every route is migrated, remove the proxy and shut it down.
Multi-Zones is the Next.js multi-app variant: each zone is a separate Next.js deployment with its own assetPrefix. The primary zone proxies others via rewrites — used when teams own distinct path prefixes and need independent deployments.
Route-by-route migration
- 1
Stand up the new app with a fallback rewrite
Deploy the new Next.js app with a
fallbackrewrite pointing to the legacy origin. All traffic passes through to legacy — no visible change yet. - 2
Build pages in the new app
Each page file you add automatically shadows the fallback. Next.js checks its own filesystem before running fallback rewrites — no rule update needed.
- 3
Track progress objectively
Compare the
next buildroute manifest against the legacy sitemap. The ratio gives a percentage complete. Set a hard deadline or migration stalls. - 4
Cut over and decommission
Once every route is migrated, remove the proxy config and shut down the legacy origin. Rollback at any point is a one-line rewrite change.
Next.js fallback rewrite to legacy origin
Add this to next.config.js in the new app. Owned pages shadow the fallback automatically.
// next.config.js
module.exports = {
async rewrites() {
return {
// Checked only after Next.js finds no matching page
fallback: [
{
source: "/:path*",
destination: `${process.env.LEGACY_ORIGIN}/:path*`,
},
],
};
},
};Add a page file and that route is migrated — no rule update needed. Remove the fallback config once legacy is decommissioned.
Multi-Zones: two gotchas
Use <a> not <Link> for cross-zone navigation — Next.js tries client-side routing across zone boundaries and fails. Set assetPrefix in each zone or zones collide on /_next/static paths.
Interview angle
Interviewers ask how you'd migrate a large legacy frontend without a big-bang rewrite. Name the Strangler Fig pattern, describe the proxy/rewrite layer, and explain how fallback rewrites in Next.js let new pages shadow old routes without config changes.
Soundbite: "A fallback rewrite makes every new page file a migration commit — no rule to update, just delete the legacy route when you're done."
Key terms
- Strangler Fig
- Migration pattern where new code wraps and gradually replaces a legacy system route by route.
- fallback rewrite
- Next.js rewrite checked last — after filesystem and dynamic routes — used to proxy unported paths to a legacy origin.
- Multi-Zones
- Next.js approach for running multiple independent Next.js apps under one domain, each owning distinct path prefixes.
- assetPrefix
- Next.js config option that namespaces a zone's `/_next/static` assets to prevent collisions with other zones.
- big-bang rewrite
- Replacing an entire app in one release; high risk because the new app must be feature-complete before any cutover.