WordPress → Next.js Migration
Migrate off WordPress without losing your rankings
The fear that stops most migrations is not the rebuild — it is waking up to a site that is faster and invisible. We migrated this very website off WordPress: 269 legacy URLs, 124 location pages, a 63-post blog. Every page URL still resolves or redirects to its successor, and an automated check refuses to let a build ship until that is true.
legacy URLs carried through our own migration — 259 resolving directly, the rest 301'd
content URLs lost, enforced by an automated gate that fails the build if one breaks
Lighthouse performance scores as the shipping standard on the rebuilt site
from scoping call to a fixed quote that holds unless the scope changes
Sound familiar?
The Problems That Quietly Cost You Customers
The traffic that never came back
Most migration horror stories are the same story: URLs changed, redirects were approximate, and six months of rankings went with them. The new site was genuinely better and nobody could find it.
Redirects done by hand, once
A spreadsheet of redirects written the week of launch, checked by spot-sampling. The twenty URLs nobody sampled are the ones that quietly 404 for a year.
A rebuild that stalls at 80%
The marketing pages get rebuilt and the long tail — old posts, landing pages, the odd PDF — is left on the old system indefinitely, so you pay to run both.
The case study is this website
We ran this migration on ourselves first
voltsconsulting.com was a WordPress and Elementor site. It is now Next.js, statically generated, on the same URLs. The inventory came to 269 legacy addresses including 124 detailing location pages and a 63-post blog — exactly the messy long tail that migrations usually abandon.
The mechanism that made it safe is unglamorous: the URL inventory lives in the repository as data, and a script checks every entry against the built output. If a URL is neither built nor redirected, the check exits with an error and the build does not ship. Redirect coverage stops being a promise somebody made in a launch meeting and becomes a condition of shipping.
We are not going to pretend the rebuild was frictionless. A CDN misconfiguration after launch served stale HTML and cost us real indexing, which we then had to diagnose and repair. That is exactly why we now treat cache behaviour and post-launch monitoring as part of the migration rather than as someone else's problem.
When you should — and should not
WordPress is not always the problem
If your team publishes daily through the WordPress editor and the site performs adequately, migrating may buy you less than tuning what you have. We will say so; a migration that solves nothing is an expensive way to change logos in an admin panel.
The move earns its cost when the symptoms are structural: plugin stacks you cannot safely update, Core Web Vitals you cannot fix, security patching that has become somebody's monthly chore, or a roadmap that needs real application features the CMS was never meant to carry.
And it is not all-or-nothing. Headless setups keep WordPress as the editor your team already knows while Next.js renders the front end — often the honest middle path for content-heavy businesses.
What's included
How a rank-safe migration actually works
Full URL inventory first
Every live URL is inventoried from sitemaps, analytics, and Search Console before a line of code is written. You cannot preserve what you never listed.
One-to-one redirect mapping
Each old URL either keeps working or 301s to a specific successor. No wildcard sweeps to the homepage — Google reads those as soft 404s and drops the rankings anyway.
An automated gate, not a spot check
The redirect map becomes a test. Our build fails if any inventoried URL stops resolving, which is why the count is zero rather than approximately zero.
Static generation and real speed
Pages pre-rendered at build time, images pre-optimized into modern formats. The speed gain is the point of leaving WordPress — it should show up in Core Web Vitals, not just in the pitch.
Content migrated, not retyped
Posts and pages come across programmatically with their dates, metadata, and images intact, so publish history and structured data survive the move.
Post-launch monitoring
Search Console watched for coverage errors and 404s through the weeks after cutover, when a missed redirect still costs nothing to fix.
How it works
From first call to launch, without the guesswork
- 01
Discovery call
We start with a short call to learn your business, your customers, and what a win looks like. Then we map the exact pages and features your site actually needs.
- 02
Design the look
You see real design mockups, not vague promises. We shape the layout, colors, and imagery around your brand and refine it until it feels right.
- 03
Build and connect
We build the site to be fast and mobile-first, then wire up the tools you rely on, from booking and forms to listings and payments.
- 04
Launch and support
We take you live, check everything works, and stay on to handle updates, tweaks, and improvements as your business grows.
Pricing
Straightforward pricing, packaged or fully custom
Every project starts with a clear quote, so you know the number before any work begins and never get surprised by hidden costs. Pick our packaged get-a-new-website offer for a fast, affordable launch, or go fully custom when you need something built exactly to spec.
FAQ
Questions We Answer Every Week
Not if the migration is done properly, and that is a process rather than a hope: inventory every URL, map each one to a successor, carry metadata and structured data across, and verify after cutover. On our own migration the inventory was 269 URLs and the loss was zero — enforced by an automated check, not by sampling.
A typical business site runs four to eight weeks depending on page count and integrations; large content archives and custom functionality extend that. You will get a real timeline at scoping, along with what we need from you and when.
Yes. Either through a headless CMS your editors log into much as they do today, or through content files if your team is technical. We pick based on who actually edits and how often, not on what is fashionable.
They get audited one by one: some become native features, some map to a service, and some turn out to be doing nothing anyone can identify. Forms, SEO metadata, analytics, and e-commerce all have solid equivalents; anything genuinely irreplaceable is a reason to consider headless instead.
Pre-rendered pages and pre-optimized images remove most of what makes WordPress slow — plugin overhead and per-request rendering. Judge it directly: run this page through PageSpeed. The score you see is the standard we ship at.
It scales with page count, custom functionality, and integrations, so we do not publish a flat number. After one scoping call you get a fixed, itemized, written quote, usually within 48 hours, and it holds unless the scope changes.
Collaboration
Got a project?
Let's talk.
We're a team of creatives who are excited about unique ideas and help companies to create amazing identity by crafting top-notch UI/UX.