WordPress zu Next.js Migration -- Social Animal

Ich habe über ein Dutzend WordPress-Seiten zu Next.js in der Produktion migriert, und ich erzähle dir etwas, das dich überraschen könnte: Die eigentliche Code-Migration ist nicht der schwierige Teil. Es ist der Cutover. Dieser angsteinflößende Moment, wenn du den Schalter umlegst und hoffst, dass nichts kaputt geht. Die gute Nachricht? Mit dem richtigen Playbook kannst du diesen Moment langweilig machen. Und in der Operationalisierung ist langweilig genau das, was du willst.

Dies ist das Playbook, das wir bei Social Animal für Production Cutovers verwenden. Es ist nicht theoretisch — es wurde aus echten Migrationen entwickelt, bei denen echte Einnahmen auf dem Spiel standen. Wir sprechen von E-Commerce-Seiten mit 50.000 $/Tag, Content-Publishern mit Millionen monatlicher Pageviews und SaaS-Marketing-Seiten, bei denen 5 Minuten Ausfallzeit bedeuten, dass der CEO deinen Handy anruft.

Inhaltsverzeichnis

Warum Zero Downtime mehr zählt, als du denkst
Übersicht der Migrationsarchitektur
Phase 1: Content-Migration und API-Layer
Phase 2: Next.js-Anwendung erstellen
Phase 3: Paralleles Deployment-Setup
Phase 4: Blue-Green-Deployment-Konfiguration
Phase 5: DNS-Switchover-Strategie
Phase 6: The Cutover Checklist
Phase 7: Überwachung nach dem Cutover und Rollback
Häufige Fehlermodi und deren Vermeidung
FAQ

Zero Downtime CMS Migration: WordPress zu Next.js Cutover Playbook

Warum Zero Downtime mehr zählt, als du denkst

Lass uns hier einige Zahlen einordnen. Googles Forschung aus 2024 zeigt, dass eine 1-Sekunden-Verzögerung beim Seitenladevorgang ungefähr 7% an Konversionen kostet. Stell dir nun vor, deine Seite ist einfach ... weg. Auch nur für 5 Minuten.

Hier ist das, was wirklich auf dem Spiel steht:

Ausfallzeit	Umsatzauswirkungen (für eine 10.000 $/Tag-Seite)	SEO-Auswirkung	Benutzervertrauens-Auswirkung
5 Minuten	~35 $ verloren	Minimal, wenn isoliert	Niedrig
30 Minuten	~208 $ verloren	Googlebot könnte es bemerken	Mittel
2 Stunden	~833 $ verloren	Crawl-Fehler in GSC	Hoch
24 Stunden	10.000 $+ verloren	Deindexierungsrisiko	Schwerwiegend

Aber es geht nicht nur um Umsatz. Suchmaschinen crawlen ständig. Wenn Googlebot deine Seite während einer Migration treffen und 500-Fehler erhalten, können diese URLs innerhalb von Stunden aus dem Index fallen. Ich habe Seiten gesehen, die 40% ihres organischen Traffics verloren haben, weil jemand eine "schnelle Migration" während der Mittagspause durchgeführt hat.

Das Ziel ist nicht nur Zero Downtime. Es ist, dass Benutzer und Crawler während des Übergangs null sichtbare Änderung sehen.

Übersicht der Migrationsarchitektur

Bevor wir zu den Phasen übergehen, schauen wir uns die Architektur an, auf die wir hinarbeiten. Das Fundamentalmuster besteht darin, beide Systeme parallel auszuführen und dann den Traffic atomar zu verlagern.

                    ┌─────────────────┐
                    │   Cloudflare /   │
                    │   Load Balancer  │
                    └────────┬────────┘
                             │
                    ┌────────┴────────┐
                    │  Traffic Router  │
                    │  (weight-based)  │
                    └────┬───────┬────┘
                         │       │
              ┌──────────┴──┐ ┌──┴──────────┐
              │  WordPress  │ │   Next.js   │
              │  (Blue)     │ │   (Green)   │
              │  Origin     │ │   on Vercel │
              └──────────┬──┘ └──┬──────────┘
                         │       │
              ┌──────────┴──┐ ┌──┴──────────┐
              │  MySQL DB   │ │ Headless CMS │
              │             │ │ (Sanity/etc) │
              └─────────────┘ └─────────────┘

Der Schlüsseleinsicht: Du migrierst nicht nur ein Frontend. Du migrierst den Content-Layer, den Rendering-Layer und den Delivery-Layer — und jeder kann unabhängig migriert werden.

Phase 1: Content-Migration und API-Layer

Hier machen die meisten Teams es falsch. Sie versuchen, zuerst das Next.js-Frontend zu bauen und den Content später zu klären. Tu das nicht. Fang mit dem Content an.

Wahl deines Headless CMS

Dein WordPress-Content braucht ein neues Zuhause. Die Wahl ist für die Migrationskomplexität sehr wichtig:

CMS	Migrationserleichterung von WP	Echtzeit-Sync möglich	Preisgestaltung (2025)	Best für
Sanity	Hoch (strukturierter Content funktioniert gut)	Ja, über Webhooks	Kostenlos, dann 99 $/Monat	Komplexe Content-Modelle
Contentful	Mittel (Feld-Mapping erforderlich)	Ja	300 $/Monat für Team	Enterprise-Teams
Strapi	Hoch (ähnliches datenbankgestütztes Modell)	Ja	Selbst gehostet kostenlos, Cloud ab 29 $/Monat	Vollständige Kontrolle
WordPress REST API	N/A (als Headless behalten)	Bereits synchronisiert	Vorhandene Hosting-Kosten	Schnelle Erfolge
Payload CMS	Hoch	Ja	Selbst gehostet kostenlos	Developer-First-Teams

Wir behandeln die Headless-CMS-Auswahl ausführlich auf unserer Seite mit Headless-CMS-Entwicklungsfähigkeiten, aber kurz gesagt: für die meisten WordPress-Migrationen geben dir Sanity oder Payload CMS den besten Migrationspfad.

Einrichtung von Content-Sync

Hier ist der kritische Teil: Während der parallelen Laufphase muss der Content in beiden Systemen vorhanden sein. Du hast zwei Strategien:

Strategie A: Einmalige Migration + Freeze Migriere alle Inhalte zum neuen CMS und dann friere WordPress-Bearbeitung ein. Dies funktioniert für kleine Seiten, bricht aber zusammen, wenn Redakteure weiterhin veröffentlichen müssen.

Strategie B: Kontinuierlicher Sync (empfohlen) Richte eine Sync-Pipeline ein, die WordPress-Änderungen in Echtzeit zu deinem neuen CMS repliziert.

// Beispiel: WordPress-Webhook-Handler, der zu Sanity synchronisiert
// Dies läuft als Serverless-Funktion (Vercel/AWS Lambda)

import { createClient } from '@sanity/client';

const sanity = createClient({
  projectId: process.env.SANITY_PROJECT_ID,
  dataset: 'production',
  token: process.env.SANITY_WRITE_TOKEN,
  apiVersion: '2025-01-01',
  useCdn: false,
});

export async function POST(request) {
  const payload = await request.json();
  const { post_id, post_title, post_content, post_status } = payload;

  if (post_status !== 'publish') return new Response('Skipped', { status: 200 });

  try {
    await sanity.createOrReplace({
      _id: `wp-${post_id}`,
      _type: 'post',
      title: post_title,
      body: convertGutenbergToPortableText(post_content),
      migratedFrom: 'wordpress',
      wpId: post_id,
      _updatedAt: new Date().toISOString(),
    });

    return new Response('Synced', { status: 200 });
  } catch (error) {
    console.error('Sync failed:', error);
    return new Response('Sync error', { status: 500 });
  }
}

Du brauchst auch die WordPress-Seite. Wir verwenden ein einfaches Plugin, das bei save_post ausgelöst wird:

// wp-content/plugins/headless-sync/headless-sync.php
add_action('save_post', function($post_id, $post) {
    if (wp_is_post_revision($post_id)) return;
    
    wp_remote_post(SYNC_ENDPOINT_URL, [
        'body' => json_encode([
            'post_id' => $post_id,
            'post_title' => $post->post_title,
            'post_content' => $post->post_content,
            'post_status' => $post->post_status,
        ]),
        'headers' => [
            'Content-Type' => 'application/json',
            'X-Sync-Secret' => SYNC_SECRET,
        ],
    ]);
}, 10, 2);

Führe diesen Sync mindestens 2 Wochen vor dem Cutover aus. Du möchtest Edge Cases erkennen — seltsame Shortcodes, benutzerdefinierte Post-Typen, ACF-Felder, die nicht sauber gemappt werden.

Zero Downtime CMS Migration: WordPress zu Next.js Cutover Playbook - Architektur

Phase 2: Next.js-Anwendung erstellen

Ich werde hier nicht den vollständigen Next.js-Build-Prozess abdecken — das verdient seinen eigenen Artikel (und wir haben tiefe Fachkenntnisse in der Next.js-Entwicklung). Aber es gibt migrationsspezifische Belange, die für Zero Downtime wichtig sind.

URL-Parität ist nicht verhandelbar

Jede einzelne URL, die auf deiner WordPress-Seite existiert, muss auf der gleichen Inhaltsseite auf deiner Next.js-Seite aufgelöst werden. Jede. Einzelne.

Das bedeutet:

/blog/my-post-slug/ muss funktionieren (einschließlich des nachstehenden Schrägstrichs, falls WordPress einen verwendet)
/category/technology/ muss funktionieren oder umleiten
/wp-content/uploads/2024/03/image.jpg muss zu deinem neuen Asset CDN umleiten
/feed/ muss immer noch gültige RSS/Atom zurückgeben
Paginierungs-URLs wie /blog/page/2/ müssen funktionieren

Baue ein URL-Audit-Skript früh:

# Exportiere alle WordPress-URLs mit WP-CLI
wp post list --post_type=post,page --post_status=publish \
  --fields=ID,post_name,post_type,guid --format=csv > urls.csv

# Hole auch Umleitungen von beliebigen SEO-Plugins
wp db query "SELECT * FROM wp_redirection_items" --format=csv > redirects.csv

Dann validiere sie gegen deinen Next.js-Build:

// validate-urls.mjs
import { readFileSync } from 'fs';
import { parse } from 'csv-parse/sync';

const urls = parse(readFileSync('./urls.csv'), { columns: true });
const NEXT_BASE = 'https://staging.yoursite.com';

for (const row of urls) {
  const res = await fetch(`${NEXT_BASE}/${row.post_name}/`, {
    redirect: 'manual'
  });
  
  if (res.status >= 400) {
    console.error(`BROKEN: /${row.post_name}/ → ${res.status}`);
  }
}

Performance-Baseline

Bevor cutover, muss deine Next.js-Seite mindestens so schnell sein wie WordPress. Klingt offensichtlich, aber ich habe Teams gesehen, die so begeistert vom neuen Stack waren, dass sie vergessen haben, Benchmarks durchzuführen.

Erfasse Core Web Vitals von deiner WordPress-Seite mit CrUX-Daten oder Lighthouse CI, und passe dich dann an oder übertreffe sie. Wenn deine WordPress-Seite eine LCP von 2,1s hat und deine Next.js-Seite bei 3,4s liegt, bist du nicht bereit.

Phase 3: Paralleles Deployment-Setup

Jetzt gelangen wir zur Infrastruktur, die Zero Downtime möglich macht.

Der parallele Lauf

Beide Systeme laufen gleichzeitig und bedienen echten Traffic. Aber nur einer ist zu einem bestimmten Zeitpunkt "primär".

Für Next.js auf Vercel (unser häufigste Setup) bereitest du deine Next.js-App auf einer benutzerdefinierten Domäne wie next.yoursite.com oder verwende Vercel's Preview-URL. Deine WordPress-Seite läuft weiterhin unter yoursite.com.

# Wenn du Nginx als Reverse Proxy verwendest
# Dies ist die parallele Run-Konfiguration

upstream wordpress {
    server wordpress-origin.internal:80;
}

upstream nextjs {
    server next-yoursite.vercel.app:443;
}

server {
    listen 443 ssl;
    server_name yoursite.com;

    # Während des Parallellaufs: Traffic zu beiden spiegeln,
    # aber Antworten von WordPress bedienen
    location / {
        mirror /mirror;
        proxy_pass http://wordpress;
    }

    location = /mirror {
        internal;
        proxy_pass https://nextjs$request_uri;
    }
}

Diese Mirror-Konfiguration sendet jede Anforderung an beide Backends, gibt aber nur die WordPress-Antwort zurück. Du erhältst echten Traffic, der deine Next.js-App trifft, ohne dass Benutzer sie sehen. Überprüfe deine Next.js-Protokolle auf Fehler, 404er und langsame Antworten.

Synthetische Überwachung

Richte eine Überwachung ein, die kontinuierlich validiert, dass beide Systeme äquivalenten Content zurückgeben:

// canary-check.mjs — läuft alle 5 Minuten über Cron
const CRITICAL_URLS = [
  '/',
  '/blog/',
  '/about/',
  '/contact/',
  '/blog/most-popular-post/',
];

for (const path of CRITICAL_URLS) {
  const [wpRes, nextRes] = await Promise.all([
    fetch(`https://yoursite.com${path}`),
    fetch(`https://next.yoursite.com${path}`),
  ]);

  if (wpRes.status !== nextRes.status) {
    alert(`Status mismatch on ${path}: WP=${wpRes.status} Next=${nextRes.status}`);
  }

  // Vergleiche Title Tags als Content-Parity-Check
  const wpTitle = (await wpRes.text()).match(/<title>(.*?)<\/title>/)?.[1];
  const nextTitle = (await nextRes.text()).match(/<title>(.*?)<\/title>/)?.[1];

  if (wpTitle !== nextTitle) {
    alert(`Title mismatch on ${path}`);
  }
}

Führe dies mindestens 1 Woche lang mit null Warnungen durch, bevor du zum Cutover übergehst.

Phase 4: Blue-Green-Deployment-Konfiguration

Blue-Green-Deployment bedeutet, zwei identische Produktionsumgebungen zu haben — Blue (aktuelles WordPress) und Green (neues Next.js) — und atomar zwischen ihnen zu wechseln.

Verwendung von Cloudflare Workers für Traffic-Routing

Dies ist unser bevorzugter Ansatz, da er Dir sofortiges, globales Traffic-Switching ohne DNS-Propagationsverzögerung gibt.

// Cloudflare Worker für Blue-Green-Routing
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    
    // Lese die aktive Umgebung aus dem KV-Store
    const activeEnv = await env.CONFIG.get('active_environment') || 'blue';
    
    // Optional: prozentbasiertes Canary-Routing
    const canaryPercent = parseInt(await env.CONFIG.get('canary_percent') || '0');
    const useGreen = activeEnv === 'green' || 
                     (canaryPercent > 0 && Math.random() * 100 < canaryPercent);
    
    const origin = useGreen
      ? 'https://next-yoursite.vercel.app'
      : 'https://wp-origin.yoursite.com';
    
    const originUrl = new URL(url.pathname + url.search, origin);
    
    const response = await fetch(originUrl, {
      method: request.method,
      headers: {
        ...Object.fromEntries(request.headers),
        'Host': new URL(origin).hostname,
        'X-Forwarded-Host': url.hostname,
      },
      body: request.method !== 'GET' ? request.body : undefined,
    });
    
    const newResponse = new Response(response.body, response);
    newResponse.headers.set('X-Served-By', useGreen ? 'green-nextjs' : 'blue-wordpress');
    
    return newResponse;
  }
};

Die Schönheit dieses Ansatzes: Der Wechsel von WordPress zu Next.js ist ein einzelnes KV-Store-Schreiben. Keine DNS-Änderungen. Keine Propagation. Sofort.

# Wechsel zu Green (Next.js)
curl -X PUT "https://api.cloudflare.com/client/v4/accounts/{account_id}/storage/kv/namespaces/{namespace_id}/values/active_environment" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  --data "green"

# Rollback zu Blue (WordPress), falls etwas schiefgeht
curl -X PUT "https://api.cloudflare.com/client/v4/accounts/{account_id}/storage/kv/namespaces/{namespace_id}/values/active_environment" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  --data "blue"

Canary-Routing

Leite nicht sofort 100% des Traffics um. Starten mit einem Canary:

1% Traffic zu Next.js — Beobachte für Fehler 1 Stunde
10% Traffic — Überwache für 2 Stunden
50% Traffic — Überwache für 4 Stunden
100% Traffic — Überwache für 24 Stunden
WordPress außer Betrieb nehmen — Nach 1 Woche bei 100%

Phase 5: DNS-Switchover-Strategie

Wenn du Cloudflare Workers nicht verwenden kannst (oder eine ähnliche Edge-Routing-Lösung), musst du den Switchover auf der DNS-Ebene durchführen. Dies ist kniffliger wegen der TTL-Propagation.

Vorbereitung vor dem Cutover DNS

Mindestens 48 Stunden vor dem Cutover:

Senke deine DNS-TTL auf 60 Sekunden (vom typischen 3600 oder 86400)
Warte, bis die alte TTL abläuft
Verifikiere, dass die niedrige TTL aktiv ist: dig yoursite.com +short sollte TTL ~60 anzeigen

# Überprüfe die aktuelle TTL
dig yoursite.com A +noall +answer
# Sollte etwa folgendes anzeigen:
# yoursite.com.  60  IN  A  76.76.21.21

Der DNS-Switch

Mit einer TTL von 60 Sekunden bedeutet die Aktualisierung deines DNS-A/CNAME-Records eine globale Propagation in etwa 5-10 Minuten (einige Resolver ignorieren niedrige TTLs, aber die meisten respektieren sie in 2025).

# Wenn zu Vercel umzuziehen
# Aktualisiere CNAME, um auf cname.vercel-dns.com zu zeigen
# Oder aktualisiere A-Records auf Vercels IP-Adressen: 76.76.21.21

Die Gotcha: SSL-Zertifikat-Timing

Hier ist etwas, das Menschen beißt. Wenn du DNS zu Vercel umschaltest (oder einen neuen Host), muss das SSL-Zertifikat für deine Domain auf dem neuen Host bevor der Switch bereitgestellt werden. Sonst bekommst du ein Fenster, in dem HTTPS nicht funktioniert.

Auf Vercel, füge deine benutzerdefinierte Domain in den Projekteinstellungen vor dem DNS-Switch hinzu. Vercel wird versuchen, das Cert über HTTP-01 oder DNS-01-Challenge bereitzustellen. Wenn du dein DNS mit Cloudflare proxyed, musst du möglicherweise den Proxy vorübergehend deaktivieren (orange Cloud → grau Cloud), damit die Cert-Bereitstellung funktioniert.

Phase 6: The Cutover Checklist

Dies ist die Checkliste, die wir am Cutover-Tag verwenden. Drucke sie aus. Überprüfe jede Box.

Vor dem Cutover (T-24 Stunden)

Alle Inhalte synchronisiert und im neuen CMS verifiziert
URL-Parity-Validierung besteht zu 100%
SSL-Zertifikat auf neuem Host bereitgestellt
DNS-TTL bestätigt bei 60 Sekunden
Rollback-Verfahren dokumentiert und getestet
Alle Umleitungen des WordPress-SEO-Plugin zu next.config.js oder Edge-Middleware migriert
robots.txt und sitemap.xml generieren korrekt auf Next.js
Analytics-Tracking auf Next.js verifiziert (GA4, GTM, usw.)
Formularübermittlungen End-to-End getestet
RSS-Feed validiert
OpenGraph-Tags auf Schlüsselseiten verifiziert
404-Seite getestet

Cutover (T-0)

Benachrichtige Stakeholder: "Migration wird gestartet"
Stelle Canary auf 1% → Überwache 30 min
Erhöhe auf 10% → Überwache 1 Stunde
Überprüfe Google Search Console auf Crawl-Fehler
Erhöhe auf 50% → Überwache 2 Stunden
Erhöhe auf 100%
Übermittle aktualisierte Sitemap zu Google Search Console
Verifiziere, dass Googlebot auf alle kritischen Seiten zugreifen kann (verwende URL-Inspektion Tool)
Teste alle Formen, E-Commerce-Flüsse, Auth-Flüsse

Nach dem Cutover (T+24 Stunden)

Überwache Core Web Vitals im CrUX-Dashboard
Überprüfe Google Search Console auf Coverage-Probleme
Verifiziere, dass alle Analytics-Daten korrekt fließen
WordPress-Origin läuft immer noch (mindestens 2 Wochen halten)
Führe Full-Site-Crawl mit Screaming Frog gegen neue Seite aus

Phase 7: Überwachung nach dem Cutover und Rollback

Was man überwachen sollte

Richte Dashboards in deinem Monitoring-Tool ein (wir verwenden eine Kombination aus Vercel Analytics, Datadog und Google Search Console), die folgendes überwachen:

Fehlerquoten: Gibt es 5xx-Antworten? Gibt es einen Anstieg in 4xx?
Antwortzeiten: P50, P95, P99 Latenz
Core Web Vitals: LCP, FID/INP, CLS
Search Console: Crawl-Statistiken, Coverage-Bericht, Indexierungsstatus
Geschäftsmetriken: Konversionsrate, Absprungquote, Seiten/Sitzung

Der Rollback-Plan

Dein Rollback muss ein einzelner Befehl sein. Nicht ein 15-Schritte-Prozess. Ein Befehl.

Mit dem Cloudflare Worker-Ansatz:

# Ein-Befehl-Rollback
wrangler kv:key put --namespace-id=$NS_ID "active_environment" "blue"

Mit DNS-basiertem Switching:

# Pre-gescripteter DNS-Rollback über Cloudflare API
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records/{record_id}" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"content": "old-wordpress-ip-address"}'

Lasse WordPress mindestens 2 Wochen nach dem Cutover laufen. Sei kein Held. Der Moment, in dem du WordPress außer Betrieb nimmst, ist der Moment, in dem du eine Seite entdeckst, die du vergessen hast zu migrieren.

Häufige Fehlermodi und deren Vermeidung

Nach Dutzenden dieser Durchführungen sind hier die Ausfälle, die ich am häufigsten sehe:

1. Vergessene WordPress-Plugins mit Frontend-Routes Dieses Kontaktformular-Plugin erstellt /wp-json/contact-form-7/-Endpunkte. Diese WooCommerce-Installation hat /my-account/ und /cart/. Mappe jeden URL-Fußabdruck des Plugins.

2. Hardcodierte wp-content URLs in Content Bilder in deinem Content referenzieren /wp-content/uploads/. Du brauchst Umleitungen oder eine Rewrite-Regel, die diese zu deinem neuen Asset CDN führt.

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/wp-content/uploads/:path*',
        destination: 'https://cdn.yoursite.com/uploads/:path*',
        permanent: true,
      },
    ];
  },
};

3. Vergessen von XML-Sitemaps Google Search Console ist auf /sitemap.xml gezeigt. Deine Next.js-App muss eine generieren. Verwende next-sitemap oder baue es in deine App-Route-Handler.

4. Authentifizierungs- und Sitzungsprobleme Wenn deine WordPress-Seite angemeldete Benutzer hat, funktionieren ihre Cookies nicht im neuen Stack. Plane die Benutzermigration separat.

5. CDN-Cache-Vergiftung während des Übergangs Wenn Cloudflare Antworten cached, könntest du veraltete WordPress-Seiten bedienen, nachdem du zu Next.js wechselst. Bereinige den CDN-Cache unmittelbar nach dem Switch.

# Bereinige den gesamten Cloudflare-Cache nach dem Switch
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything": true}'

Wenn du eine Migration planst und möchtest, dass Experten die schwere Arbeit leisten, schaue dir unsere Pricing-Seite an oder kontaktiere uns direkt. Wir haben dies oft genug getan, dass unsere Playbooks in allen richtigen Wegen kampferprobt sind.

Für Seiten, die mit anderen Frameworks erstellt wurden, tun wir auch Astro-basierte Migrationen, die für inhaltsreiche Seiten, die nicht viel Interaktivität brauchen, sogar noch schneller sein können.

FAQ

Wie lange dauert eine WordPress zu Next.js Migration typischerweise?

Für eine Seite mit mittlerer Komplexität (100-500 Seiten, benutzerdefinierte Post-Typen, einige dynamische Funktionalität), plane 8-12 Wochen Ende-zu-Ende. Die Content-Migration und parallele Run-Phase dauert allein 3-4 Wochen. Der eigentliche Cutover dauert, wenn du die Vorbereitungsarbeiten gemacht hast, etwa 4 Stunden aktiver Arbeit. Lass dich nicht von jemandem sagen, dass dies in einem Wochenende möglich ist.

Kann ich WordPress als Headless CMS verwenden, anstatt Content zu migrieren?

Absolut, und für einige Teams ist dies der richtige Anruf. Du behältst WordPress als dein CMS, verwendest die REST API oder WPGraphQL, um Content an Next.js zu servieren, und migrierst nur das Frontend. Dies verkürzt die Migrations-Timeline erheblich, da du die Content-Migrations-Phase ganz überspringst. Der Tradeoff ist, dass du immer noch eine WordPress-Installation mit dem ganzen Updat- und Sicherheitsoverhead wartest.

Was passiert mit meinen SEO-Rankings während einer Migration?

Bei einer ordnungsgemäßen Zero-Downtime-Migration sollten deine Rankings stabil bleiben. Googles John Mueller hat bestätigt, dass ein Wechsel deines CMS die Rankings nicht beeinflussen sollte, wenn der Content, die URLs und die technischen SEO-Elemente äquivalent bleiben. Die größten Risiken sind fehlerhafte URLs (die 404er verursachen), geänderte interne Verlinkungsstrukturen und beeinträchtigte Seitengeschwindigkeit. Unser Playbook behandelt alle drei speziell.

Wie gehe ich mit WordPress-Formularen in Next.js um?

Du hast mehrere Optionen: Verwende einen Formularservice wie Formspree oder Basin, baue API-Routes in Next.js, die Übermittlungen direkt verarbeiten, oder verwende die Formularfunktionen deines Headless CMS (Sanity hat keine nativen Formen, aber Payload CMS hat sie). Für komplexe Formen mit bedingter Logik bauen wir typischerweise benutzerdefinierte API-Routes und verwenden React Hook Form auf dem Frontend.

Sollte ich Vercel, Netlify oder Self-Host für das Next.js-Deployment verwenden?

Für die meisten Teams ist Vercel der Weg der geringsten Widerstände für Next.js. Es wird von demselben Team gebaut, und Features wie ISR, Middleware und Image-Optimierung funktionieren dort am besten. Vercels Pro-Plan bei 20 $/Benutzer/Monat deckt die meisten Produktionsanforderungen ab. Wenn du spezifische Compliance-Anforderungen hast oder auf AWS bleiben musst, kannst du mit dem standalone-Ausgabemodus selbst hosten. Netlify funktioniert auch, aber hat historisch bei der Next.js-Feature-Unterstützung hinterhergehinkt.

Was ist der Unterschied zwischen Blue-Green-Deployment und Canary-Deployment?

Blue-Green ist binär: Der gesamte Traffic geht entweder zum alten System (Blau) oder zum neuen (Grün). Canary-Deployment verlagert schrittweise einen Prozentsatz des Traffics vom alten zum neuen. In der Praxis kombinieren wir beides. Wir richten Blue-Green-Infrastruktur auf (zwei vollständige Umgebungen), verwenden aber während des eigentlichen Switchovers ein Canary-ähnliches prozentbasiertes Routing. Dies gibt dir die Sicherheit eines schrittweisen Rollouts mit der Einfachheit, nur zwei Umgebungen zu verwalten.

Wie migriere ich WordPress-Umleitungen zu Next.js?

Exportiere deine Umleitungen aus deinem WordPress-Plugin (Redirection, Yoast, RankMath). Konvertiere sie in das Next.js-Umleitungsformat in next.config.js. Für Seiten mit hunderten Umleitungen verwende stattdessen Middleware — sie ist performanter und kann Pattern-Matching verarbeiten. Bedenke, dass next.config.js Umleitungen ein praktisches Limit von etwa 1.000 Einträgen auf Vercel haben, bevor Build-Zeiten leiden.

Kann ich nach dem Cutover zu WordPress zurückrollen, falls etwas schiefgeht?

Ja, und dies ist nicht verhandelbar. Lasse deine WordPress-Instanz mindestens 2 Wochen nach dem Cutover laufen. Mit dem in diesem Artikel beschriebenen Cloudflare Worker-Ansatz ist das Rollback ein einzelner API-Anruf, der weltweit innerhalb von Sekunden wirksam wird. Mit DNS-basiertem Switching dauert das Rollback 1-10 Minuten, abhängig von TTL-Propagation. Dekomissioniere das alte System nie, bis du sicher bist, dass das neue stabil ist.