The question with a WordPress migration is never whether Next.js will be faster. It will be. The question is whether you will still have your organic traffic in month three. Most migrations that go wrong go wrong in exactly the same places: permalinks that changed shape, redirects that were never mapped, structured data that Yoast used to emit and nothing replaced, and pagination or archive URLs that quietly stopped existing. I plan the migration around those risks first and the rebuild second.
Before a single component is written I pull every URL Google knows about — sitemap, Search Console coverage report, server logs — and classify it: keep, redirect, or retire deliberately. Sites almost always have more indexed URLs than anyone remembers, and the forgotten ones are exactly where traffic leaks after a launch.
A full cutover on launch night means every problem arrives simultaneously. I prefer routing one section at a time to the new Next.js frontend — blog first, then landing pages, then the rest — with the old site serving everything else. Problems show up one at a time and in a scope you can reason about.
The migration is not finished at deploy. For the following weeks I watch impressions, average position, Core Web Vitals and coverage errors in Search Console, and compare against the pre-launch baseline I captured. If something dropped, we find out in days rather than discovering it in a quarterly report.
Not if the migration is planned around URLs and redirects rather than treated as an afterthought. Expect some volatility for two to four weeks while Google recrawls — that is normal. A sustained drop is not, and it is what the redirect map and Search Console monitoring exist to prevent.
Yes, and it is usually what I recommend. Going headless keeps your content, editors and workflow in place while replacing only the frontend. Migrating content out of WordPress entirely is a bigger project and only worth it if WordPress itself is the problem.
For a content site of a few hundred pages, typically four to eight weeks including the inventory work and a staged rollout. Sites with heavy plugin dependencies or e-commerce take longer, because each plugin's frontend behaviour needs an equivalent.