Migrating from WordPress to Next.js: What Actually Happens

The WordPress Paradox

WordPress is simultaneously the most popular CMS in the world and the one people most want to leave. W3Techs has put WordPress on more than 40% of all websites for several years running, and a large share of those owners are quietly looking for the exit.

The reasons are predictable:

• Security maintenance is relentless. WordPress core, themes, and plugins need constant updates. Skip one, and you're a target for automated attacks. Every plugin you run is one more codebase you depend on someone else to patch.

• Performance degrades over time. Every plugin adds JavaScript, CSS, and database queries. A site that was fast at launch slows down as plugins, page builder sections, and tracking scripts pile up, and caching plugins only hide part of it.

• PHP templates are a poor fit for modern frontend work. The frontend world has moved to React, TypeScript, and edge rendering. A WordPress theme mixes PHP, HTML, CSS, and JavaScript across a template hierarchy, which makes every design change slower than it needs to be.

• AI editing works, but only partly. WordPress has an official MCP adapter from the core AI team, so an AI agent can reach your posts and settings. What it cannot give you is a branch, a diff, a test run, or a one-command revert. In a Next.js repo, the agent works on the whole codebase and every change goes through review before it ships.

Before You Build: The Audit That Humbles You

Every WordPress-to-Next.js guide shows a neat flowchart. Here's what the flowchart doesn't show.

You open your WordPress admin and start cataloguing. That's when you realize a "simple" site can easily have:

• A couple of dozen active plugins, some of which nobody on the team recognizes

• A theme that hasn't been updated in years

• Custom post types created by plugins (testimonials, case studies, team members, portfolio items), each of which becomes its own collection in the new CMS

• A hundred-plus blog posts with embedded videos and custom shortcodes

• WooCommerce with several payment gateways (if applicable)

• A contact form with conditional logic and a CRM integration

• Custom PHP functions in functions.php that you forgot you wrote

• SEO metadata managed by Yoast or Rank Math across every page

Two more items belong in the audit before anyone writes code:

• Every URL pattern. WordPress permalinks vary: /category/post-name/, /2024/03/post-name/, /custom-post-type/slug/. Each pattern needs a route in Next.js and a redirect rule for the old format. Pull the full list from your sitemap and from Google Search Console, not just the menu.

• The media library and every external connection. Count the files and their total size, because a large library needs a scripted transfer, not drag and drop. Then map every outside service: analytics, CRM, email marketing, chat, booking, payments. Each one has to be reconnected and tested on the new site.

The Plugin Audit

Every WordPress plugin needs a replacement strategy. There are three categories:

1. Plugins you can replace with native code. Contact forms, SEO meta tags, image optimization, caching: these are built into modern frameworks. You don't need a plugin for what Next.js does out of the box.

2. Plugins you can replace with services. Email marketing (use the API directly), analytics (Plausible or Umami), booking systems (Cal.com), e-commerce (Shopify's Storefront API).

3. Plugins you'll need to rebuild. Custom calculators, proprietary workflows, membership gates, LMS features, complex form logic. These require actual development work, and this is where migration scope explodes.

Content Migration: Where the Surprises Live

WordPress content migration sounds simple: export posts, import them to your new CMS. In reality:

• Shortcodes are everywhere. WordPress plugins inject shortcodes like [gallery ids="1,2,3"] and [contact-form-7 id="42"] throughout your content. Each one needs to be identified and replaced with an actual component.

• The Block Editor (Gutenberg) generates complex HTML. Those columns, buttons, and media blocks carry WordPress-specific class names and data attributes that mean nothing outside WordPress.

• Image paths are absolute. Every image in your content points to yoursite.com/wp-content/uploads/2024/03/image.jpg. You need to download every image, re-optimize it, upload it to your new host, and rewrite every reference.

• Post metadata is scattered. SEO titles live in Yoast's or Rank Math's meta fields. Featured images are in post_meta. Custom fields are wherever ACF decided to put them. Your export has to gather data from several places per post.

The WooCommerce Problem (If Applicable)

If your WordPress site runs WooCommerce, the migration scope roughly doubles. Product data, customer accounts, order history, tax rules, shipping zones, discount codes: all of it lives in the WordPress database and needs to go somewhere.

The usual answer is to separate the two jobs: build the marketing site in Next.js and either keep WooCommerce running headless for the store or move the store to Shopify. It works, but it is a different architecture than what you had before, and it should be scoped as its own project.

How Long It Actually Takes

Done by one person working through it step by step around a day job, the sequence above easily stretches over several weeks: a week of audit, another of plugin decisions, then content scripts, rebuild, and redirect testing one after the other.

That is not how a dedicated team runs it. MigrateLab is a fast migration agency: the audit, rebuild, content scripts, and redirect map run in parallel, so most WordPress sites go live in 7 to 14 days, and large CMS sites (hundreds of items, ecommerce or localization) take 3 to 4 weeks. See WordPress to Next.js migration services for how that is scoped.

The Technical Migration: Step by Step

1. Export Your Content

Use the WordPress REST API (/wp-json/wp/v2/posts, /wp-json/wp/v2/pages, plus one endpoint per custom post type that is registered with show_in_rest) to export content programmatically. The XML export is lossy and awkward to parse. Write a script that pulls every post with its metadata, categories, tags, and featured image. ACF fields only appear in the REST response if they are enabled for it, so check before you trust the export. Save the raw JSON: it is your source of truth, not the live site.

2. Map the Design to Components

Before writing pages, catalogue the visual patterns across the site: navigation (desktop, mobile, dropdowns), hero variations, card layouts (posts, services, testimonials), CTA sections, footer, plus the typography scale, color palette, and spacing system. Each pattern becomes one React component with typed props. A "service card" that is an Elementor widget on one page and a Gutenberg block on another becomes a single ServiceCard with title, description, icon, and link. Don't replicate the old theme's inconsistencies; this is the moment to clean them up.

3. Set Up Your Next.js Project

Start a clean project on a current Next.js release with TypeScript, the App Router (React Server Components, nested layouts), and Tailwind CSS, which ships only the classes you use and is easy for AI tools to read. Decide on hosting at the start, not the end. If a developer or agency is building it for a business, Vercel's Hobby tier is not an option: its terms restrict it to non-commercial use, so budget for Vercel Pro or use Cloudflare Pages, which has no commercial restriction.

4. Build Pages in Order

Build the global layout (header, footer) first, then the homepage, which establishes most of the components. Interior pages (services, about, contact) then reuse those components with different content, so each one goes faster than the last. Dynamic templates (blog posts, case studies) come last, wired to the CMS. AI tools speed this up a lot: give one a screenshot of a section and a description, and it produces a working first draft of the component for a developer to refine.

5. Transform and Import Content

Write a transformation script that converts WordPress HTML into your new format. Handle shortcodes, rewrite image URLs, and carry over SEO metadata. If you use a headless CMS, the script creates entries through its API and uploads images separately, then links them. If you go with Markdown or MDX, each post becomes a file with frontmatter (title, date, excerpt, tags). For anything beyond a handful of posts, script it: manual copying introduces errors you won't find until after launch. Re-optimize media on the way through (WebP, responsive sizes) and host it in object storage such as Cloudflare R2 or S3, or in the CMS's media library. This script will be ugly. That's fine. It only needs to run correctly once.

6. Decide Where Editors Will Work

If content changes regularly, editors need an admin interface. The common choices: Payload (open source, TypeScript-native, runs inside your Next.js app; the software is free but it needs a database and hosting, and Payload Cloud is not taking new deployments), Sanity (hosted, with a free tier of 20 seats and 10,000 documents), or no CMS at all, where content lives in the repo and changes go through a developer or an AI tool. Pick based on who edits and how often, not on what is fashionable.

7. Implement Redirects and Carry Over SEO

WordPress URLs follow patterns like /2024/03/post-title/ or /category/post-title/. Your new site probably uses /blog/post-title. Every old URL needs a 301 redirect to its new URL: static ones in next.config.js, pattern-based ones in middleware. Miss one and that page's ranking and backlinks are at risk. In the same pass:

• Export titles, meta descriptions, and canonicals from Yoast or Rank Math and set them through the Next.js Metadata API.

• Generate a sitemap that covers every page, and confirm robots.txt allows crawlers on all public pages.

• Keep any schema.org markup you had (Article, FAQ, Product) and add it where it is missing.

• Crawl the new build for internal links that still point at old URL patterns.

8. Launch and Watch

Deploy the final build, lower your DNS TTL 24 to 48 hours ahead, switch the records, and check the site from more than one location. Submit the new sitemap to Google Search Console. Keep the old WordPress install reachable (not public) as a fallback. Then monitor Search Console, analytics, and form submissions daily for two weeks. Watch for crawl errors, dropped pages, and indexing issues. Rankings will fluctuate; that's normal. If they haven't settled after about four weeks, something in the redirects or indexing needs a closer look.

What Makes This Hard (Really)

The technical steps above are knowable. The hard part of a WordPress migration is scope management. Every WordPress site has grown organically over years. Features were added piecemeal. Plugins were installed to solve problems nobody remembers anymore. Content was created by several people with different formatting habits.

When you migrate, you make hundreds of micro-decisions: Do we keep this feature? Do we rebuild this form exactly, or improve it? Do we migrate every blog post, or only the ones that still get traffic? Each decision takes time, and they compound. That is why DIY estimates slip: not because the technology is hard, but because the scope is always bigger than you think. A fixed scope agreed before the build starts is what keeps a migration on schedule.

The Honest Trade-offs

Next.js is not free of costs. Before you commit, weigh these:

• One-time cost. A professional migration of a 50 to 100 page site runs $5,000 to $25,000, depending on content volume, custom functionality, and integrations. That is a real upfront investment set against the plugin licences, managed hosting, and maintenance time you stop paying for.

• A new editing interface. Your content team will use a different admin. Payload and Sanity are straightforward, but expect a short adjustment period and plan a handover session.

• Niche plugins become custom code. If you rely on specific WooCommerce extensions, membership plugins, or LMS plugins, the equivalent may need custom development rather than an install.

• E-commerce adds real scope. Many businesses move the marketing site to Next.js and keep the store on Shopify, or run a headless option like Medusa or Saleor.

• Sometimes you should stay. If your site is a simple blog that one person updates, it is fast enough, and the plugins are under control, a migration may not pay back. Migrate when the maintenance, speed, or editing workflow is costing you something real.

The AI Advantage

Here's the payoff: once your site is in Next.js, every change after launch gets faster. Need a new page? An AI coding tool can scaffold it from the components you already have. Need to update your pricing section? Describe the change in plain English. Need to fix a mobile layout bug? The tool can find and fix the CSS, and you review the diff before anything goes live.

The migration is a one-time cost. The velocity gain stays. If you want to know what that would look like for your site, start with a free review.