WordPress Multisite Migration to Next.js

WordPress multisite migration is what we call the process of moving a WordPress Multisite network -- prefixed tables, serialized options, shared users and all -- onto a single Next.js and Supabase application, with Row Level Security enforcing per-location data isolation instead of shared database tables. We build this for platform operators running networks of 5 to 80+ subsites who've hit the point where wp_2_posts, wp_3_posts and wp_4_posts multiplying faster than queries can handle stops being a joke about database sprawl and becomes an actual outage risk. Here's what changes: every subsite's prefixed tables get extracted and mapped to a location_id, serialized data in wp_options and wp_postmeta gets properly deserialized rather than string-replaced, and the shared wp_users table with its per-site capability blobs gets rebuilt as a clean role model in Supabase Auth. What we end up with is one codebase serving unlimited locations, RLS policies doing the isolation work the database layer should've been doing all along, and a per-location dashboard replacing WordPress's network admin switcher. Timeline runs from 4-6 weeks for a 5-10 subsite network up to 10-16 weeks for 50+ subsites with heavy custom integrations -- we start every engagement with an audit of wp_blogs and every subsite's plugin footprint so we can scope it properly. Pricing is fixed-fee, quoted after that audit; see /pricing/ for how we structure it. This isn't a lift-and-shift. It's a rebuild of the isolation model Multisite never had, using tools -- Supabase RLS, Next.js route-based tenancy -- that didn't exist when Multisite shipped.

Who This Is For (and When It's the Wrong Call)

We take this migration on when there's a real network behind it: a franchise operation, a multi-location service business, an agency-managed portfolio of client sites, or a directory that's outgrown a single WordPress install. If you're staring at 25+ subsites and your database has crossed into three-digit table counts, you're who we're writing this for. We've written more on why Multisite's architecture breaks down at that scale in WordPress Multisite Isn't Multi-Site Architecture.

We'll tell you when it's the wrong call, too. If your network is 2-3 subsites with minimal content and no growth plans, the migration cost won't pay back -- just tidy up what you've got. If you depend on a specific WordPress plugin ecosystem with no equivalent (some niche booking or membership plugins genuinely don't have a clean headless replacement), scope that dependency before you commit, not after. And if you can't tolerate any downtime or SEO risk in the next quarter, this needs more lead time than a rushed migration allows -- rebuilding a redirect map for 80 subsites properly takes real weeks, not a weekend.

How We Do It

The process runs in phases, and the timeline scales with subsite count -- a 5-10 subsite network moves faster than an 80-subsite one, but the steps stay the same.

Audit (1-2 weeks). We query wp_blogs to enumerate every subsite, then crawl each one to inventory content volume, plugins, custom post types and domain mapping. What comes out is a migration specification with a subsite-by-subsite content breakdown.

Architecture design (1 week). We design the Supabase schema -- a locations table, content tables with location_id foreign keys, RLS policies per table -- and map the Next.js route structure. Every old URL gets mapped to its new equivalent before we write a line of migration code.

Content export (1-2 weeks). Standard content comes through the WP REST API. Everything the API can't surface -- ACF fields, custom plugin tables, serialized options -- comes through direct SQL against the prefixed tables. We run serialized strings through phpserialize rather than find-and-replace, because a naive string swap corrupts the length prefixes and breaks the whole option set. We've seen it happen; it's not a risk worth taking.

Build (2-6 weeks). The Next.js application takes shape here: route-based tenancy, RLS-enforced Supabase tables, a per-location admin dashboard. This is the phase where the timeline flexes most -- a network with standard pages and no custom integrations moves through it fast; one with booking systems and membership areas doesn't, and we don't pretend otherwise.

Content import (1-2 weeks). Batch import maps every wp_2_ prefixed table to location_id 2, and so on. Media URLs get rewritten to Supabase Storage paths. WordPress password hashes migrate to Supabase Auth and rehash on first login, so nobody has to reset a password.

Redirect mapping and launch (1-2 weeks). Every URL across every domain gets a 301. New sitemaps go to Google Search Console per former domain. We monitor indexing and Core Web Vitals for 30 days before we let the old hosting go.

Here's what you get at the end: a single Next.js codebase, a Supabase schema with RLS policies doing the tenant isolation, a content dashboard your team can learn in a session, a full redirect map, and 30 days of post-launch monitoring.

What We've Shipped

We've taken this pattern from WordPress into production more than once, and the results hold up.

SleepDr.com, a sleep medicine practice, moved from WordPress to Next.js 15 with Payload CMS and Supabase, with a HIPAA-safe architecture (patient forms handled via HIPAA-compliant Jotform, no PHI touching our servers), medical schema markup, 20 city landing pages and four-language support. Lighthouse went from 35 to 94 -- that's the exact range of scores we see on Multisite networks buried under serialized-data overhead, and we fix it the same way every time: strip the parsing weight, ship static where you can.

Not Another Sunday, a global coffee, pub and restaurant directory, runs on Next.js 15, Supabase and Vercel with 137,000 listings and 10,500 coffees ranked by a custom quality score, hundreds of programmatic SEO pages, and a crawl-budget strategy that keeps thin pages out of the index. It's the same route-based, database-driven pattern a multisite migration needs at scale -- one codebase serving thousands of location-equivalent pages instead of hundreds of WordPress database tables doing the same job worse.

Sources

Our redirect strategy follows Google's own guidance on 301 redirects and consolidating duplicate URLs -- both matter when you're mapping dozens of domains at once. The Lighthouse and Core Web Vitals targets we design against come from web.dev's Vitals documentation. We build the route-based tenancy pattern on the Next.js App Router.

Next Step

If your network's past the point where you can keep patching around prefixed tables and serialized data, get in touch and we'll scope an audit. See /pricing/ for how fixed-fee engagements are structured, or contact us directly to talk through your network's specifics.