Migrating PHP to React/Next.js: Strategies and Case Studies
When the PHP monolith slows down: migration to React/Next.js
Your Laravel site has started slowing down: INP over 300 ms, and adding a new page takes a week. We've encountered such projects dozens of times. Migrating to React/Next.js is not a framework change but an architecture rethink. Next.js with React Server Components (RSC) generates pages 2-3 times faster than pure PHP rendering and cuts TTFB in half. The migration pays for itself in 6-12 months through reduced hosting and development costs. Below are real strategies we've applied on 50+ projects. We guarantee preserving SEO positions during the move. Get a consultation — we'll evaluate your project in one day.
What problems does migration solve?
Performance. PHP generates HTML on the server per request, leading to high TTFB. Next.js with RSC serves static content and streams dynamic content. CLS improves thanks to server-side rendering.
Maintenance complexity. Blade templates mix logic and presentation. React with TypeScript and strict typing reduces bugs by 30% as per our measurements.
SEO issues. Client-side SPAs are poorly indexed. Next.js solves this with SSR and ISR. For example, an e-commerce store with 5000 products saw a 20% traffic increase after migration.
How to choose a migration strategy?
There are three approaches, and the choice depends on project size and acceptable downtime.
| Strategy |
Essence |
When to apply |
| Strangler Fig |
Gradual route replacement via Nginx |
Large projects, zero error tolerance |
| Big Bang |
Full rewrite in one deploy |
Small sites (<50 pages) |
| Hybrid |
Next.js frontend, PHP API |
When you want to preserve backend investments |
Strangler Fig — our favorite. We configure Nginx so new routes go to Next.js and old ones to PHP, eliminating downtime.
server {
server_name mysite.com;
# New routes → Next.js
location /blog/ {
proxy_pass http://nextjs:3000;
}
location /about {
proxy_pass http://nextjs:3000;
}
# Old routes → Laravel
location / {
proxy_pass http://laravel:8000;
}
}
How to prepare the project for migration
- Conduct a code audit: identify integration points, performance bottlenecks, N+1 queries.
- Choose a strategy: Strangler Fig for large projects, Big Bang for small ones.
- Set up infrastructure: Docker, CI/CD, separate environments.
- Implement gradually: test each route individually.
- Perform A/B testing and deploy.
Migrating business logic: Laravel → Zod + Prisma
One common mistake is copying validation "as is." In Laravel it's built via $request->validate, in React via Zod. We rewrite with TypeScript types in mind.
// До (Laravel)
// $request->validate([
// 'email' => 'required|email|unique:users',
// 'name' => 'required|min:2|max:255',
// ]);
// После (Zod + React Hook Form)
const schema = z.object({
email: z.string().email('Некорректный email'),
name: z.string().min(2).max(255),
});
Database queries also change. Eloquent queries with N+1 are replaced with Prisma includes.
// До (Eloquent в Laravel)
// User::where('active', true)->with('posts')->paginate(10);
// После (Prisma в Next.js API Route)
const users = await prisma.user.findMany({
where: { active: true },
include: { posts: true },
take: 10,
skip: (page - 1) * 10,
});
Templates: Blade → React components
A Blade loop template becomes a ProductCard component. This improves maintainability.
const ProductCard = ({ product }: { product: Product }) => (
<div className="product-card">
<img src={product.imageUrl} alt={product.name} />
<h3>{product.name}</h3>
<span>{product.price.toLocaleString('ru-RU')} руб.</span>
<Link href={`/products/${product.slug}`}>Подробнее</Link>
</div>
);
Authentication: PHP sessions → NextAuth
PHP sessions via Cookie are replaced with JWT tokens via NextAuth. For Laravel API we use Sanctum.
// Next.js: аутентификация через Laravel Sanctum
import NextAuth from 'next-auth';
import Credentials from 'next-auth/providers/credentials';
export const { auth, handlers } = NextAuth({
providers: [
Credentials({
async authorize(credentials) {
const res = await fetch(`${process.env.LARAVEL_URL}/api/auth/login`, {
method: 'POST',
body: JSON.stringify(credentials),
headers: { 'Content-Type': 'application/json' },
});
if (!res.ok) return null;
return res.json();
},
}),
],
});
What's included
We deliver a complete package:
- Architecture and API documentation
- Access to repository, CI/CD, hosting
- Team training on Next.js
- One month of post-deployment support
- SEO preservation guarantee (100% redirects, zero 404s)
Timelines and cost
Cost is calculated individually after an audit. Indicative timelines:
| Site type |
Strangler Fig |
Big Bang |
| Corporate (10–20 pages) |
4–8 weeks |
3–6 weeks |
| Blog/portal (50–200 pages) |
8–16 weeks |
6–12 weeks |
| E-commerce store |
3–6 months |
2–4 months |
| Complex portal |
6–12 months |
Not feasible |
Case study
An e-commerce site on CodeIgniter (2000 products) migrated using the Strangler Fig pattern. We first rewrote the catalog, then the cart, then the user account. Result: LCP dropped from 4.2 s to 1.1 s, traffic increased by 25%. The whole process took 4 months.
Why trust us with the migration?
Over 8 years of experience in React/Next.js migrations. Certified engineers (React, Next.js, AWS). 50+ successful projects. We guarantee your site won't lose search rankings. Contact us to get a detailed audit of your PHP project and cost estimate.
More about our experience
Over 8 years we've performed migrations for 50+ projects: from simple landing pages to high-load e-commerce stores. We use official tools: [React Server Components](https://nextjs.org/docs/app/building-your-application/rendering/server-components), Prisma, Zod. Each project is documented and we deliver a complete architectural diagram.
Request a consultation — we'll analyze your project and suggest the optimal migration plan.
Website Redesign and Migration: CMS Change, SEO Preservation
A client came to us 6 weeks after a self-attempted redesign: 'We moved from WordPress to Tilda, traffic dropped by 70%.' I opened Google Search Console — 847 pages returned 404, the URL structure had completely changed, not a single 301 redirect was in place. Yandex hadn't reindexed the new site yet, positions collapsed. Recovery took 4 months and resulted in significant revenue loss for the quarter. Our experience — over 7 years and 80+ successful migrations, we guarantee position retention with the right approach.
Why Do Migrations Break SEO?
Search engines have indexed specific URLs. If /catalog/shoes/nike-air-max-270 turned into /products/nike-air-max-270 without a 301 redirect — all the link equity, traffic, and rankings go nowhere. Google says 301 passes ~99% of PageRank, but in practice positions recover over 2–8 weeks, not instantly.
Commonly, SEO gets broken not out of malice, but because a developer doesn't view the URL structure as a public API. Here are typical breakages:
| Problem |
Cause |
Solution |
| Duplicate content |
New site opened parallel to old |
Disable indexing of dev version, set canonical |
| Loss of metadata |
Title and description left in old CMS |
Export via API, mass import with verification |
| Canonical changes |
Pagination and filters reset |
Lock before development, implement in template |
| Speed drop |
Heavy sections, unoptimized images |
Optimize LCP, CLS, TTFB before launch |
How to Recover Traffic After a Failed Migration?
If traffic dropped, act immediately:
- Crawl the new site for 404s and compare with the pre-migration URL list.
- Create redirects for all lost pages with traffic >0.
- Check structured data and meta tags on a test sample.
- Daily monitor Coverage in Search Console and positions for top 50 queries.
- If after 2 weeks traffic does not recover — deep audit of redirects (transitivity, chains, loops).
In our practice, a large e-commerce site lost 50% of traffic when moving from Bitrix to React + Strapi. We restored 95% of redirects in three days, and within 3 weeks traffic returned to 90% of original.
What Does a Pre-Migration Audit Include?
Before starting development on the new site:
- Full crawl of current site via Screaming Frog or Sitebulb. Get list of all indexable URLs with traffic from Google Search Console.
- Export all pages with organic traffic >0 over the last 6 months — these are priority for redirects.
- Record all external backlinks to specific pages — Ahrefs, Semrush.
- Snapshot current positions for key queries — baseline for post-migration comparison.
- Save Core Web Vitals from Search Console for the previous 90 days.
Table for recording:
| Audit Stage |
Tool |
Criticality |
| URL collection |
Screaming Frog + GSC |
High |
| Page traffic |
Google Analytics / Search Console |
High |
| External links |
Ahrefs / Majestic |
Medium |
| Positions |
Yandex Wordstat / Serpstat |
Medium |
| Core Web Vitals |
GSC CrUX |
High |
Contact us for a detailed pre-migration audit — we will help identify all risks and create an action plan.
URL Mapping and Redirects
For projects with 200+ pages, we create a mapping table: old URL → new URL → status (301, merged with another page, deleted). Each row is verified: does the content actually migrate here?
In Laravel, redirects are handled via configuration file and middleware, not .htaccess — faster and more manageable. For WordPress → Next.js: redirects are set in next.config.js (static) and at the Nginx/CDN level for dynamic ones. Old .htaccess on shared hosting with 500+ lines of redirects is a special hell. Each redirect is checked sequentially, performance suffers. We move to Nginx map directive or Redis cache for dynamic lookup. More at Wikipedia: HTTP 301.
How to Migrate Content from Different CMSs?
WordPress → Headless CMS (Contentful, Strapi, Sanity):
WordPress REST API or WP All Export to export posts, meta fields, media files. Migration script in Node.js: parse export, transform structure, upload via CMS API. Media files are reuploaded to new storage, links updated in content. Typical problem — shortcodes in WordPress content ([gallery id="123"]): need parser and transformation to new format.
1C-Bitrix → modern stack:
Bitrix stores content in non-standard tables with IBLOCK_ELEMENT_PROPERTY. Direct SQL export via phpMyAdmin or Bitrix API. Transformation is the longest part due to specific Bitrix data structure.
Heavy WYSIWYG → structured content:
Years of editing in FCKEditor/TinyMCE leave inline styles, non-standard tags, broken attributes. HTML sanitize + transformation to Markdown or Portable Text (Sanity) with manual check of problematic pages.
| CMS |
Migration Tools |
Complexity |
Risks |
| WordPress |
WP All Export, WP-CLI, REST API |
Medium |
Shortcodes, meta fields |
| 1C-Bitrix |
Bitrix API, SQL export |
High |
Complex structure, infoblock properties |
| Joomla |
J2XML, direct DB export |
High |
Outdated extensions |
| Tilda/Readymag |
API export (limited) |
Medium |
No full content access |
How to Preserve Technical SEO Elements During Migration?
Structured data (Schema.org) — if the old site had Product, Article, BreadcrumbList markup, they must be on the new site too. Google Search Console → Enhancement reports will show loss of rich snippets.
Sitemap XML: generated automatically, submitted to GSC a day after launch. Old sitemap remains until full reindexing.
hreflang for multilingual sites: if tags are lost during migration, conflicts between language versions in search results will start within weeks.
Open Graph and Twitter Card meta tags — often forgotten when changing template, pages stop displaying correctly when shared on social networks.
Launch and First Weeks Monitoring
DNS propagation: DNS switching takes up to 48 hours, plan launch with buffer. Cloudflare as DNS provider — propagation takes minutes, not hours.
After launch, monitor daily: Search Console → Coverage (indexing errors), Analytics → organic traffic, year-over-year comparison, crawl site for 404 errors.
First 2 weeks are critical. If traffic drops more than 30% — immediate audit of redirects and comparison with pre-migration crawl.
Launch checklist (spoiler)
- [ ] All 301 redirects work and do not form chains
- [ ] Sitemap submitted to GSC and Yandex.Webmaster
- [ ] Canonical tags set on all pages
- [ ] Open Graph / Twitter Card display checked
- [ ] robots.txt and noindex meta tags adjusted
- [ ] Core Web Vitals in green zone (LCP <2.5s, CLS <0.1, INP <200ms)
What the Service Includes
Results you receive:
- Migration plan with URL mapping and redirects in Excel/Google Sheets format.
- Configured 301 redirects at server level (Nginx/Cloudflare/Vercel).
- Migrated content with integrity check: images, meta fields, links.
- Structured data (Schema.org) on the new site, identical to old or improved.
- SEO report: position trend at 1, 3, and 6 weeks after launch.
- Coverage monitoring in Search Console with error notifications.
- Guaranteed position retention: if traffic drops more than 15% within the first month — free audit and correction.
Timelines and Estimates
- Redesign with migration for a small site (up to 100 pages): 4–8 weeks.
- E-commerce migration with 500+ product pages: 8–16 weeks.
- Only technical migration part (redirects, metadata) without redesign: 1–3 weeks.
Cost is calculated individually based on scope.
Get a consultation for your project — we will respond within a day. Order a pre-migration audit of your site and receive a detailed proposal with a redirect plan. Contact us to discuss details.