Ihr Dev-Team öffnet das WordPress-Admin und exportiert 847 Beiträge, 12 Custom Post Types und 3.200 Media Assets. Der Datenbankdump ist 4,2 GB groß. Jemand fragt, wie lange diese Migration wirklich dauert – nicht die geschönte Schätzung aus der Kickoff-Präsentation, sondern der Zeitplan, der für kaputte Shortcodes, ACF-Feldkonflikte und die Redirect-Map berücksichtigt, die sich von 200 auf 1.800 Zeilen in Woche zwei vergrößert. Ich habe über fünf Jahre 40+ CMS-Migrationen geleitet, die meisten von WordPress zu Next.js. Die Antwort hängt von vier Variablen ab, die die meisten Agenturen erst erwähnen, wenn Sie bereits unterschrieben haben. Hier ist, was wirklich bestimmt, ob Sie in 3 Wochen oder 6 Monaten starten.

Ein kleines Marketing-Site? Sie sind bei 3–6 Wochen. Eine mittelständische Unternehmensseite mit Blog, E-Commerce und Custom Integrations? Planen Sie 2–4 Monate ein. Ein Enterprise mit 10.000+ Seiten, mehrsprachig und Legacy-Systemen? Schnallen Sie sich an für 4–8 Monate.

Aber diese Spannweiten sind sinnlos ohne Kontext. Ich breche auf, was genau in jeder Phase passiert, wo Teams Zeit verlieren und wie Sie Ihre Migration davon abhält, zu einer dieser Horror-Geschichten zu werden, die sich über ein Jahr hinziehen.

Inhaltsverzeichnis

CMS-Migration: WordPress zu Next.js 2026

Warum von WordPress zu Next.js 2026 migrieren?

Lasst mich deutlich sein: Nicht jede WordPress-Site muss migriert werden. Wenn Sie einen persönlichen Blog oder eine kleine Geschäftsseite betreiben, die gut funktioniert, ist WordPress immer noch vollkommen in Ordnung. Aber es gibt echte, messbare Gründe, warum Teams 2026 zu Next.js mit einem Headless CMS wechseln:

  • Performance: Next.js-Sites mit statischer Generierung und Edge-Rendering erreichen konsistent 90+ bei Core Web Vitals. WordPress-Sites liegen durchschnittlich bei 50–65 ohne erhebliche Optimierungsarbeit.
  • Sicherheit: Die Entkopplung des Frontend vom CMS eliminiert die häufigsten WordPress-Angriffsvektoren. 2025 meldete Sucuri, dass WordPress 96,2 % der infizierten CMS-Sites ausmachte.
  • Developer Experience: React-basierte Komponentenarchitektur bedeutet schnellere Iteration und leichtere Personaleinstellung. Der WordPress-PHP-Talentpool schrumpft – Stack Overflows 2025-Umfrage zeigte PHP auf Platz 14 in der Sprachenpopularität.
  • Skalierbarkeit: Im Edge deployete Next.js-Sites auf Vercel oder Cloudflare bewältigen Traffic-Spitzen ohne den Ansatz "lasst uns einfach mehr Server hinzufügen".

Wenn Sie mit Performance-Problemen, Sicherheitsbedenken oder einem Dev-Team, das sich scheut, WordPress zu berühren, kämpfen, macht Migration Sinn. Wir behandeln den technischen Ansatz im Detail auf unserer Seite Next.js Entwicklungsmöglichkeiten.

Migrations-Zeitplan nach Site-Größe

Hier ist die ehrliche Aufschlüsselung. Diese Zeitpläne gehen von einem dedizierten Team (nicht Leute, die sich Zeit mit anderen Projekten teilen) und vergleichsweise responsiven Stakeholdern aus.

Site-Größe Seiten Typische Komplexität Zeitplan Team-Größe
Klein (Marketing/Broschüre) 5–50 Niedrig – wenige Integrationen, Standard-Content 3–6 Wochen 2–3 Personen
Mittel (Geschäft) 50–500 Mittel – Blog, Formulare, einige Integrationen, mehrere Templates 8–16 Wochen 3–5 Personen
Groß (Mittelständler) 500–5.000 Hoch – E-Commerce, Multi-Author, komplexe Workflows 3–5 Monate 4–7 Personen
Enterprise 5.000+ Sehr Hoch – mehrsprachig, Legacy-Integrationen, Compliance 4–8 Monate 6–12 Personen

Das sind Build-Zeitpläne, keine Kalender-Zeitpläne. Kalenderzeit ist immer länger, wegen Stakeholder-Reviews, Feedback-Schleifen und die unvermeidlichen zwei Wochen, in denen der VP of Marketing im Urlaub ist während der Design-Genehmigungsphase.

Phase 1: Discovery und Audit

Dauer: 1–3 Wochen

Hier beeilen sich die meisten Agenturen und die meisten Migrationen gehen schief. Discovery ist nicht nur "schau dir die WordPress-Site an und mach eine Liste". Es ist forensische Arbeit.

Was wirklich passiert

  • Content-Inventar: Katalogisiere jeden Content Type, jede Taxonomie, jedes Custom Field und jeden Media Asset. Ich verwende Screaming Frog, um die bestehende Site zu crawlen und eine vollständige URL-Map zu exportieren. Bei einer 2.000-Seiten-Site dauert das allein einen ganzen Tag zum ordentlichen Organisieren.
  • Plugin-Audit: Dokumentiere jedes aktive Plugin und was es macht. Die durchschnittliche WordPress-Site hat 20–30 Plugins. Jeder stellt Funktionalität dar, die Sie entweder replizieren, mit einem SaaS-Tool ersetzen oder bewusst weglassen müssen.
  • Integration-Mapping: Formulare gehen zu HubSpot? Payment Processing über WooCommerce? Analytics über Google Tag Manager mit Custom Events? Zeichnen Sie das vollständige Bild.
  • SEO-Basis: Exportiere alle Meta Titles, Descriptions, Canonical URLs, Structured Data und interne Verlinkungsmuster. Sie können sich nicht leisten, SEO-Eigenkapital während der Migration zu verlieren.
  • Stakeholder-Interviews: Sprich mit den Leuten, die das CMS täglich nutzen. Content-Editoren, Marketer, wer den Blog verwaltet. Ihre Workflows sind wichtiger als die technische Architektur.

Discovery-Ergebnisse

  • Content Model Dokument
  • Integration Dependency Map
  • SEO Migration Plan
  • Risk Register (Dinge, die den Zeitplan sprengen könnten)
  • Vorläufige Architektur-Empfehlung

Discovery zu überspringen oder zu beeilen ist die Nummer-Eins-Ursache für Zeitplan-Blowouts. Ich habe gesehen, wie eine "schnelle 6-Wochen-Migration" zu einer 5-Monats-Odyssee wurde, weil niemand dokumentiert hatte, dass die WordPress-Site 47 Custom Gravity Forms mit bedingter Logik hatte, die Daten in drei verschiedene CRMs piped.

CMS-Migration: WordPress zu Next.js 2026 – Architektur

Phase 2: Architektur und Planung

Dauer: 1–2 Wochen

Mit Discovery-Daten in der Hand treffen Sie die großen Entscheidungen.

Wahl Ihres Headless CMS

Next.js ist dein Frontend-Framework, aber du brauchst immer noch ein Content Management Backend. Die Top-Optionen 2026:

CMS Best For Preisgestaltung (2026) Lernkurve
Sanity Komplexe Content Models, Echtzeit-Zusammenarbeit Kostenlos, dann €99–€949/Mo Moderat
Contentful Enterprise-Teams, starke Governance €300/Mo und höher Moderat
Storyblok Visuelles Editing, Marketing-Teams Kostenlos, dann €106–€399/Mo Niedrig
Payload CMS Developer-First, Self-Hosted Kontrolle Kostenlos (Open Source), Cloud ab €50/Mo Höher
WordPress (Headless) Teams, die WordPress Admin behalten möchten Bestehende Hosting-Kosten Niedrig (vertraut)

Ja, Sie können WordPress als Headless CMS mit WPGraphQL oder der REST API verwenden. Manche Teams machen das, um ihre Content-Editoren in einer vertrauten Umgebung zu halten, während sie Next.js im Frontend bekommen. Das ist ein gültiger Ansatz, obwohl Sie einigen WordPress-Wartungsaufwand erben.

Wir helfen Teams bei der Evaluierung dieser Optionen als Teil unserer Headless-CMS-Entwicklung. Die richtige Wahl hängt stark vom technischen Komfort Ihres Editorial-Teams ab.

Architektur-Entscheidungen

  • Rendering-Strategie: Static Site Generation (SSG), Incremental Static Regeneration (ISR) oder Server-Side Rendering (SSR)? Die meisten Sites 2026 verwenden ein Hybrid – ISR für Content-Seiten, SSR für personalisierte oder Echtzeit-Seiten.
  • Hosting: Vercel ist der Standard für Next.js, aber Netlify, Cloudflare Pages und AWS Amplify sind alle lebensfähig. Vercels Pro-Plan mit €20/User/Mo deckt die meisten Teams ab.
  • API-Architektur: Werden Sie die native API des CMS verwenden, eine Middleware-Schicht bauen oder mit etwas wie tRPC für Type-sichere API-Aufrufe gehen?
  • Authentifizierung: Falls Sie Gated Content oder Member-Bereiche haben, planen Sie dies früh. NextAuth.js (jetzt Auth.js v5) handhaben die meisten Muster.

Phase 3: Content Modeling und CMS-Setup

Dauer: 1–3 Wochen

Hier bauen Sie Ihre Content-Struktur im neuen CMS. Replizieren Sie einfach nicht Ihre WordPress-Struktur – das ist Ihre Chance, Jahre angesammelter Content-Schulden zu beheben.

Content Model Design

WordPress neigt zu einem flachen Content Model: Posts, Pages und ein Durcheinander von Custom Fields via ACF oder Meta Box. Ein Headless CMS lässt Sie in strukturiertem Content denken.

// Beispiel: Blog Post Content Model in Sanity
export default defineType({
  name: 'blogPost',
  title: 'Blog Post',
  type: 'document',
  fields: [
    defineField({
      name: 'title',
      type: 'string',
      validation: (Rule) => Rule.required().max(70),
    }),
    defineField({
      name: 'slug',
      type: 'slug',
      options: { source: 'title' },
    }),
    defineField({
      name: 'author',
      type: 'reference',
      to: [{ type: 'author' }],
    }),
    defineField({
      name: 'body',
      type: 'portableText', // Rich strukturierter Content
    }),
    defineField({
      name: 'seo',
      type: 'seoFields', // Wiederverwendbares SEO-Objekt
    }),
  ],
})

Strukturierter Content bedeutet, dass Ihr Blog Post Body keine Blob aus HTML ist. Es sind strukturierte Blöcke, die Ihr Frontend beliebig rendern kann – Web, Mobile App, E-Mail Newsletter, was auch immer.

CMS-Konfiguration

  • Rollen und Berechtigungen einrichten
  • Vorschaufunktionalität konfigurieren (Live Preview in Next.js ist essentiell für Editor-Adoption)
  • Custom Input Components oder Validierungsregeln bauen
  • Webhooks für das Auslösen von Rebuilds bei Content-Änderungen einrichten

Phase 4: Frontend-Build

Dauer: 2–8 Wochen (die größte Variable)

Hier geht die meiste Kalenderzeit hin. Der Next.js Frontend-Build beinhaltet:

Design und Komponenten-System

Wenn Sie während der Migration redesignen (was etwa 70 % unserer Clients machen), addieren Sie 2–4 Wochen. Wenn Sie das bestehende Design replizieren, können Sie schneller gehen.

// Komponentengesteuerte Architektur Beispiel
export default function BlogPost({ post }: { post: BlogPostType }) {
  return (
    <article>
      <PageHeader title={post.title} date={post.publishedAt} />
      <AuthorCard author={post.author} />
      <PortableText 
        value={post.body} 
        components={customComponents} 
      />
      <RelatedPosts posts={post.related} />
      <NewsletterSignup />
    </article>
  )
}

Ich empfehle stark, zuerst eine Component Library zu bauen, dann Seiten zu assemblieren. Es fühlt sich zunächst langsamer an, zahlt sich aber massiv aus, wenn Sie Ihr 15. Page Template bauen.

Wichtige Build-Aufgaben

  • Page Templates für jeden Content Type
  • Dynamisches Routing und Catch-All Routes
  • Navigation (einschließlich Mega Menus wenn applicable)
  • Such-Funktionalität (Algolia, Meilisearch oder Next.js Built-in)
  • Form Implementierungen (Gravity Forms, Contact Form 7, usw. ersetzen)
  • Drittanbieter-Integrationen (Analytics, Chat Widgets, CRM-Verbindungen)
  • Bild-Optimierung (Next.js Image Component mit Ihrem CMS Image CDN)
  • Sitemap-Generierung
  • RSS-Feeds
  • 301 Redirect-Mapping

Die Redirect-Map allein kann Tage dauern bei einer großen Site. Jede URL, die sich ändert, braucht einen Redirect, sonst werfen Sie SEO-Eigenkapital weg.

Phase 5: Content-Migration

Dauer: 1–4 Wochen

Content-Migration ist entweder trivial einfach oder albtraumhaft komplex. Es gibt keinen Mittelweg.

Automatisierte Migration

Für strukturierten Content (Blog Posts, Produkte, Team Member), schreiben Sie Migration-Skripte:

// Vereinfachte WordPress zu Sanity Migration Script
import { createClient } from '@sanity/client'
import { wpClient } from './wordpress-api'

const sanity = createClient({
  projectId: 'your-project',
  dataset: 'production',
  token: process.env.SANITY_WRITE_TOKEN,
  apiVersion: '2026-01-01',
})

async function migratePosts() {
  const wpPosts = await wpClient.posts().perPage(100).get()
  
  for (const post of wpPosts) {
    await sanity.create({
      _type: 'blogPost',
      title: post.title.rendered,
      slug: { current: post.slug },
      // Transform WordPress HTML zu Portable Text
      body: htmlToPortableText(post.content.rendered),
      publishedAt: post.date,
    })
  }
}

Der htmlToPortableText Schritt ist, wo es haarig wird. WordPress Content ist voll von Shortcodes, Inline-Styles und Plugin-spezifischem Markup, das nicht saubervoll zu strukturiertem Content mapped. Budget Zeit für Cleanup.

Manuelle Content-Arbeit

Etwas Content braucht menschliche Aufmerksamkeit:

  • Seiten mit komplexen Layouts gebaut in Elementor, Divi oder WPBakery
  • Content mit eingebetteten Shortcodes von deaktivierten Plugins
  • Media, die Neuoptimierung oder Alt Text braucht
  • Interne Links, die Aktualisierung brauchen

Bei einer 500-Seiten-Site planen Sie 40–80 Stunden manuelle Content-Arbeit. Ja, wirklich.

Phase 6: QA und Testing

Dauer: 1–3 Wochen

Shortshoppen Sie das nicht. Ich habe Launches gesehen, die Monate verzögert wurden, weil QA als Nachgedanke behandelt wurde.

QA Checkliste

  • Functional Testing: Jedes Formular, jedes interaktive Element, jede dynamische Feature
  • Cross-Browser Testing: Chrome, Firefox, Safari, Edge. Safari hat immer etwas Seltsames.
  • Mobile Testing: Echte Geräte, nicht nur Chrome DevTools. Testen Sie auf echten iPhones und Android-Geräten.
  • Content-Verifikation: Spot-Check mindestens 20 % des migrierten Content auf Formatierungsprobleme
  • SEO Audit: Vergleichen Sie alte Meta Tags mit neuen. Verifizie Structured Data. Testen Sie alle Redirects.
  • Performance Testing: Lighthouse Scores, Core Web Vitals im Feld, Load Testing mit Tools wie k6
  • Accessibility: WCAG 2.2 AA Compliance. Führen Sie axe-core aus, aber machen Sie auch Keyboard-Only Navigation Testing.
  • Analytics-Verifikation: Stellen Sie sicher, dass Tracking auf allen Events richtig feuert

Redirect Testing

Das verdient seinen eigenen Callout. Exportieren Sie jede URL von der alten Site. Mappen Sie jede zur neuen URL. Testen Sie jeden Single Redirect. Für Enterprise-Sites mit tausenden URLs, verwenden Sie automatisiertes Testing:

# Test Redirects mit curl
while IFS=, read -r old_url new_url; do
  status=$(curl -o /dev/null -s -w "%{http_code}" -L "$old_url")
  final=$(curl -o /dev/null -s -w "%{url_effective}" -L "$old_url")
  echo "$old_url -> $final (Status: $status)"
done < redirects.csv

Phase 7: Launch und Post-Launch

Dauer: 1–2 Wochen

Launch Day

Ich bevorzuge Launches am Dienstag oder Mittwoch morgens. Niemals Freitag (Sie wollen nicht übers Wochenende debuggen) und niemals Montag (Leute sind noch am Aufholen vom Wochenende).

Launch Checkliste:

  • DNS-Änderungen (TTL sollte 48 Stunden vorher gesenkt werden)
  • SSL-Zertifikat-Verifikation
  • CDN Cache Warming
  • Monitor Error Rates für die ersten 4 Stunden
  • Verifizie Google Search Console auf Crawl-Fehler
  • Überprüfe alle Drittanbieter-Integrationen feuern

Post-Launch (2 Wochen)

  • Monitor Core Web Vitals in Google Search Console
  • Schaue nach 404-Fehler und addiere fehlende Redirects
  • Tracke Organic Search Performance täglich für den ersten Monat
  • Sammle Feedback von Content-Editoren auf dem neuen CMS
  • Adressiere alle Edge Cases, die QA entglitten sind

Ein temporärer Traffic-Rückgang von 5–15 % in Organic Search ist normal nach einer großen Migration. Es sollte sich innerhalb von 2–4 Wochen erholen, wenn Ihre Redirects und SEO korrekt handheben werden. Falls es nicht recovered, ist etwas mit der Redirect-Map oder Content-Parität schief.

Häufige Verzögerungen und wie man sie vermeidet

Nach dutzenden Migrationen, hier sind die echten Timeline Killer:

Scope Creep während Build: "Während wir dabei sind, können wir auch ein Customer Portal adden?" Ja, aber das ist ein separates Projekt. Scope Creep addiert durchschnittlich 3–6 Wochen zu Migrationen.

Stakeholder Verfügbarkeit: Design Reviews, die in jemandem Posteingang für zwei Wochen liegen. Budget Kalenderzeit entsprechend und set klare SLAs für Feedback Runden.

Plugin-Funktionslücken: Dieses obskure WordPress Plugin, das etwas Kritisches tut, das niemand dokumentiert hat. Discovery sollte das catchen, aber manchmal schlüpft etwas durch.

Content-Editor Training: Wenn Ihr Team das neue CMS nicht nutzen kann, haben Sie die Migration nicht fertig. Budget 1–2 Tage für Training und Dokumentation.

Perfektionismus bei Content-Migration: Manche Content ist es nicht wert zu migrieren. Blog Posts von 2014 mit Zero Traffic? Lass sie gehen. Setz einen Redirect zum Blog Index und moves weiter.

Kostenerwartungen 2026

Lasst mich Sie ehrliche Zahlen geben. Agency Rates für diese Arbeit 2026:

Site-Größe Zeitplan Geschätzte Kosten (Agency) Geschätzte Kosten (Freelancer)
Klein 3–6 Wochen €15.000–€35.000 €8.000–€18.000
Mittel 8–16 Wochen €40.000–€90.000 €25.000–€55.000
Groß 3–5 Monate €80.000–€200.000 €50.000–€120.000
Enterprise 4–8 Monate €150.000–€500.000+ Selten angemessen

Diese Spannweiten reflektieren, was wir am Markt gesehen haben. Die Varianz ist riesig, weil "mittlere Site" sehr unterschiedliche Dinge bedeuten kann. Eine 200-Seiten-Site mit einem einfachen Blog und Kontaktformular ist sehr anders von einer 200-Seiten-Site mit multilingualen Content, E-Commerce und Membership Portal.

Wenn Sie Ihre spezifische Situation besprechen möchten, outlines unsere Pricing-Seite unsere Engagement-Modelle, oder Sie können direkt Kontakt aufnehmen für eine scoped Schätzung.

FAQ

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

Eine kleine Marketing-Site (unter 50 Seiten) mit Standard Content Types und minimalen Integrationen braucht typischerweise 3–6 Wochen von Kickoff zum Launch. Das geht von einem Team von 2–3 Entwickler aus, die ohne Major Design Changes arbeiten. Falls Sie auch redesignen, addieren Sie 2–3 Wochen für die Design-Phase.

Kann ich von WordPress zu Next.js migrieren ohne SEO-Rankings zu verlieren?

Absoluut, aber es erfordert sorgfältige Planung. Die kritischen Elemente sind: URL-Strukturen beibehalten wo möglich, 301 Redirects für jede URL, die sich ändert, implementieren, alle Meta Tags und Structured Data bewahren und sicherstellen, dass die neue Site Content Parity mit der alten hat. Ein temporärer Rückgang von 5–15 % in Organic Traffic ist normal und sollte sich innerhalb von 2–4 Wochen erholen. Der größte Risikofaktor sind fehlende Redirects – eine verpfuschte Redirect-Map kann einen Abschnitt Ihres Site Traffic tanken.

Sollte ich WordPress als Headless CMS mit Next.js verwenden oder komplett zu einem anderen CMS wechseln?

Es hängt von Ihrem Team ab. Falls Ihre Content-Editoren tief in WordPress vertraut sind und Änderungen widerstrebend, ist Headless WordPress mit WPGraphQL ein vernünftiger Middle Ground. Sie bekommen die Next.js Frontend Vorteile während Sie die vertraute Admin-Interface behalten. Allerdings tragen Sie immer noch WordPress Wartung-Burden (Updates, Sicherheit Patches, Hosting). Falls Sie für Change offen sind, Purpose-Built Headless CMSes wie Sanity, Contentful oder Storyblok offer bessere structured Content, Real-Time Collaboration und weniger Operational Overhead.

Was sind die größten Risiken während einer CMS-Migration?

Die Top Drei sind: SEO Rückgang von schlechter Redirect-Map (fixierbar aber teuer in verlorenenem Traffic), Zeitplan-Blowout von unzureichender Discovery (üblicherweise, weil versteckte Komplexität mid-Build surfaces) und Editor Adoption Fehler (Ihr Team weigert sich, das neue CMS zu nutzen, weil es zu anders ist oder nicht mit ihren Workflows gebaut wurde). Alle Drei sind mit angemessener Planung vermeidbar.

Wie viel kostet es, von WordPress zu Next.js 2026 zu migrieren?

Agency Kosten rangieren von €15.000 für eine kleine Broschüren-Site bis €500.000+ für große Enterprise Migrationen mit komplexen Integrationen. Der Median für Mittelständler-Seiten ist rund €50.000–€90.000 bei einer spezialisierten Agency. Freelancer Rates sind typischerweise 40–60 % niedriger aber kommen mit höherem Risiko um Verfügbarkeit und Projektmanagement. Die Kosten sind primär driven durch die Zahl einzigartiger Templates, Komplexität von Integrationen und Volumen von Content, der manuelle Aufmerksamkeit braucht.

Muss ich alle meine Content auf einmal migrieren?

Nein, und tatsächlich eine phasierte Migration reduziert oft Risiko. Manche Teams starten indem sie ihre Marketing Pages zu Next.js bewegen, während sie den Blog auf WordPress behalten, dann migrieren den Blog in einer zweiten Phase. Sie können Reverse Proxy Rules verwenden um verschiedene Sektionen von verschiedenen Origins unter derselben Domain zu serve. Dieser Approach addiert etwas Architektur Komplexität aber lasst Sie schneller launchen und den Approach validieren bevor Sie all-in gehen.

Was ist der Unterschied zwischen einer Replatform und einer Redesign?

Eine Replatform bewegt Ihre existierende Site Design und Content auf neue Technologie (WordPress zu Next.js) mit minimalen Visual Changes. Eine Redesign ändert den Look, Feel und potenziell die Information Architecture. Beide in einem Projekt zu kombinieren ist common aber addiert 30–50 % zur Zeitplan. Falls Budget oder Zeitplan tight ist, empfehle ich zuerst Replatform, dann iterativ Redesign einmal Sie auf dem neuen Stack sind.

Kann ich Astro statt Next.js für meine Migration verwenden?

Ja, und für Content-Heavy Sites mit minimaler Interaktivität kann Astro eine exzellente Wahl sein. Astro shippt Zero JavaScript default und supports partielles Hydration ("Islands Architecture"), was bedeutet Ihre Content Pages laden unglaublich schnell. Next.js ist besser wenn Sie schwere Client-Side Interaktivität, Authentifizierung oder Real-Time Features brauchen. Wir haben Migrationen zu beiden Frameworks getan und die richtige Wahl hängt komplett ab von Ihren Site-Anforderungen.