Migrating Legacy Systems to Next.js for Ultimate Speed

Legacy systems don't die — they get migrated. After running multiple PHP-to-Next.js migrations in production, here's what actually works.

The strangler fig pattern

Don't do a big-bang rewrite. Use the strangler fig: route new features to Next.js while legacy handles existing routes. Migrate page by page behind a reverse proxy (nginx or Vercel rewrites).

Step 1: Inventory first

Before writing a line of code, document every route, every API call, every cron job, every session dependency. Missing one will bite you at 3am on launch day.

Step 2: Shared auth layer

Build a shared authentication service both systems trust. JWT tokens with the same secret, or session cookies with the same domain. Users should never know they're on different systems.

Step 3: Database first, UI second

Migrate your data model and API layer before touching the UI. A stable API boundary lets the Next.js frontend evolve independently.

Step 4: Incremental cutover

Route 5% of traffic to Next.js on day one. Watch error rates. Increase to 25%, 50%, 100% over weeks. This is the most important step — it gives you a rollback path.

Performance gains

Typical results: TTFB drops 60-80%, Core Web Vitals improve, and server costs go down because Next.js handles load more efficiently than PHP at scale. The harder-to-measure win is dev velocity — new features ship faster when you're not fighting Magento.