Wie lange dauert eine Headless-WordPress-Migration im Jahr 2026?
Sechs bis sechzehn Wochen für typische Projekte. Die Form sind vier Phasen: Discovery, Scoping, Build und Cutover, Tuning. Die Variablen, die den Plan strecken oder verkürzen, sind Katalogumfang, Anzahl der Integrationen, URL-Erhalt und die Bereitschaft des Redaktionsteams, nicht die Wahl des Frameworks.
Dieser Artikel ist im Headless-WordPress-Servicepfeiler verankert und gehört zur Entscheidungsmatrix Next.js vs. Astro für die Framework-Frage und zu Cloudflare Workers und WordPress am Edge für die Runtime-Schicht.
TL;DR
- Reine Redaktionsseiten unter fünfzig Seiten: vier bis sechs Wochen.
- WooCommerce mit bis zu wenigen tausend SKUs und Standard-Integrationen: zehn bis vierzehn Wochen.
- Multi-Region oder mehrsprachig mit individuellen Integrationen: vierzehn bis sechzehn Wochen, gelegentlich länger.
- Die teuren Wochen sind das Scoping (Woche eins bis zwei) und der Cutover (das letzte Wochenende), nicht der Build selbst.
- Die Preisgestaltung ist projektindividuell; wir veröffentlichen den Zeitplan, nicht den Preis.
Die vier Phasen in echter Zeit
Die Phasen sind keine Etiketten in einem Gantt-Diagramm; sie bilden unterschiedliche Arbeitsmodi ab, für die unterschiedliche Personen im Raum gebraucht werden.
Phase 1, Discovery (Woche null bis zwei)
Stakeholder, das Redaktionsteam, der Analytics-Verantwortliche und der technische Ansprechpartner durchlaufen drei bis fünf Sitzungen über ein bis zwei Wochen. Die Lieferobjekte sind ein Audit des Content-Modells, eine Performance-Baseline aus dem Live-System (TTFB, TTI, LCP pro Template), ein Inventar von Plugins und Integrationen sowie ein Entwurf der SEO-Migrationskarte.
Das Ergebnis der Discovery ist Entscheidungsinput, keine Architektur. Ein Team, das die Discovery überspringt, um “Zeit zu sparen”, zahlt die Kosten in Woche acht zurück, wenn eine nicht deklarierte Integration auftaucht und der Datenlayer neu entworfen werden muss.
Phase 2, Scoping (Woche zwei bis drei)
Architekturentscheidung: Astro 5+ oder Next.js 15, Wahl des Renderings pro Route, Data-Fetching-Muster (REST oder GraphQL), Strategie zur Cache-Invalidierung. Die Redirect-Map wird hier abgenommen, nicht später. Der redaktionelle Workflow wird finalisiert: Vorschauen, Entwürfe, geplante Veröffentlichungen, Mehr-Autoren-Flows.
Das Scoping endet mit einem schriftlichen Engagement-Letter und einer fixen Liste der Lieferobjekte. Was hier fehlt, wird in Woche zehn zur Change-Order, also zum teuersten Zeitpunkt für eine Scope-Verhandlung.
Phase 3, Build und Cutover (Woche drei bis zwölf)
Der Build läuft in Zwei-Wochen-Sprints mit einer wöchentlichen Demo. Jede Demo läuft auf Staging, nicht auf Localhost, damit das Team sieht, wie sich die redaktionelle Seite im neuen Stack tatsächlich verhält. Der erste Sprint umfasst das Designsystem und ein einzelnes Template Ende-zu-Ende; die folgenden Sprints fächern sich nach Template-Typ auf.
Der Cutover selbst ist ein Fenster von achtundvierzig bis zweiundsiebzig Stunden, bewusst geplant. Zwei Muster funktionieren: DNS-Switch (sauberer, langsamerer Rollback) und Reverse-Proxy-Cutover (schnellerer Rollback, mehr bewegliche Teile). Die Redirect-Map wird am Edge angewendet, nicht in PHP.
Das parallele Messfenster läuft ein bis zwei Wochen vor dem Cutover. Es fängt Regressionen bei Tracking-Tags, Schema-Validierung und Core Web Vitals ab, bevor sie produktiv gehen.
Phase 4, Tuning und Wartung (Woche zwölf bis sechzehn)
Die Edge-Cache-TTLs werden pro Route justiert. Observability (Cloudflare Logpush, synthetische Tests, Alerting auf TTFB und 5xx-Raten) wird eingebaut. Die Übergabe in die Wartung deckt neue Feature-Arbeit, vierteljährliche Tech-Radar-Reviews und eine Roadmap für die sich wandelnden Anforderungen des Redaktionsteams ab.
Diese Phase wird am häufigsten ausgelassen. Das Auslassen kostet sechs Monate kleiner Vorfälle, die das Team nicht diagnostizieren kann, weil nichts instrumentiert ist.
Was den Zeitplan streckt
Drei Muster verschieben ein Sechs-Wochen-Projekt auf zwölf und ein Zwölf-Wochen-Projekt auf zwanzig.
Spät entdeckte Integrationen. Ein individuelles Payment-Gateway, eine Legacy-ERP-Integration über SOAP, ein Nischen-Plugin ohne REST-Schnittstelle. Jede einzelne braucht einen maßgeschneiderten Adapter. Jeder Adapter bedeutet zwei bis vier zusätzliche Wochen Build, plus Vertragsverhandlungen, falls eine dritte Partei das Upstream-System besitzt.
URL-Erhalt. Eine Site mit dreißig eindeutigen URL-Mustern ist mechanisch. Eine Site mit dreihundert Mustern und einer Permalink-Umstrukturierung ist ein eigenes Projekt. Die 301-Map wird im Scoping abgenommen, nicht in Woche zehn improvisiert.
Umbau des Content-Modells. Wenn die existierenden WordPress-Inhalte um Theme-Templates herum strukturiert sind statt um strukturierte Felder, kann das Frontend sie nicht deterministisch verarbeiten. Der Umbau des Content-Modells fügt zwei bis sechs Wochen hinzu und erfordert eine Verfügbarkeit des Redaktionsteams, die die meisten Teams unterschätzen.
Was den Zeitplan verkürzt
Vier Bedingungen verkürzen den Plan zuverlässig.
Sauberes Content-Modell. Custom Post Types, ACF- oder Meta-Box-Feldgruppen oder ein kürzlich erfolgter Umzug auf den Block Editor mit strukturierten Patterns. Das Frontend liest strukturierte Daten und rendert deterministisch. Spart zwei bis vier Wochen.
Vorhandenes Designsystem. Eine Figma-Bibliothek, ein Token-Set oder eine Komponentenbibliothek, die das Team bereits verwendet hat. Spart eine bis zwei Wochen Grundlagenarbeit im ersten Sprint.
Verfügbarkeit des Redaktionsteams. Wenn das Redaktionsteam wöchentlich an Vorschauen teilnehmen und Flows abnehmen kann, stockt der Build nicht beim Warten auf Klärung. Spart eine bis zwei Wochen über das gesamte Projekt.
Senior-Team auf beiden Seiten. Ein Senior-Product-Owner auf Kundenseite halbiert den Frage-Antwort-Zyklus. Die Agentur kann das nicht herstellen; es muss vom Auftraggeber kommen.
Wann die Sechs-Wochen-Antwort falsch ist
Ein WooCommerce-Shop mit dreitausend SKUs und einem individuellen Checkout migriert nicht in sechs Wochen. Wer diesen Zeitplan anbietet, verkauft einen anderen Scope und verhandelt später nach. Die ehrliche Antwort für dieses Profil sind zwölf bis vierzehn Wochen.
Eine Multi-Region-Site mit fünf Locales und locale-spezifischen Commerce-Flows ist ebenfalls kein Sechs-Wochen-Projekt. Übersetzungs-Workflows, Hreflang-Validierung, locale-spezifische Cache-Strategien und regionsbezogene Payment-Integrationen fügen vier bis sechs Wochen selbst zu einer gesunden Baseline hinzu.
Wann die Sechzehn-Wochen-Antwort falsch ist
Eine kleine Redaktionsseite, eine frische WordPress-Installation, ein sauberes Content-Modell und ein Senior-Team können in fünf Wochen ausliefern. Sechzehn Wochen für dieses Profil sind aufgepolsterter Scope.
Eine Greenfield-Headless-Site (keine Migration, nur ein neues Frontend auf einem neuen WordPress) überspringt den Großteil von Phase eins und kürzt Phase drei. Sechs bis acht Wochen insgesamt.
Wie die Preisgestaltung aussieht
Die Preisgestaltung ist projektindividuell. Wir veröffentlichen keine Servicepreise auf der öffentlichen Site. Der Engagement-Letter bindet Stunden an die vier obigen Phasen, mit einer festen Obergrenze auf Phase eins (sie ist durch die Anzahl der Interviews begrenzt, nicht durch etwas, das skaliert) und Time-and-Materials oder Fixed-Scope auf Phase drei (je nachdem, wie stabil der Scope nach dem Scoping ist).
Wir rechnen in EUR oder USD ab, EU-Rechtsraum, B2B-Vertrag. Siehe den Headless-WordPress-Servicepfeiler für das Zusammenarbeitsmodell und die Über-uns-Seite WPPoland für das Team und den EU-Standardrechtsraum.
Cluster reading
Die unterstützenden Artikel im Cluster, nach Thema.
- Cloudflare Workers und WordPress am Edge zur Runtime-Schicht des neuen Stacks.
