Ihr Compliance Officer schreibt um 21:47 Uhr eine E-Mail: Seitenladezeiten erreichen 4,2 Sekunden, und das ist ein regulatorisches Risiko. Ihr CFO leitet eine Stunde später die $420K jährliche CMS-Verlängerung mit einem Wort weiter: "Warum?" Beide Anfragen zeigen auf denselben WordPress-Monolithen — eine Marketing-Website, ein Kundenportal und ein Dokumentations-Hub, zusammengehalten von 19 Premium-Plugins und einem Lizenzsystem, das teurer ist als zwei Engineers. Das Series-C-Fintech-SaaS hinter diesen E-Mails brauchte eine headless Next.js Migration, die Ausfallzeiten eliminierte, denn im Fintech-Bereich triggert jede Sekunde Offline-Zeit Überprüfungen durch Regulatoren und wütende Anrufe von Enterprise-Clients. Sie brauchten auch eine Kostenstruktur, die vor dem nächsten Board-Meeting sinnvoll war. Wir haben die Migration in 90 Tagen durchgeführt und die Infrastrukturausgaben um 73% gekürzt, während wir die Seitengeschwindigkeit verdreifacht haben — aber der schwierigste Teil war nicht der Code.

Das ist die vollständige Geschichte, wie wir es geschafft haben.

Inhaltsverzeichnis

WordPress zu Next.js Migration: Financial SaaS spart $420K ARR

Der Ausgangspunkt: Ein WordPress-Monolith unter Druck

Lassen Sie mich das Bild zeichnen. Dieses Unternehmen — wir nennen es FinEdge (NDA, Sie verstehen) — hatte ungefähr 12.000 Seiten Inhalte über drei verschiedene Web-Eigenschaften:

  1. Marketing-Website — Produktseiten, Landing Pages, Blog mit 2.400+ Posts
  2. Kundenportal — Account Dashboards, Onboarding-Flows, Dokumentenverwaltung
  3. Dokumentations-Hub — API-Dokumentation, Compliance-Guides, Integrationsleitfäden

Alle drei liefen auf einer einzelnen WordPress-Multisite-Installation gehostet auf WP Engines Enterprise-Tier. Die Plugin-Situation war... etwas. Sie führten 47 aktive Plugins aus, darunter WPGraphQL, Advanced Custom Fields Pro, Yoast SEO Premium, WP Rocket, Gravity Forms und ein Custom Plugin ihrer vorherigen Agentur, das SOC 2-Compliance-Logging für Content-Änderungen handhabte.

Die echten Pain Points:

  • Durchschnittliche Seitenladezeiten von 4,2 Sekunden auf mobil (Google CrUX-Daten)
  • Core Web Vitals scheitern auf 68% der Seiten — LCP war brutal bei 5,1s Median
  • $420K/Jahr in Lizenzen über WP Engine Enterprise-Hosting, Premium-Plugins, eine WAF, CDN und eine separate Staging-Umgebung
  • Content-Editoren warten 8-12 Sekunden auf WordPress-Admin-Reaktion während Spitzenzeiten
  • Sicherheits-Patches erforderten jede zwei Wochen dedizierte DevOps-Zeit — die Finanzdienstleistungs-Regulatoren spielen nicht
  • Keine Preview-Deployments — Content-Team musste auf Staging pushen und 4 Minuten auf Cache-Invalidierung warten

Ihr VP of Engineering sagte uns im Discovery-Call: "Wir geben mehr für unsere Website-Infrastruktur aus als für zwei Senior Engineers. Und es ist immer noch langsam."

Warum Headless Next.js die richtige Wahl war

Wir haben während der Architektur-Phase mehrere Optionen evaluiert. Hier ist, was auf dem Tisch lag:

Option Vorteile Nachteile Geschätzte jährliche Kosten
WordPress (optimiert) Vertraut dem Team, keine Migration nötig Immer noch langsam, Lizenzierungskosten unverändert $420K
Webflow Enterprise Visuelles Editing, schnelle Bereitstellung Begrenzt für Portal/App-Anforderungen, Vendor Lock-in $180K
Next.js + Sanity Blitzschnell, flexibel, Live-Preview Migrations-Aufwand, Team Ramp-Up $38K
Next.js + Contentful Starke Enterprise-Features, gutes DX Pro-Benutzer Pricing skaliert schlecht $95K
Astro + Storyblok Großartig für statische Inhalte, leicht Weniger ausgereift für dynamische Portal-Anforderungen $42K

Wir landeten bei Next.js 14 (App Router) mit Sanity als Headless CMS. Hier ist warum:

  • FinEdges Portal hatte dynamische, authentifizierte Routen, die Server-seitiges Rendering brauchten. Next.js handhabt dies nativ mit React Server Components.
  • Sanitys Echtzeit-Zusammenarbeit und GROQ-Abfragesprache gab dem Content-Team eine dramatisch bessere Erfahrung als WordPress.
  • Das Pricing-Modell (Sanitys Growth-Plan für $99/Monat + Vercel Pro) bedeutete, dass Infrastrukturkosten von $420K auf ungefähr $38K jährlich fielen.
  • Ihr Engineering-Team konnte bereits React. Das Ramp-Up zu Next.js war eine Frage von Tagen, nicht Monaten.

Wir haben ernsthaft in Erwägung gezogen, Astro für den Dokumentations-Hub zu verwenden, da es größtenteils statischer Inhalt ist, aber die betriebliche Einfachheit, alles in einem Framework zu halten, gewann. Wenn die Docs-Website ein eigenständiges Projekt gewesen wäre, wäre Astro die Wahl gewesen.

Die Migrations-Architektur

Hier ist die High-Level-Architektur, die wir gestaltet haben:

┌─────────────────┐     ┌──────────────────┐
│   Sanity CMS     │────▶│  Next.js auf      │
│   (Inhalt)       │     │  Vercel (Edge)    │
└─────────────────┘     └──────────────────┘
         │                        │
         │                        ▼
         │               ┌──────────────────┐
         │               │  Cloudflare       │
         │               │  (DNS + WAF)      │
         │               └──────────────────┘
         │                        │
         ▼                        ▼
┌─────────────────┐     ┌──────────────────┐
│  Media Pipeline  │     │  Endbenutzer      │
│  (Cloudinary)    │     └──────────────────┘
└─────────────────┘

Die Schlüsselkomponenten:

Content Layer

  • Sanity als primäres CMS für Marketing-Inhalte, Blog-Posts und Dokumentation
  • Custom Sanity Schemas, die ihren bestehenden WordPress Content-Typen entsprechen
  • Portable Text für Rich Content (Ersatz für WordPress Gutenberg Blocks)

Application Layer

  • Next.js 14 mit App Router, bereitgestellt auf Verdels Pro-Plan
  • React Server Components für Marketing-Website und Dokumentation
  • Client Components nur wo echte Interaktivität nötig war (Formulare, Dashboards, interaktive Diagramme)
  • Middleware für Authentifizierung auf Portal-Routen, integriert mit ihrem bestehenden Auth0-Setup

Infrastructure Layer

  • Vercel für Hosting und Edge Functions
  • Cloudflare für DNS-Verwaltung und zusätzliche WAF-Regeln (Finanzdienstleistungs-Compliance-Anforderung)
  • Cloudinary für Bildoptimierung und Transformation — ersetzte 3 WordPress Image-Plugins

WordPress zu Next.js Migration: Financial SaaS spart $420K ARR - Architektur

Null-Ausfallzeit-Strategie: Der Parallel-Betrieb

Das war der Teil, der mich nachts wach hielt. FinEdge konnte sich nicht einmal ein paar Minuten Ausfallzeiten leisten. Ihr Kundenportal verarbeitet Finanztransaktionen, und jede Unterbrechung triggert zwingend erforderliche Incident Reports an Regulatoren.

So haben wir es gemacht:

Phase 1: Content Sync (Wochen 1-3)

Wir haben eine Custom WordPress-to-Sanity Sync Pipeline gebaut, die während der Migrationsperiode kontinuierlich lief:

// Vereinfachte Version unserer WP-to-Sanity Sync Worker
import { createClient } from '@sanity/client'
import WPGraphQL from './wp-graphql-client'

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

async function syncPosts(since: string) {
  const posts = await WPGraphQL.getModifiedPosts(since)
  
  const transaction = sanity.transaction()
  
  for (const post of posts) {
    const sanityDoc = transformWPToSanity(post)
    transaction.createOrReplace(sanityDoc)
  }
  
  await transaction.commit()
  console.log(`Synced ${posts.length} posts`)
}

// Lief alle 5 Minuten über Cron

Das bedeutete, Content-Editoren konnten während der gesamten Migration in WordPress arbeiten. Jede Änderung wurde automatisch innerhalb von 5 Minuten zu Sanity synchronisiert.

Phase 2: Parallel Deployment (Wochen 4-8)

Wir haben die Next.js Website auf einer Subdomain bereitgestellt (next.finedge.com) und liefen beide Websites gleichzeitig. Unser QA-Prozess verglich jede einzelne Seite:

  • Visual Regression Testing mit Playwright über 200+ kritische Seiten
  • SEO-Parität Checks (Meta-Tags, strukturierte Daten, kanonische URLs, Sitemaps)
  • Performance Benchmarks auf jedem Seiten-Template
  • Accessibility Audits (WCAG 2.1 AA — erforderlich für Finanzdienstleistungen)

Phase 3: Der Cutover (Woche 9)

Der eigentliche Switch war unbedeutend — was genau das ist, was Sie wollen. Wir verwendeten Cloudflare Load Balancing, um Traffic schrittweise zu verschieben:

  • Stunde 0: 5% Traffic auf Next.js, 95% auf WordPress
  • Stunde 2: 25% / 75% (Monitoring von Fehlerquoten, Core Web Vitals)
  • Stunde 6: 50% / 50%
  • Stunde 12: 90% / 10%
  • Stunde 24: 100% Next.js, WordPress in Read-Only Modus
  • Woche 2: WordPress deaktiviert

Null Fehler. Null Ausfallzeiten. Die Monitoring Dashboards waren langweilig grün.

Performance-Ergebnisse: 3x schneller und noch mehr

Hier sind die echten Zahlen, gemessen 30 Tage nach der Migration unter Verwendung von Google CrUX-Daten und Vercel Analytics:

Metrik WordPress (Vorher) Next.js (Nachher) Verbesserung
LCP (p75) 5.1s 1.2s 4.25x schneller
FID / INP (p75) 280ms 68ms 4.1x schneller
CLS (p75) 0.18 0.02 9x besser
TTFB (p75) 1.8s 0.12s 15x schneller
Lighthouse Performance 34 96 +62 Punkte
Seiten mit bestandenen CWV 32% 98% +66%
Time to Interactive 6.8s 1.4s 4.9x schneller

Die "3x schneller" Schlagzeile verkauft es eigentlich zu kurz. Bei den meisten Metriken sahen wir 4-5x Verbesserungen. TTFB war der Star — von 1,8 Sekunden auf 120 Millisekunden dank Verdels Edge Network und ISR (Incremental Static Regeneration).

Organischer Traffic stieg in den ersten 90 Tagen nach der Migration um 31%. Ihr SEO-Team schrieb dies hauptsächlich Core Web Vitals Verbesserungen und schnelleren Crawling-Raten von Googlebot zu.

Die $420K Lizenz-Einsparungen Aufschlüsselung

Lasst uns über Geld sprechen. Hier ist genau, wo die $420K hingingen und was sie ersetzt hat:

Posten WordPress jährliche Kosten Next.js jährliche Kosten Einsparungen
WP Engine Enterprise Hosting $150,000 — $150,000
Vercel Pro (Team Plan) — $2,400 —
Premium Plugin Lizenzen (47 Plugins) $28,000 — $28,000
Sanity Growth Plan — $1,188 —
Cloudinary Pro — $2,388 —
Enterprise WAF (Sucuri) $36,000 — $36,000
Cloudflare Pro — $2,400 —
Custom WordPress Wartungsvertrag $96,000 — $96,000
CDN (separat von WP Engine) $24,000 — $24,000
Staging-Umgebung Hosting $18,000 — $18,000
WordPress-Sicherheits-Audits (vierteljährlich) $48,000 — $48,000
DevOps Team Zeit (teilweise FTE) $120,000 $30,000 $90,000
Summen $520,000 $38,376 $481,624

Die eigentlichen Einsparungen endeten bei ungefähr $482K, nicht $420K. Die ursprüngliche $420K Schätzung aus der Discovery-Phase war konservativ — wir berücksichtigten ursprünglich nicht die Reduzierung der DevOps-Zeit oder die Beseitigung von vierteljährlichen Sicherheits-Audits (Vercel und Cloudflare handhaben die meisten Dinge, die diese Audits abdeckten).

Die ROI-Mathematik ist unkompliziert. Unser Migrations-Projekt kostete FinEdge ungefähr $185K in Agentur-Gebühren über das 10-Wochen-Engagement. Diese Investition zahlte sich in unter 5 Monaten aus.

Technischer Tiefengang: Wichtige Implementierungsdetails

Umgang mit 2.400 Blog-Posts mit ISR

Wir haben nicht alle 2.400 Blog-Posts zum Build-Zeitpunkt statisch generiert. Das hätte Deployments schmerzhaft langsam gemacht. Stattdessen verwendeten wir ISR mit On-Demand-Revalidierung:

// app/blog/[slug]/page.tsx
import { sanityFetch } from '@/lib/sanity'
import { postQuery } from '@/lib/queries'

export const revalidate = 3600 // Revalidieren alle Stunden als Fallback

export async function generateStaticParams() {
  // Nur die Top 100 Posts nach Traffic pre-generieren
  const topPosts = await sanityFetch({
    query: `*[_type == "post"] | order(pageViews desc) [0...100] { "slug": slug.current }`
  })
  return topPosts.map((post) => ({ slug: post.slug }))
}

export default async function BlogPost({ params }) {
  const post = await sanityFetch({
    query: postQuery,
    params: { slug: params.slug },
    tags: [`post:${params.slug}`]
  })
  
  // ... Post rendern
}

Wenn Content-Editoren in Sanity veröffentlichen oder aktualisieren, wird ein Webhook auf unseren Revalidierungs-Endpoint geschickt:

// app/api/revalidate/route.ts
import { revalidateTag } from 'next/cache'
import { NextRequest } from 'next/server'

export async function POST(req: NextRequest) {
  const body = await req.json()
  const secret = req.headers.get('x-sanity-webhook-secret')
  
  if (secret !== process.env.SANITY_WEBHOOK_SECRET) {
    return Response.json({ error: 'Unauthorized' }, { status: 401 })
  }
  
  // Spezifische Inhalte revalidieren
  if (body._type === 'post') {
    revalidateTag(`post:${body.slug.current}`)
    revalidateTag('posts-list')
  }
  
  return Response.json({ revalidated: true })
}

Content-Updates erscheinen nun auf der Live-Website in unter 3 Sekunden. Vergleichen Sie das mit der 4-Minuten Cache-Invalidierung, die sie mit WordPress + WP Rocket hatten.

Authentifizierung für das Kundenportal

Die Portal-Routen benötigten serverseitige Authentifizierung. Wir verwendeten Next.js Middleware kombiniert mit ihrem bestehenden Auth0-Setup:

// middleware.ts
import { NextResponse } from 'next/server'
import { getSession } from '@auth0/nextjs-auth0/edge'

export async function middleware(req) {
  if (req.nextUrl.pathname.startsWith('/portal')) {
    const session = await getSession(req, NextResponse.next())
    
    if (!session?.user) {
      return NextResponse.redirect(new URL('/api/auth/login', req.url))
    }
  }
  
  return NextResponse.next()
}

export const config = {
  matcher: ['/portal/:path*']
}

Das läuft am Edge, also unauthentifizierte Anfragen werden umgeleitet, bevor sie sogar den Application Server treffen. Schnell und sicher.

301 Redirect Map

Wir hatten ungefähr 340 URLs, deren Struktur sich während der Migration änderte. Eine Finanzdienstleistungs-Website kann sich absolut keine kaputten Links leisten — jeder eingehende Link von regulatorischen Unterlagen, Partner-Websites und historischem Inhalt muss korrekt auflösen.

Wir haben eine Redirect Map in next.config.js gebaut und sie mit einem dynamischen Redirect-Lookup von Sanity für Editor-verwaltete Umleitungen ergänzt:

// next.config.js (teilweise)
module.exports = {
  async redirects() {
    return [
      // Statische Umleitungen für bekannte URL-Änderungen
      ...require('./redirects.json').map(r => ({
        source: r.from,
        destination: r.to,
        permanent: true,
      })),
    ]
  },
}

Sechs Monate nach dem Start zeigt Google Search Console null 404-Fehler aus der Migration. Jede einzelne Umleitung funktioniert.

Lektionen, die uns schwer gefallen sind

1. WordPress Gutenberg Blocks sind schmerzhaft zu konvertieren

Wir haben den Aufwand zur Konvertierung von Gutenberg Blocks zu Sanitys Portable Text unterschätzt. FinEdge hatte 23 verschiedene Block-Typen verwendet, einschließlich Custom Blocks ihrer vorherigen Agentur. Planen Sie mindestens 20% mehr Zeit ein, als Sie denken, für Content-Transformation.

2. Content-Editor Training ist nicht optional

Sanitys Studio ist intuitiv, aber es ist nicht WordPress. Wir führten drei 90-Minuten-Trainingssitzungen durch und erstellten ein Custom Sanity Studio mit geführten Workflows. Das Content-Team ging von skeptisch zu begeistert innerhalb von zwei Wochen, aber diese Trainings-Investition war kritisch.

3. Finanzdienstleistungs-Compliance addiert Komplexität

Jede Deployment brauchte einen Audit Trail. Jede Content-Änderung musste mit Zeitstempel und Benutzer-Zuschreibung geloggt werden. Wir haben ein Custom Sanity Plugin gebaut, das alle Dokument-Mutationen in eine Append-Only Audit Table in ihrer bestehenden PostgreSQL-Datenbank loggt. Das nahm eine zusätzliche Woche, die nicht im ursprünglichen Scope war.

4. Vergessen Sie nicht Formulare

Gravity Forms handhabte 14 verschiedene Form-Typen auf der WordPress Website. Wir haben sie mit React Hook Form + Zod Validation auf dem Frontend und Server Actions auf dem Backend ersetzt, mit Submissions an ihr bestehendes HubSpot CRM. Diese Migration allein dauerte eine volle Woche.

Zeitplan und Team-Struktur

Gesamt-Projektdauer: 10 Wochen

Woche Fokus Team
1 Architektur, Sanity Schema Design, Content Audit 2 Devs, 1 Architect
2-3 Content Sync Pipeline, Sanity Studio Customization 2 Devs, 1 Content Strategist
4-5 Marketing Site Build (Next.js) 3 Devs
6-7 Portal Migration, Authentifizierung, Formulare 3 Devs
8 Dokumentations-Hub, SEO Audit, Redirect Map 2 Devs, 1 SEO Specialist
9 QA, Visual Regression, Performance Testing 2 Devs, 1 QA
10 Schrittweise Traffic Cutover, Monitoring, WordPress Deaktivierung 2 Devs, 1 DevOps

Die Peak Team Größe war 4 Personen. Das meiste Projekt lief mit 2-3 Developern. Dies ist kein 15-Person, 6-Monats Engagement — es ist ein fokussiertes, erfahrenes Team, das eine gut geplante Migration ausführt.

Wenn Sie eine ähnliche Migration für Ihre Organisation in Betracht ziehen, haben wir unseren Headless-CMS-Entwicklungs-Ansatz dokumentiert und unsere Preisstruktur ist transparent. Wir sind auch gerne bereit, einen Call zu führen, um Ihre spezifische Situation zu durchleuchten — kontaktieren Sie uns hier.

FAQ

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

Für eine Website dieser Komplexität (12.000 Seiten, Kundenportal, Dokumentations-Hub) sind 10 Wochen mit einem erfahrenen Team realistisch. Einfachere Marketing-Websites mit 100-500 Seiten können in 4-6 Wochen migriert werden. Die größte Variable ist Content-Komplexität — wie viele Custom Post-Typen, Block-Typen und Plugin-abhängige Features Sie ausführen.

Können Sie WordPress zu Next.js ohne Ausfallzeiten migrieren?

Ja, aber es erfordert Planung. Der Schlüssel ist, beide Systeme parallel zu betreiben mit einer Content-Sync-Pipeline, dann DNS-Level Traffic Shifting zu verwenden, um Benutzer zur neuen Website zu verschieben. Wir haben dies erfolgreich für mehrere Clients gemacht. Die kritische Anforderung ist, dass Ihr Content während des Übergangszeitraums über beide Systeme synchron bleibt.

Wie viel kostet eine WordPress zu Headless CMS Migration?

Es hängt stark vom Scope ab. Eine unkomplizierte Marketing-Website Migration könnte $30K-$60K laufen. Eine Enterprise Migration wie FinEdges — mit Kundenportal, Compliance-Anforderungen und 12.000 Seiten — war $185K. Die ROI-Berechnung ist wichtiger als die absolute Kosten. FinEdges Investition zahlte sich in unter 5 Monaten durch Lizenz-Einsparungen allein aus.

Ist Next.js wirklich schneller als WordPress?

In praktisch jedem Fall, ja — deutlich schneller. WordPress generiert HTML bei jeder Anfrage (wenn nicht schwer gecacht), und selbst mit Caching-Plugins wie WP Rocket sind Sie durch PHPs Antwortzeit und das Gewicht des WordPress Ökosystems begrenzt. Next.js mit ISR oder statischer Generierung dient vorerstellten Seiten vom Edge. Wir sehen typischerweise 3-5x Verbesserungen in Core Web Vitals.

Welches Headless CMS sollte ich mit Next.js verwenden?

Es hängt von Ihrem Team und Anforderungen ab. Sanity brilliert bei Custom Content Modeling und Echtzeit-Zusammenarbeit. Contentful ist stark für Enterprise Teams, die einen strukturierteren, präskriptiveren Ansatz wollen, wird aber teuer pro Seat. Storyblok ist großartig, wenn visuelles Editing eine Priorität ist. Für einfachere Websites können sogar Markdown-Dateien in einem Git Repo funktionieren. Wir evaluieren dies auf Projektbasis — es gibt keine universelle Antwort.

Verlieren Sie SEO, wenn Sie von WordPress zu Next.js migrieren?

Nicht wenn Sie es richtig machen. Die drei Dinge, die wichtig sind: umfassende 301 Redirect-Mapping, so dass keine bestehenden URLs 404s zurückgeben, alle Meta-Tags und strukturierten Daten bewahren, und aktualisierte Sitemaps sofort nach Cutover an Google Search Console einreichen. FinEdge sah einen 31% Anstieg des organischen Traffics innerhalb von 90 Tagen, hauptsächlich durch Core Web Vitals Verbesserungen angetrieben.

Was passiert mit WordPress Plugins nach der Migration?

Jedes Plugin muss in seiner Funktionalität repliziert oder ersetzt werden. Einige sind unkompliziert — SEO Plugins werden durch Metadaten in Ihren Next.js Komponenten ersetzt, Caching-Plugins werden unnötig, und Form Plugins werden durch React Form Libraries ersetzt. Andere, wie Custom Compliance-Logging-Plugins, benötigen maßgeschneiderten Replacement Code. Dies ist der Grund, warum ein gründliches Plugin-Audit während der Discovery essenziell ist.

Können Content-Editoren nach dem Wechsel zu Headless einen visuellen Editor verwenden?

Ja. Sanity Studio bietet eine anpassbare Benutzeroberfläche mit Live-Preview. Es ist anders als WordPress's Block Editor, aber die meisten Content-Teams bevorzugen es nach der anfänglichen Lernkurve. Sanitys Presentation Tool bietet nun echtes visuelles Editing mit Click-to-Edit Funktionalität auf der Live-Preview. Wir haben auch Preview Deployments auf Vercel eingerichtet, so dass Editoren genau sehen können, wie ihr Inhalt aussehen wird, bevor er veröffentlicht wird.