Migration von WordPress/PHP zu Django/Python: Wann es sich lohnt und was es kostet
WordPress auf PHP deckt die meisten Content-Sites ab, doch mit dem Wachstum des Unternehmens werden Plugins, Custom Code und CMS-Grenzen zum Engpass. Django/Python ist der Weg zu eigener Business-Logik, APIs, Rollen und einem skalierbaren Backend ohne „Plugin-Zoo“. Unten: Anzeichen für eine Migration, typische Szenarien, Budget, Zeitplan und wie Sie 2026 erkennen, ob sich der Umzug lohnt.
- Typische Auslöser - komplexe Business-Logik, Integrationen, Sicherheit, Performance, PHP-Tech-Schulden
- Migrationsbudget - $3.000 - $80.000+ je nach Datenvolumen, Funktionen und SEO-Anforderungen
- Zeitrahmen - 3-12 Wochen für typische Sites, 3-9 Monate für E-Commerce und SaaS
- Amortisation - 12-36 Monate bei höherer Conversion, geringeren Support-Kosten und neuen Integrationen
- Hauptrisiko - nicht Django, sondern schlechte Legacy-Analyse und SEO-Verlust beim URL-Umzug
Wenn WordPress nicht mehr reicht
WordPress passt, solange die Site Content + Formulare + einfacher Katalog ist. Probleme beginnen, wenn die Business-Logik das Plugin-Ökosystem sprengt:
- 10+ Plugins mit überlappender Funktion, Update-Konflikten und Sicherheitslücken;
- Custom PHP in
functions.php, mu-plugins und Plugin-Forks - ohne Tests, Doku und Code Review; - Langsame Seiten bei 50K+ Einträgen, komplexen Filtern oder schweren WooCommerce-Queries;
- Integrationen über Workarounds - Zapier-Webhooks, CSV-Exporte, manuelle CRM-/ERP-Sync;
- Kein sauberes API für Mobile App, Partner-Portal oder Headless-Frontend;
- Rollen und Rechte jenseits von „Admin / Redakteur / Abonnent“ - Abteilungen, Approval-Flows, Audit Log.
Django ist nicht „in allem besser als WordPress“ - es ist besser dort, wo das CMS zur ERP auf Plugins wird.
Anzeichen, dass Migration nötig ist
| Symptom | Was passiert | Folge |
|---|---|---|
| WP-Update bricht Site | Plugin-Konflikte, deprecated Hooks | Ausfall, verlorene Leads |
| „Plugin-Entwicklung“ dauert Wochen | Kein Zugriff auf Kernlogik | Teure Anpassungen |
| Sicherheit dauernd im Krisenmodus | Plugin-Schwachstellen, nulled Themes | Hacks, SEO-Strafen |
| Daten-Duplikate | Bestellungen in WP, Kunden im CRM, Lager in Excel | Fehler, Handarbeit |
| Last steigt, Cache reicht nicht | Architektur: Monolith auf Plugins | Conversion sinkt |
Treffen 2-3 Punkte zu, ist Migration kein „Trend-Stack“, sondern Risikoreduktion.
Was Migration umfasst
Ein typisches „WordPress → Django“-Projekt ist mehr als HTML-Umzug:
- Legacy-Audit - Plugins, Custom Code, DB, Cron, Integrationen, „versteckte“ Logik.
- Neue Architektur - Datenmodelle, API, Rollen, Hintergrundjobs (Celery).
- Content-Migration - Posts, Seiten, Medien, Meta, Kategorien, Tags, Custom Fields (ACF).
- User-Migration - Passwort-Hashes (oft Re-Hash beim ersten Login), Rollen, Profile.
- E-Commerce / Bestellungen - bei WooCommerce: Produkte, Varianten, Orders, Gutscheine, Steuern.
- SEO-Schicht - 301-Redirects, Sitemap, Canonical, Schema.org, Slugs wo möglich beibehalten.
- Integrationen - CRM, Zahlungen, E-Mail, Analytics - in Python, ohne Mittelsmänner.
- Parallellauf - Staging, UAT, Cutover-Plan, Rollback.
- Redakteur-Schulung - Wagtail / Django Admin / Headless CMS.
Django muss das WordPress-Admin nicht 1:1 nachbauen. Eine vereinfachte CMS passend zum Team-Workflow gewinnt oft.
Migrationsstrategien
Big Bang (Einmal-Umstellung)
Alte Site aus, neue Site in Wartungsfenster (Nacht / Wochenende).
- Vorteile - ein Cutover, keine Doppelpflege.
- Nachteile - hohes Risiko, Rollback nötig, Stress für SEO und Team.
- Wann passend - kleine Site, wenige Integrationen, wenig Off-Peak-Traffic.
Phasenweise (Strangler Fig)
Zuerst ein Modul - Blog, Kundenbereich, API - und Teil-Traffic auf Django.
- Vorteile - geringeres Risiko, KPIs in Teilen messbar.
- Nachteile - vorübergehend zwei Systeme, komplexere Infra (Reverse Proxy, Shared Auth).
- Wann passend - E-Commerce, SaaS, hoher Traffic, Zero-Downtime.
Headless WordPress → Django Backend
Zuerst bleibt WordPress CMS für Redakteure; Django übernimmt Katalog, Bestellungen, API. Später Content nach Wagtail.
- Vorteile - Redakteure arbeiten weiter; Business-Logik verlässt PHP schneller.
- Nachteile - zwei CMS in der Übergangsphase.
Für die meisten B2B- und E-Commerce-Projekte lohnt sich phasenweise Migration durch ruhigeres Team und weniger Ausfallzeit.
Kosten der Migration
Der Preis hängt von Datenvolumen, WooCommerce-/Membership-Tiefe, Integrationszahl und SEO ab - nicht vom „Umzug zu Python“ an sich.
Typische Spannen (USD, Outsourcing Osteuropa / GUS)
| Szenario | Was wandert | Budget | Dauer |
|---|---|---|---|
| Unternehmens-Site | 20-100 Seiten, Blog, Formulare, SEO | $3.000 - $12.000 | 3-6 Wochen |
| Content + Kundenbereich | User, Rollen, Dokumente, API | $8.000 - $25.000 | 6-10 Wochen |
| WooCommerce MVP | bis 2.000 SKUs, Orders, Zahlung, Admin | $15.000 - $45.000 | 2-4 Monate |
| Marketplace / SaaS | Multi-Vendor, Abos, Billing, RBAC | $40.000 - $80.000+ | 4-9 Monate |
Für US-/Westeuropa-Teams x2-x3 ansetzen. Migration kostet meist +15-35% gegenüber vergleichbarem Greenfield-Django wegen Legacy-Parsing, Redirects und Parallelbetrieb.
Budget-Aufteilung
| Posten | Anteil | Kommentar |
|---|---|---|
| Audit und Spec | 10-15% | Ohne das wird um 40-60% unterschätzt |
| Design / Frontend | 15-30% | Redesign oder Anpassung bestehendes Markup |
| Django Backend | 30-45% | Modelle, API, Logik, Admin |
| Datenmigration | 10-20% | Skripte, Validierung, Dry-Run |
| SEO und Redirects | 5-10% | URL-Karte, 301, Search Console |
| Test, UAT | 10-15% | Regression, Last, Cutover-Probe |
| DevOps | 5-10% | CI/CD, Staging, Monitoring |
Beim Legacy-Audit und SEO sparen ist riskant - dort explodieren Budget und organischer Traffic geht verloren.
Zeitplan und kritischer Pfad
| Phase | Corporate | WooCommerce | SaaS / Marketplace |
|---|---|---|---|
| WP-Audit, Datenkarte | 3-7 Tage | 1-2 Wochen | 2-3 Wochen |
| Architektur, Spec | 3-5 Tage | 1-2 Wochen | 2-4 Wochen |
| Django-Entwicklung | 2-4 Wochen | 6-12 Wochen | 12-24 Wochen |
| Migrationsskripte + Dry-Run | 3-5 Tage | 1-2 Wochen | 2-3 Wochen |
| SEO, Redirects, UAT | 3-5 Tage | 1-2 Wochen | 2-3 Wochen |
| Cutover | 1 Tag | 1-2 Tage | 2-5 Tage |
| Gesamt | 3-6 Wochen | 2-4 Monate | 4-9 Monate |
Verzögerungen durch schmutzige WP-Daten (ACF mit Dutzenden Feldern, doppelte Slugs), instabile Partner-APIs und späte Freigabe der Redirects mit SEO.
Wann sich Migration amortisiert
Amortisation misst man in Geld und Risiko, nicht in „Stack-Schönheit“:
Direkte Einsparungen
- Plugin-Support und Notfall-Fixes - $200-800/Mo auf WP vs $150-500/Mo Django-Retainer ohne Plugin-Zoo;
- Hosting - schweres WooCommerce auf managed WP $100-400/Mo vs optimiertes Django auf VPS $40-150/Mo bei vergleichbarer Last;
- Integrationen - Wegfall von Zapier/Make und CSV spart $50-300/Mo und Handarbeit.
Umsatzwachstum
- Site-Geschwindigkeit - +0,1s LCP oft +1-3% E-Commerce-Conversion;
- Neue Features ohne Plugin-Decke - Abos, B2B-Portal, Partner-API;
- Weniger Ausfall - ein WP-Hack oder Update-Konflikt kann mehr kosten als ein Quartal Support.
Einfache ROI-Formel
ROI (Monate) = (Migrationskosten) / (monatliche Einsparung + Marge aus Conversion-Anstieg)
Beispiel: WooCommerce-Migration für $25.000. Einsparung Support, Hosting, Integrationen - $600/Mo. Umsatzplus durch Speed und B2B-Bereich - $800/Mo. Summe $1.400/Mo → Amortisation ~18 Monate.
Migration lohnt sich nicht, wenn die Site eine 10-Seiten-Broschüre ohne Integrationen und Wachstumspläne ist. Dann ist WP aufräumen und besseres Hosting günstiger.
Risiken und Gegenmaßnahmen
SEO-Verlust. 301-Karte vor Cutover, 404-Monitoring 4-8 Wochen, URL-Struktur wo möglich beibehalten.
Datenverlust. Mindestens zwei Dry-Runs, Checksummen, Stichproben bei Orders und Usern.
Cutover-Ausfall. Staging-Probelauf, Rollback-Plan, Low-Traffic-Fenster, Feature Flags.
Widerstand der Redakteure. Früher Zugang zum neuen Admin, kurze Schulung, 1-2 Wochen Parallelbetrieb.
Scope Creep. Feature-Freeze für Migration; Neues in „Phase 2“ nach Stabilisierung.
WordPress vs Django nach der Migration
| Kriterium | WordPress | Django |
|---|---|---|
| Content, Blog | Exzellent | Wagtail / Headless CMS |
| Eigene Business-Logik | Schwach (Workarounds) | Stärke |
| API, Mobile | Über Plugins | DRF eingebaut |
| Enterprise E-Commerce | WooCommerce + Schmerz | Oscar / Custom |
| Sicherheit | Abhängig von Plugins | Kleinere Angriffsfläche |
| MVP-Geschwindigkeit | Schneller | Langsamer am Start |
| TCO beim Wachstum | Nichtlinear steigend | Planbarer |
Fazit
Migration von WordPress/PHP zu Django/Python lohnt sich, wenn das CMS Tech-Schulden wurde: Plugin-Konflikte, Custom-Logik, Integrationen, Sicherheit, Skalierung. Budget - ab $3.000 für Content-Site bis $80.000+ für Marketplace; Dauer - 3 Wochen bis 9 Monate. Amortisation - 12-36 Monate bei messbarer Support-Einsparung und Conversion-Wachstum.
Starten Sie mit 3-5 Tagen Legacy-Audit - er zeigt echten Umfang und filtert „Migration um der Migration willen“. Wenn Django nicht nötig ist, spart das Audit mehr als es kostet.
Häufig gestellte Fragen
Kann ich zu Django migrieren ohne SEO zu verlieren?
Ja, mit sauberer URL-Karte. 301-Redirects für jede geänderte Adresse, Slugs wo möglich, aktuelle Sitemap, Search Console und 404 nach Cutover. Content und Meta per Skript mit Stichproben auf Top-Traffic-Seiten. Risiko sind fehlende Redirects - 5-10% Budget für SEO einplanen.
Bleiben Passwörter nach WordPress-Migration erhalten?
Abhängig vom Hash-Algorithmus. WordPress nutzt phpass - Django akzeptiert das nicht direkt. Typisch: Hashes migrieren und beim ersten Login re-hashen (Custom Auth Backend) oder Einmal-Link für neues Passwort. Bei großer B2C-Basis - früh kommunizieren; bei B2B - manuelles Onboarding wichtiger Accounts.
Was kostet reine Content-Migration ohne E-Commerce?
Corporate Site (bis 100 Seiten, Blog, Medien, Formulare) - $3.000 - $8.000, 3-5 Wochen. Komplexität steigt mit ACF/Custom Fields, Mehrsprachigkeit (WPML/Polylang) und exotischen Post Types. Neues Design in Wagtail - +15-25% Frontend.
Was ist günstiger: WordPress erweitern oder zu Django migrieren?
WP-Erweiterung kurzfristig günstiger (Tage-Wochen) für eine kleine Funktion ohne Tech-Schulden. Django langfristig (1-3 Jahre) günstiger, wenn Plugins, Integrationen und Sicherheitsvorfälle sich häufen. Regel: wenn die letzten 2-3 Änderungen länger dauerten als geplant - Migrations-TCO rechnen.
Kann WordPress für den Blog bleiben und Django die Business-Logik übernehmen?
Ja, ein üblicher Zwischenschritt. Django für Katalog, Orders, API, Kundenbereich; WordPress nur Redaktion. Reverse Proxy (Nginx) leitet /blog/ zu WP, Rest zu Django. Nachteil - zwei Systeme für Updates und Sicherheit. Vorteil - schnellerer Time-to-Value und weniger Risiko für Redakteure. Langfristig wandert Content meist nach Wagtail, wenn Business-Module stabil sind.