WordPress Multisite to Next.js Migration

WordPress Multisite Was a Good Idea in 2012

WordPress Multisite made sense in 2012. In 2026, every subsite you add makes the migration you'll eventually need harder. The prefixed tables grow. The serialized data accumulates. The domain mapping plugin adds another dependency. Every year on Multisite is a year of technical debt you'll pay back during migration.

The question isn't whether you'll migrate. It's when.

We've migrated Multisite networks with 5 subsites and networks with 80+. The technical pattern's the same every time: extract prefixed tables, deserialize years of accumulated options data, map shared users to a modern auth system, and build a multi-tenant architecture that actually scales. The difference is scope, not complexity.

Why Leave WordPress Multisite

Multisite networks accumulate specific categories of technical debt that compound over time.

Prefixed Table Sprawl

Every subsite creates its own set of tables: wp_2_posts, wp_2_postmeta, wp_2_options, wp_3_posts, and so on. A 25-site network has 250+ tables. Querying across subsites requires unions across all of them. There's no native cross-site search, no unified content API, no way to aggregate without custom SQL.

Serialized Data Everywhere

WordPress stores complex data as PHP serialized strings. ACF field groups, widget configurations, site URLs, plugin settings — all serialized. These strings encode string lengths (s:23:"https://old-domain.com"), which means you can't do a simple find-and-replace on URLs without breaking the serialization. Every migration that touches serialized data needs proper deserialization, transformation, and re-serialization. No shortcuts.

Shared Users, Fragmented Roles

The wp_users table is network-wide. One user can be an admin on subsite 2, an editor on subsite 5, and a subscriber on subsite 12. Those roles live as serialized arrays in wp_usermeta under keys like wp_2_capabilities. Extracting that into a sane auth model means parsing every user's role per subsite — which is as tedious as it sounds.

Plugin and Update Fragility

Network-activated plugins affect all subsites simultaneously. A plugin update that breaks one subsite breaks the admin for every subsite. Site-specific plugins create version conflicts. The shared codebase means every change is a potential network-wide outage.

Performance Degradation at Scale

Multisite networks with 10+ subsites see 40-60% slower page loads compared to standalone WordPress installations. Serialized data parsing, shared database connections, and plugin overhead all stack up. Lighthouse mobile scores typically land between 35-55. Not great.

What You Get: Next.js + Supabase Multi-Tenant Architecture

The target architecture replaces the entire Multisite network with a single Next.js application backed by Supabase, using Row Level Security for tenant isolation.

Route-Based Multi-Tenancy

Instead of subdomains or subdirectories managed by WordPress, each location gets a clean route: /locations/[slug]. Shared components (navbar, footer, brand elements) render from a single layout. Location-specific content pulls from Supabase filtered by location_id. One codebase, one deployment, unlimited locations.

Supabase RLS for Data Isolation

Row Level Security policies enforce that location managers only see their own data, while network admins see everything. No application-level filtering hacks. The database itself enforces access:

CREATE POLICY "location_isolation" ON posts
  FOR ALL USING (
    auth.uid() IN (
      SELECT user_id FROM user_locations
      WHERE location_id = posts.location_id
    )
  );

This eliminates an entire class of authorization bugs that plague multi-tenant WordPress setups.

Modern Admin Dashboard

Location managers get a purpose-built dashboard: add locations, edit content per location, manage media. No more clicking through WordPress's network admin switcher. No more "Super Admin" vs "Site Admin" confusion.

Our 7-Phase Migration Process

Phase 1: Network Audit (1-2 Weeks)

We map every subsite in your network — URL structure, content volume, plugins used, custom post types, custom fields, domain mapping configuration. We query wp_blogs to enumerate subsites, then crawl each one via REST API and direct database queries.

We identify shared content (network-wide) versus site-specific content. Shared plugins versus site-specific plugins. Custom code in child themes, mu-plugins, and network-activated plugins with custom functionality.

The output is a migration specification document with a subsite-by-subsite content inventory.

Phase 2: Architecture Design (1 Week)

We design the Supabase schema: locations table, content tables with location_id foreign keys, RLS policies per table. We design the Next.js route structure and map every old URL to its new equivalent for 301 redirects.

The admin dashboard gets wireframed: location management, per-location content editing, role-based access. Every decision is documented before we write a line of code.

Phase 3: Content Export (1-2 Weeks)

This is where Multisite migrations get technical. We extract content through two channels:

WP REST API for standard content — authenticated requests per subsite, handling pagination across thousands of posts.

Direct database queries for everything the API can't surface: ACF fields stored in wp_2_postmeta, custom tables created by plugins, serialized options containing critical configuration.

Serialized data gets processed through PHP's unserialize() or Python's phpserialize library. Domain references embedded in serialized options (siteurl, home) are updated before re-serialization. A naive search-and-replace on serialized strings corrupts the length prefixes and breaks everything — we've seen this go wrong, and cleaning it up is brutal.

Media files are downloaded by iterating /wp-content/uploads/sites/[id]/ per subsite. Users are exported from the network-wide wp_users table with per-site capabilities parsed from serialized wp_usermeta entries.

Output: JSON and CSV files per subsite with all content, users, and media inventoried.

Phase 4: Build (2-6 Weeks)

The Next.js application takes shape with route-based multi-tenancy. Supabase tables are created with RLS policies enforced. Shared layout components handle brand consistency. Per-location page templates render localized content zones.

The admin dashboard supports adding locations, editing location content, and viewing aggregated data across all locations. Contact forms, booking integrations, and third-party embeds are rebuilt or migrated.

Timeline depends on complexity: a 5-subsite network with standard pages takes 2 weeks. A 40-subsite network with custom booking systems, membership areas, and complex ACF layouts takes 6.

Phase 5: Content Import (1-2 Weeks)

All content is batch-imported to Supabase with location_id mapping. Every wp_2_ prefixed table maps to location ID 2. Media URLs are rewritten from /uploads/sites/23/image.jpg to Supabase Storage paths or new CDN URLs using regex transformations across all content fields.

WordPress users are mapped to Supabase Auth. Password hashes are preserved — bcrypt rehashing occurs on first login, so users don't need to reset passwords.

We validate by spot-checking 10% of content per subsite against the original.

Phase 6: Redirect Mapping (1 Week)

Every old URL across all subsites gets mapped to its new URL. For domain-mapped subsites, the old domain redirects to the new /locations/[slug] path with a 301. Old subdomains (site2.example.com) redirect to /locations/site2.

We crawl every old sitemap and verify a 301 exists for every URL. New sitemaps are submitted to Google Search Console per former domain.

Phase 7: Launch and Monitor

DNS cutover happens per domain. SSL certificates auto-provision via Vercel. Google Search Console gets new domain properties with fresh sitemaps. We monitor for 30 days: indexing progress, Core Web Vitals baselines, 404 tracking.

The old WordPress database is archived. Hosting is cancelled after a 60-day monitoring period confirms everything's stable.

SEO Preservation Strategy

Multisite migrations carry real SEO risk — you're potentially changing URLs across dozens of domains at once. Our approach:

• Exhaustive 301 mapping — every URL, every subsite, every domain. No 404s.
• Sitemap submission per domain — each former domain gets its own sitemap submitted to GSC.
• Canonical tag consistency — new pages carry proper canonicals from day one.
• Content parity verification — automated diffing ensures no content is lost or truncated during import.
• Backlink preservation — we audit backlinks per subsite and ensure 301s capture all inbound link equity.

Clients typically see 25-50% organic traffic improvement within 90 days, mostly from Core Web Vitals gains alone.

Timeline and Pricing

Network Size	Subsites	Timeline	Investment
Small	5-10	4-6 weeks	$15,000 - $30,000
Medium	10-25	6-8 weeks	$30,000 - $60,000
Large	25-50	8-12 weeks	$60,000 - $100,000
Enterprise	50+	10-16 weeks	$80,000 - $150,000+

Pricing scales with the volume of serialized data, custom post types, user role complexity, and third-party integrations per subsite. Networks with heavy ACF usage or custom plugin functionality trend toward the higher end.

Every engagement starts with a free migration audit. We map your network, estimate scope, and give you a fixed-price proposal before any work begins.