Now accepting Q2 projects — limited slots available. Get started →

Espanol Portugues العربية 한국어 Francais Deutsch English 中文日本語繁體中文 Nederlands

Enterprise Migration

Multisite NetworksMulti-Tenant ArchitectureZero-Downtime Cutover

WordPress Multisite Migration zu Next.js

Ihr WordPress-Netzwerk teilt eine Angriffsfläche über alle Sites hinweg

$1-2.5K/mo

WP Multisite Hosting

Typical managed hosting for 20-50 site networks

$45/mo

After Migration

Vercel + Supabase for same 50 sites

4-8wk

Migration Timeline

Typical WordPress Multisite to Next.js duration

95+

Lighthouse Score

Performance + accessibility target on every build

What WordPress Multisite Migration Actually Requires — And Why Most Agencies Won't Touch It

Your WordPress Multisite network runs 30+ subsites off one database, one plugin stack, one shared wp_users table. A migration pulls each subsite out — extracting content from prefixed tables like wp_2_posts and wp_3_options, remapping user capabilities stored as serialized arrays, rewriting every hardcoded media URL from /sites/[site-id]/ directories, and rebuilding the whole thing as isolated Next.js routes with per-location Supabase queries. Your team gets separate content stores, independent authentication, and zero shared plugin vulnerabilities. The old network had one entry point for attackers. Your new stack has none.

Wo Projekte scheitern

One plugin vulnerability on one subsite exposes all 30+ sites simultaneously That's not a hypothetical — 96% of WordPress exploits target plugins, and your entire network shares one attack surface. All it takes is one unpatched plugin on one subsite.

Prefixed database tables (wp_2_posts, wp_3_options) turn what should be a straightforward extraction into a multi-day operation Serialized data makes it worse — it contains hardcoded domain references, so a naive find-and-replace doesn't just miss things, it actively corrupts widget configs and option values.

The shared wp_users table with per-site capabilities (wp_2_capabilities, wp_3_capabilities) is its own headache You can't cleanly separate user access without remapping every capability key per subsite. There's no clean path — just careful, tedious work.

Media files live in /wp-content/uploads/sites/[site-id]/ with hardcoded URLs baked into the content itself Move or restructure any subsite and you break every image and file reference in that subsite overnight.

Domain-mapped subsites each need individual DNS changes, SSL certificates, and redirect rules Miss one domain during migration and you've handed that subsite's indexed pages and organic traffic to a 404 page.

Then there's the plugin problem The plugin that runs fine on your main site breaks on subsite #7 — and you can't update them independently. Network-activated plugins force every subsite onto the same version, so each update is a network-wide gamble.

Compliance

Prefixed Table Extraction

We remap every wp_N_ prefixed table to clean schema structures in Supabase. Serialized data gets parsed properly — domain references rewritten without touching the serialization format itself.

Multi-Tenant Row-Level Security

Each former subsite gets its own location_id in Supabase, with RLS policies enforcing content isolation. No shared database, no cross-site data leaks. They're genuinely separate now.

Per-Site User Role Mapping

We extract per-subsite capabilities from the shared wp_users table and remap them to Supabase Auth roles. Each user ends up with the right permissions per location — a single login that actually knows where they're allowed to be.

Media URL Rewriting

Every media file from /wp-content/uploads/sites/[id]/ moves to CDN-optimized storage, and all content references get rewritten to the new paths with next/image optimization baked in.

Per-Domain Redirect Mapping

Every URL across every subsite — including domain-mapped custom domains — gets a 301 redirect to its new path. No orphaned URLs, no rankings quietly disappearing in the background.

Network-Wide Performance Audit

We benchmark each subsite's Core Web Vitals, page count, and plugin dependencies before migration starts. After launch, we verify 95+ Lighthouse scores across all locations. You get before-and-after numbers, not just a promise.

Was wir bauen

One plugin exploit hits all 30+ subsites simultaneously because network activation forces identical versions everywhere

Automated REST API extraction pulls posts, taxonomies, ACF fields, and meta from each subsite without manual exports

Prefixed database tables scatter your content across wp_2_posts, wp_3_options, wp_7_postmeta with no clean export path

Dynamic /locations/[slug] routes share brand components while serving isolated content from Supabase per-location queries

Shared wp_users table stores per-site capabilities as serialized keys that break on naive migration attempts

Normalized schema replaces wp_N_ prefix chaos with location_id foreign keys and actual relational structure

Media files live in /sites/[site-id]/ with hardcoded URLs baked into post content and widget configs

Custom admin interface manages content and users per location without WordPress core or plugin conflict risk

Domain-mapped subsites each require separate DNS, SSL, and redirect coordination or you lose indexed traffic overnight

Pre-rendered pages serve static HTML from edge nodes with zero PHP execution or database queries on page load

Network-wide plugin updates gamble every subsite's stability because you can't update subsites independently

Per-domain GSC properties and sitemap monitoring track indexing stabilization across every former subsite domain

Unser Prozess

Network Audit

Start by mapping every subsite: URLs, content volume, active plugins, custom post types, domain mapping configuration, and user role distribution. You need to know exactly what shared functionality exists versus what's site-specific, and you need to flag every piece of serialized data that contains domain references before anything moves.

Week 1-2

Architecture Design

Then design the Next.js route structure, Supabase schema with location_id and RLS policies, shared component library, and per-location content models. The redirect strategy for every domain gets defined here too — before a single line of migration code runs.

Week 2-3

Content Export & Media Migration

Extract content via the WP REST API per subsite. Download media from each /sites/[id]/ directory. Export users with per-site capability mapping. Validate serialized data integrity at every step.

Week 3-5

Build & Import

Build the Next.js multi-tenant application with Supabase Auth, RLS, and the admin dashboard. Then batch import all content, rewrite all media URLs, and map users to Supabase Auth with the correct per-location roles assigned.

Week 5-10

Redirect Mapping & Launch

Implement 301 redirects for every URL across all subsites and domain-mapped domains. DNS cutover per domain. GSC property updates. Monitor indexing across all former subsites for 30 days post-launch — long enough to catch anything that wants to surface late.

Week 10-12

Next.jsSupabaseVercelWP REST APIRow-Level SecuritySupabase Auth

Häufige Fragen

Warum ist die WordPress-Multisite-Migration schwieriger als eine Single-Site-Migration?

Hier ist das, was eine Multisite-Migration wirklich komplex macht: Jede Subsite hat ihre eigenen Datenbanktabellen mit Präfix (wp_2_posts, wp_3_options), aber alle teilen sich eine einzige wp_users-Tabelle mit pro-Site eingebauten Fähigkeiten. Medien befinden sich in separaten /sites/[id]/-Verzeichnissen. Serialisierte Daten enthalten überall im System verstreut domänenspezifische Referenzen. Eine Subsite zu extrahieren bedeutet, alle Präfix-Tabellen neu zuzuordnen, serialisierte Daten ohne Beschädigungen umzuschreiben, Medienpfade zu migrieren und DNS pro Domain zu handhaben — dann das Ganze wieder für jede Subsite im Netzwerk zu tun.

Können Sie Subsites mit benutzerdefinierten Domains migrieren?

Für Domain-zugeordnete Subsites handhaben wir den DNS-Cutover pro Domain, SSL-Zertifikatbereitstellung und Implementierung von 301-Weiterleitungen von der alten Domain zur neuen Pfadstruktur. Jede benutzerdefinierte Domain erhält eine eigene Google Search Console-Eigenschaft und dedizierte Indexierungsüberwachung. Wir koordinieren den Cutover-Zeitpunkt, um Ausfallzeiten über alle Domains hinweg zu minimieren — Versatz wo sinnvoll, Batches wo nicht.

Was passiert mit gemeinsamen Benutzern über Subsites hinweg?

WordPress Multisite speichert alle Benutzer in einer wp_users-Tabelle mit pro-Site Fähigkeiten wie wp_2_capabilities und wp_3_capabilities. Wir extrahieren die pro-Site Rollen jedes Benutzers, ordnen sie Supabase Auth zu und weisen lokationsspezifische Berechtigungen mit Row-Level Security zu. Das Ergebnis: eine einzige Anmeldung mit der richtigen Zugriffsstufe pro Standort, ohne dass jemand Inhalte sieht, die er nicht sehen sollte.

Werden wir während der Migration SEO-Rankings verlieren?

Wir erstellen 301-Redirect-Zuordnungen für jede URL über jede Subsite hinweg, einschließlich Domain-zugeordnete benutzerdefinierte Domains. Google Search Console-Eigenschaften werden pro Domain mit aktualisierten Sitemaps eingerichtet, die am Launch-Tag eingereicht werden. Wir überwachen die Indexierung für 30 Tage nach dem Launch über alle ehemaligen Subsites hinweg, um alles zu erfassen, das durchrutscht. Erwähnenswert: Der Performance-Sprung von statischem HTML hilft typischerweise eher den Rankings als ihnen zu schaden.

Wie lange dauert eine WordPress-Multisite-Migration?

Der Zeitrahmen skaliert mit der Netzwerkgröße. Ein Netzwerk mit 5–10 Subsites dauert normalerweise 8–10 Wochen. Netzwerke im Bereich von 25–50 Subsites laufen 12–16 Wochen. Enterprise-Netzwerke mit 50+ Subsites, komplexer Domain-Zuordnung und benutzerdefinierter Funktionalität können 16–24 Wochen dauern. Die Audit-Phase legt einen genauen Zeitrahmen für Ihr spezifisches Netzwerk fest — die obigen Zahlen sind Startpunkte, keine Garantien.

Welche Sicherheitsverbesserung gibt es nach der Migration von WordPress Multisite?

WordPress-Multisite-Netzwerke sind hochwertige Ziele, genau weil eine Plugin-Sicherheitslücke jede Subsite gleichzeitig trifft. Nach der Migration sind Ihre Sites vorgerendetes statisches HTML, das von einem CDN bereitgestellt wird — keine PHP-Runtime, keine Datenbank im Web exponiert, nichts, das ein Plugin-Exploit greifen kann. Die Angriffsfläche sinkt auf praktisch Null. Keine Wordfence-Warnungen mehr um 2 Uhr morgens. Keine Notfall-Patches mehr. Kein mehr Luft anhalten jedes Mal, wenn ein Plugin-Update herunterkommt.

Multisite Migration from $15,000

Priced by network size. 30-day post-launch monitoring included.

See all packages →

Multi-Site Website Platform WordPress to Next.js Migration WordPress Multisite to Next.js Next.js vs WordPress WordPress Multisite Is Not Multi-Site

Get Your Multisite Network Assessment

Tell us about your network. We'll deliver a migration plan and quote within 48 hours.

Get Your Network Assessment

Get in touch

Let's build
something together.

Whether it's a migration, a new build, or an SEO challenge — the Social Animal team would love to hear from you.

Get in touch →