Move to Next.js. Keep every ranking you've earned.

Most of the risk in a WordPress migration has nothing to do with rebuilding pages — that part is predictable. What sinks a migration is URLs: the ones nobody inventoried, the redirects that chain instead of landing in one hop, the ones that quietly 404. We run the process that catches that before launch, not after.

WORDPRESSNEXT.JS301 REDIRECTS

Starting at $1,500 same published pricing as our web builds

Is a migration the right call?

A migration earns its cost when the site is becoming an application, when plugin debt has made every change genuinely risky, or when performance is measurably costing you conversions. It is not justified by "the site feels slow" on its own — that's usually a cheaper problem: caching, image optimisation, trimming four plugins. We'll say so if that's your actual situation rather than sell you a rebuild you don't need.

If the real complaint is that a developer has to touch every content change, that's the editing question, and it's worth settling before anything else — either budget a headless CMS into the new build, or consider keeping WordPress purely as the editor and rendering the front end in Next.js.

What's included

  • Full URL inventory — sitemap, Search Console's indexed list, server logs, and a crawl, combined. The gaps between those four lists are what a migration usually loses.
  • A redirect map built before a page is coded — 301s, one hop each, trailing-slash matched, never bulk-redirected to the homepage.
  • Content and media extraction — post bodies, shortcodes triaged one by one, images re-pathed, and Yoast/RankMath metadata carried over rather than regenerated from scratch.
  • Pre-launch verification on staging — every redirect checked in one hop to a 200, content confirmed server-rendered, structured data validated.
  • An admin panel with a CMS and lead system — so the new site doesn't freeze the moment we hand it over. See what's in it.
  • Post-launch monitoring — Coverage report, crawl stats, and top-pages-by-clicks watched through the reprocessing window, not just at launch.

How it works

i

Inventory

Every URL that currently resolves, sorted by traffic and inbound links, before anything is built.

ii

Redirect map

Old URL to new URL, one hop, written down before the URL structure decision gets made informally.

iii

Build

Content extracted via the WordPress REST API, rebuilt on Next.js, with your admin panel wired in.

iv

Verify

Every redirect and every page checked on staging against the original inventory before cutover.

v

Monitor

Sitemap resubmitted, top pages re-indexed, and Search Console watched for four to six weeks.

Want the full technical breakdown, including the actual redirect code? Read the migration playbook →

Questions

Will I lose my Google rankings during the migration?

A two-to-four week wobble while Google reprocesses the new URLs is normal even on a clean migration. What isn't normal is a decline that doesn't recover by week six — that means URLs were genuinely lost, which is what the URL inventory and redirect map at the start of the process exist to prevent.

How long does a migration take?

Two to four weeks depending on how many pages and post types the site has. Sites with a large blog or heavy shortcode use on the content side take longer to extract cleanly than they do to rebuild.

What happens to my old WordPress site after launch?

We keep it reachable for a period after cutover if the redirects are served there, and only decommission it once the coverage report and top-page traffic have been watched through the reprocessing window.

Will I still be able to edit content myself?

Yes. Every migration ships with the same admin panel that comes with a new build — you edit pages, prices and blog posts yourself, with no developer in the loop for routine changes.

Do you migrate every plugin and shortcode?

Every shortcode gets found and triaged before the build starts — rebuilt as a React equivalent where it's load-bearing, converted to static markup where it isn't. Scope and cost depend on what your specific plugin stack is actually doing, so this gets confirmed in the scoping call rather than assumed upfront.

Is a migration always the right call?

Not always. If the complaint is just that the site feels slow, that's often a cheaper fix — caching, image optimisation, trimming plugins. A migration earns its cost when the site is becoming an application, plugin debt has made changes genuinely risky, or performance is measurably costing conversions. We'll tell you if you don't need one.

Start a migration

Tell us what's on the old site.

Send your current URL and a rough page count. You'll get a written scope, timeline, and quote within 24 hours.