Wie man eine Drupal-Website zu WordPress migriert: Ein vollständiger technischer Leitfaden

Die Migration von Drupal zu WordPress bedeutet, Ihre Datenbankinhalte, Mediendateien, URL-Struktur und Benutzerkonten von Drupals entitätsbasierter CMS-Architektur auf das Post-Type-Modell von WordPress zu übertragen — ohne SEO-Wert zu verlieren, interne Links zu unterbrechen oder Ausfallzeiten zu verursachen. Der Prozess umfasst einen datenbankbasierten Inhaltsimport über das FG Drupal to WordPress-Plugin, gefolgt von Permalink-Mapping, 301-Redirect-Konfiguration und Theme-Rekonstruktion.

Dieser Leitfaden behandelt jede Phase dieser Migration in präzisen technischen Details: Pre-Migration-Backup-Strategie, Umgebungseinrichtung, Extraktion von Datenbank-Zugangsdaten, Plugin-gesteuerter Import, URL-Struktur-Abgleich und Validierung nach dem Launch. Unabhängig davon, ob Sie Drupal 7, 9 oder 10 betreiben, gilt der folgende Workflow.

Warum von Drupal zu WordPress migrieren

Drupal ist ein leistungsstarkes Framework, aber seine Komplexität hat reale Betriebskosten. Modul-Updates führen häufig zu Breaking Changes, das Theming erfordert Twig-Template-Kenntnisse, und routinemäßige Inhaltsbearbeitungen erfordern die Einbeziehung von Entwicklern. WordPress hingegen bietet eine flachere Lernkurve, ein deutlich größeres Plugin-Ökosystem und niedrigere Gesamtbetriebskosten für inhaltsreiche Websites, die keine granulare Zugriffskontrolle oder komplexe Inhaltsmodellierung von Drupal benötigen.

Das Performance-Argument ist ebenfalls relevant. Eine WordPress-Installation auf einer ordnungsgemäß konfigurierten VPS Hosting-Umgebung mit LiteSpeed, Object-Caching und NVMe-Speicher wird einen aufgeblähten Drupal-Stack auf gemeinsam genutzter Infrastruktur konsistent übertreffen.

Wichtigste Migrationsgründe nach Anwendungsfall:

• Redaktionsteams, die von Drupals Admin-UX und langsamen Publishing-Workflows frustriert sind
• Agenturen, die Client-Websites auf einem einzigen verwaltbaren CMS konsolidieren
• Entwickler, die den Wartungsaufwand durch Drupals Modul-Abhängigkeitsketten reduzieren
• SEO-Teams, die eine engere Integration mit WordPress-nativen Tools wie Yoast oder Rank Math anstreben

Drupal vs. WordPress: Architekturvergleich

Das Verständnis der strukturellen Unterschiede zwischen den beiden Plattformen ist unerlässlich, bevor Sie beginnen. Fehlannahmen darüber, wie Inhalte gespeichert werden, sind die Hauptursache für fehlgeschlagene oder unvollständige Migrationen.

Die kritischste architektonische Lücke ist das Content-Entity-Modell. Drupal speichert Paragraphen, benutzerdefinierte Felder und Taxonomie-Referenzen über mehrere verknüpfte Tabellen. Das FG Drupal to WordPress-Plugin ordnet diese WordPress-Post-Meta und Taxonomie-Termen zu, aber komplexe paragraphenbasierte Layouts erfordern eine manuelle Rekonstruktion.

Pre-Migration-Checkliste

Bevor Sie eine der beiden Umgebungen anfassen, vervollständigen Sie jeden Punkt auf dieser Liste. Das Überspringen von Schritten ist die häufigste Ursache für Datenverlust und verlängerte Ausfallzeiten.

• Prüfen Sie Ihr Drupal-Inhaltsverzeichnis: Node-Typen, Taxonomie-Vokabulare, Benutzeranzahl, Dateianzahl und Gesamtdatenbankgröße
• Identifizieren Sie Drupal-Module ohne WordPress-Äquivalent (z. B. Rules, Webform-Komplexlogik, Commerce)
• Bestätigen Sie, dass Ihr WordPress-Server die Mindestanforderungen erfüllt: PHP 8.1+, MySQL 8.0+ oder MariaDB 10.6+, 256 MB PHP-Speicherlimit
• Entscheiden Sie sich für ein Migrationsfenster — idealerweise eine Zeit mit geringem Traffic
• Aktivieren Sie den Wartungsmodus in Drupal während des abschließenden Importdurchlaufs, um Content-Drift zu verhindern
• Stellen Sie sicher, dass der WordPress-Server den Drupal-Datenbankhost erreichen kann (gleicher Server, Remote-Host oder SSH-Tunnel)

Schritt 1: Sichern Sie Ihre Drupal-Website

Ein vollständiges, verifiziertes Backup ist nicht verhandelbar. Sie benötigen sowohl den Datenbank-Dump als auch das Dateiverzeichnis.

Datenbank-Backup via Drush

Wenn Sie Drush installiert haben (Standard für Drupal 9/10), ist dies die schnellste Methode:

drush sql-dump --result-file=/var/backups/drupal_backup_$(date +%Y%m%d).sql --gzip

Datenbank-Backup via mysqldump

mysqldump -u drupal_user -p drupal_database_name | gzip > /var/backups/drupal_backup_$(date +%Y%m%d).sql.gz

Backup des Dateiverzeichnisses

tar -czf /var/backups/drupal_files_$(date +%Y%m%d).tar.gz /var/www/html/drupal/sites/default/files/

phpMyAdmin-Backup (GUI-Methode)

1. Melden Sie sich über Ihr Hosting-Control-Panel bei phpMyAdmin an
2. Wählen Sie die Drupal-Datenbank aus der linken Seitenleiste
3. Klicken Sie auf Exportieren, wählen Sie die Schnell-Exportmethode, Format SQL
4. Klicken Sie auf OK, um die .sql-Datei herunterzuladen

Speichern Sie alle Backup-Archive außerhalb des Servers — laden Sie sie in einen Remote-Speicher hoch oder laden Sie sie lokal via SFTP herunter. Ein Backup, das nur auf demselben Server wie die zu migrierende Website liegt, ist kein echtes Backup.

Schritt 2: WordPress auf Ihrem Zielserver einrichten

Installieren Sie eine saubere WordPress-Instanz in Ihrer Zielumgebung. Importieren Sie keine Drupal-Inhalte in eine bestehende WordPress-Website, es sei denn, Sie haben explizit für das Zusammenführen von Inhalten geplant — der Importer wird keine Duplikate entfernen.

Serveranforderungen

Für große Drupal-Websites (10.000+ Nodes, mehrere GB Medienbibliotheken) bietet ein VPS mit cPanel direkten Zugriff auf PHP-Konfiguration, MySQL-Tuning-Parameter und Cron-Job-Verwaltung — alles, was Sie während einer umfangreichen Migration benötigen.

WordPress-Installation via WP-CLI

cd /var/www/html/wordpress
wp core download
wp config create --dbname=wp_database --dbuser=wp_user --dbpass=secure_password --dbhost=localhost
wp core install --url="https://yourdomain.com" --title="Site Title" --admin_user=admin --admin_password=strongpassword --admin_email=admin@yourdomain.com

One-Click-Installation via cPanel

Wenn Ihr Host cPanel bereitstellt, navigieren Sie zu Softaculous Apps Installer, wählen Sie WordPress, geben Sie die Datenbank- und Admin-Zugangsdaten ein und klicken Sie auf Installieren. Der Vorgang dauert weniger als zwei Minuten.

Konfigurieren Sie nach der Installation sofort diese PHP-Einstellungen in php.ini oder via .htaccess:

php_value max_execution_time 300
php_value memory_limit 256M
php_value post_max_size 128M
php_value upload_max_filesize 128M

Schritt 3: Das FG Drupal to WordPress-Plugin installieren und konfigurieren

Das FG Drupal to WordPress-Plugin (kostenlose Version verfügbar; Premium für große Websites empfohlen) übernimmt die datenbankbasierte Migration von Nodes, Taxonomie-Termen, Benutzern und Mediendateien.

Installation

1. Gehen Sie in Ihrem WordPress-Admin zu Plugins > Neu hinzufügen
2. Suchen Sie nach FG Drupal to WordPress
3. Klicken Sie auf Jetzt installieren und dann auf Aktivieren

Alternativ können Sie es via WP-CLI installieren:

wp plugin install fg-drupal-to-wp --activate

Vergleich der kostenlosen und Premium-Funktionen

Für jede Produktionswebsite mit Drupal 8 oder höher ist die Premium-Version ihren Preis wert. Der Versuch, paragraphenbasierte Inhalte manuell zu rekonstruieren, ist in Entwicklerzeit weitaus teurer.

Schritt 4: Drupal-Datenbank-Zugangsdaten sammeln

Das FG Drupal to WordPress-Plugin verbindet sich direkt mit Ihrer Drupal-Datenbank. Sie benötigen vier Werte: Datenbankname, Benutzername, Passwort und Host.

Zugangsdaten in Drupals settings.php finden

grep -A 20 "'database'" /var/www/html/drupal/sites/default/settings.php

Die Ausgabe enthält einen Block wie diesen:

$databases['default']['default'] = [
  'database' => 'drupal_db_name',
  'username' => 'drupal_db_user',
  'password' => 'drupal_db_password',
  'host' => 'localhost',
  'port' => '3306',
  'driver' => 'mysql',
];

Überlegungen zum Remote-Datenbankzugriff

Wenn WordPress und Drupal auf verschiedenen Servern laufen, muss die Drupal-Datenbank Remote-Verbindungen akzeptieren. Auf dem Drupal-Datenbankserver:

GRANT SELECT ON drupal_database.* TO 'drupal_user'@'wordpress_server_ip' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

Stellen Sie außerdem sicher, dass Port 3306 in der Firewall nur für die IP des WordPress-Servers geöffnet ist — setzen Sie MySQL niemals 0.0.0.0 aus.

Wenn Sie keinen direkten MySQL-Port öffnen können, verwenden Sie einen SSH-Tunnel:

ssh -L 3307:localhost:3306 user@drupal_server_ip -N -f

Setzen Sie dann den Datenbank-Host des Plugins auf 127.0.0.1 und den Port auf 3307.

Schritt 5: Den Inhaltsimport ausführen

Navigieren Sie in Ihrem WordPress-Dashboard zu Werkzeuge > Importieren, scrollen Sie zum Drupal-Abschnitt und klicken Sie auf Importer ausführen.

Konfiguration der Importer-Einstellungen

Registerkarte Datenbankverbindung:

• Datenbank-Host: localhost (oder Remote-IP / SSH-Tunnel-Adresse)
• Port: 3306 (oder Ihr benutzerdefinierter Port)
• Datenbankname: Wert aus settings.php
• Benutzername / Passwort: Werte aus settings.php
• Drupal-Dateien-URL: die öffentliche URL Ihres Drupal-sites/default/files/-Verzeichnisses — erforderlich für den Medien-Download

Klicken Sie auf Verbindung testen, bevor Sie fortfahren. Eine fehlgeschlagene Verbindung in dieser Phase wird fast immer durch eines von drei Problemen verursacht: falsche Zugangsdaten, eine Firewall, die den MySQL-Port blockiert, oder der Drupal-Datenbankbenutzer verfügt nicht über SELECT-Berechtigungen für die Zieldatenbank.

Registerkarte Verhalten — empfohlene Einstellungen für die meisten Migrationen:

• Posts importieren: Ja
• Seiten importieren: Ja
• Kategorien und Tags importieren: Ja
• Bilder und Anhänge herunterladen: Ja (erforderlich, um Medien in das Upload-Verzeichnis von WordPress zu kopieren)
• WordPress-Daten vor dem Import entfernen: Ja (nur bei einer Neuinstallation — dies leert wp_posts und verwandte Tabellen)

Den Import starten

Klicken Sie auf Importer starten / fortsetzen. Das Plugin verarbeitet Inhalte in Batches. Bei großen Websites kann der Import eine Zeitüberschreitung haben und mehrere Fortsetzungszyklen erfordern — dies ist ein erwartetes Verhalten, kein Fehler. Klicken Sie einfach jedes Mal auf Fortsetzen.

Überwachen Sie das auf dem Bildschirm angezeigte Import-Protokoll. Achten Sie auf:

Error downloading file — zeigt an, dass die Drupal-Dateien-URL falsch ist oder das Dateiverzeichnis nicht öffentlich zugänglich ist
Duplicate entry-Fehler — in der Regel harmlos, zeigt an, dass das Plugin bereits importierte Datensätze bei einer Fortsetzung überspringt
MySQL server has gone away — zeigt an, dass wait_timeout auf dem MySQL-Server zu niedrig ist; erhöhen Sie es auf mindestens 600 Sekunden

SET GLOBAL wait_timeout = 600;
SET GLOBAL interactive_timeout = 600;
Schritt 6: URL-Struktur abgleichen und Redirects konfigurieren
Dies ist der Schritt, den die meisten Anleitungen unterschätzen. URL-Struktur-Diskrepanzen zwischen Drupal und WordPress sind die Hauptursache für SEO-Ranking-Einbrüche nach der Migration.
Drupal-URL-Muster (häufig)




Drupal-URL-Muster
Beschreibung




/node/123
Standard-Node-Pfad (kein Alias)


/about-us
Pfad-Alias (am häufigsten)


/taxonomy/term/5
Taxonomie-Term-Seite


/user/1
Benutzerprofil


/content/article-title
Inhaltstyp-präfixierter Alias




WordPress-Permalink-Konfiguration
Gehen Sie zu Einstellungen > Permalinks und wählen Sie eine Struktur, die Ihren Drupal-Pfad-Aliasen so genau wie möglich entspricht. Für die meisten Drupal-Websites mit sauberen Aliasen ist /%postname%/ die richtige Wahl.
/%postname%/
Wenn Ihre Drupal-Website kategoriepräfixierte URLs wie /blog/article-title verwendet hat, nutzen Sie:
/%category%/%postname%/
301-Redirects implementieren
Installieren Sie das Redirection-Plugin (von John Godley) zur Verwaltung von Redirect-Regeln. Für Massen-Redirects exportieren Sie Ihre Drupal-Pfad-Aliase aus der Datenbank:
SELECT source, alias FROM path_alias WHERE langcode = 'en';
Importieren Sie dann die resultierende CSV-Datei in das Redirection-Plugin und ordnen Sie jeden Drupal-Alias seinem WordPress-Äquivalent zu. Für /node/123-Style-URLs, die nie aliasiert wurden, erstellen Sie Regex-basierte Redirects:
/node/([0-9]+)$ → /?p=$1
Dies ordnet Drupal-Node-IDs WordPress-Post-IDs zu — funktioniert aber nur, wenn das FG-Plugin die ursprünglichen Node-IDs als Post-IDs beibehalten hat, was standardmäßig der Fall ist.
Kritisch: Testen Sie jeden Redirect mit curl -I vor dem Go-Live:
curl -I https://yourdomain.com/old-drupal-path
Überprüfen Sie, ob die Antwort HTTP/2 301 mit dem korrekten Location-Header ist, nicht ein 302 oder ein 200 mit einem Soft-Redirect.
Schritt 7: Themes migrieren und Design neu aufbauen
Drupal-Themes (Twig-basiert) haben kein direktes Äquivalent in WordPress. Sie müssen das visuelle Design mit einem WordPress-Theme als Grundlage neu aufbauen.
Theme-Auswahlstrategie

Block-basierte Themes (FSE): Verwenden Sie den WordPress Site Editor für vollständige Layout-Kontrolle ohne Page Builder. Am besten für Entwickler geeignet, die mit Block-Markup vertraut sind.
Klassische Themes mit Page Builder: Themes wie Astra oder GeneratePress in Kombination mit Elementor oder Bricks Builder bieten das nächste Äquivalent zu Drupals Layout Builder.
Benutzerdefiniertes Child-Theme: Wenn Ihre Drupal-Website ein stark angepasstes Design hatte, erstellen Sie ein Child-Theme basierend auf einem minimalen Parent (Underscores, Blocksy) und replizieren Sie das CSS.

Navigationsmenüs neu aufbauen
Drupal-Menüs werden nicht automatisch migriert. Bauen Sie sie unter Design > Menüs (klassische Themes) oder dem Navigationsblock des Site Editors (FSE-Themes) neu auf. Vergleichen Sie Ihre Drupal-Menüstruktur:
drush eval "print_r(menu_tree_all_data('main', NULL));"
Oder fragen Sie die Datenbank direkt ab:
SELECT ml.link_path, ml.link_title, ml.weight, ml.depth
FROM menu_links ml
WHERE ml.menu_name = 'main-menu' AND ml.hidden = 0
ORDER BY ml.weight;
Widgets und Blöcke
Drupal-Blöcke entsprechen grob WordPress-Widgets und Gutenberg-Blöcken. Bauen Sie Sidebar- und Footer-Bereiche unter Design > Widgets oder direkt im Site Editor neu auf. Benutzerdefinierte Drupal-Block-Typen mit PHP-Logik müssen als WordPress-Shortcodes oder benutzerdefinierte Blöcke neu erstellt werden.
Schritt 8: Inhaltsaudit nach der Migration
Überspringen Sie diese Phase nicht. Automatisierte Migrations-Tools verarbeiten strukturierte Inhalte gut, scheitern aber lautlos bei Randfällen.
Prüfungen der Inhaltsintegrität

Eingebettete Medien: Drupals inline Dateireferenzen verwenden ein benutzerdefiniertes Token-Format ([file:123] oder <drupal-media uuid="..."/>). Diese werden in WordPress nicht gerendert. Durchsuchen Sie die Datenbank nach diesen Tokens:

SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%drupal-media%' OR post_content LIKE '%[file:%';

Shortcodes und Views: Drupal Views haben kein WordPress-Äquivalent. Jede Seite, die eine View gerendert hat (z. B. eine gefilterte Inhaltsliste), wird leer sein. Bauen Sie diese mit WP_Query, benutzerdefinierten Post-Type-Archiven oder einem Plugin wie Posts Table Pro neu auf.


Benutzerdefinierte Felder: Drupal-Felddaten, die über das Premium-Plugin migriert wurden, landen in wp_postmeta. Überprüfen Sie, ob Feldwerte vorhanden sind:

SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_key LIKE 'field_%' LIMIT 50;

Benutzerkonten: Wenn Sie Benutzer migriert haben, überprüfen Sie das Rollen-Mapping. Drupals authenticated user-Rolle entspricht WordPress Subscriber. Drupal editor entspricht WordPress Editor. Drupal administrator entspricht WordPress Administrator. Prüfen Sie das Mapping und passen Sie es bei Bedarf an.

Erkennung defekter Links
Installieren Sie Broken Link Checker oder führen Sie einen Crawl mit Screaming Frog gegen Ihre Staging-Umgebung durch, bevor Sie den DNS-Cutover durchführen. Beheben Sie alle internen 404-Fehler vor dem Go-Live — verlassen Sie sich nicht auf die Überwachung nach dem Launch, um diese zu erkennen.
Schritt 9: Performance- und Sicherheitshärtung
Eine frisch migrierte WordPress-Website muss gehärtet werden, bevor sie produktionsbereit ist.
Caching-Konfiguration
Installieren Sie LiteSpeed Cache (bei einem LiteSpeed-Server) oder W3 Total Cache / WP Rocket für Apache/Nginx-Umgebungen. Konfigurieren Sie:

Seiten-Cache mit einer TTL von mindestens 3600 Sekunden für statische Seiten
Object-Cache mit Redis oder Memcached als Backend
Browser-Cache-Header via .htaccess oder Server-Konfiguration

SSL/HTTPS
Stellen Sie sicher, dass Ihre WordPress-Website ausschließlich über HTTPS bereitgestellt wird. Wenn Sie noch kein Zertifikat haben, können SSL-Zertifikate schnell bereitgestellt und für die automatische Erneuerung konfiguriert werden. Aktualisieren Sie die Site-URL-Einstellungen von WordPress:
wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'
Erzwingen Sie HTTPS in .htaccess:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Sicherheitshärtungs-Checkliste

Deaktivieren Sie XML-RPC, wenn nicht benötigt: fügen Sie add_filter('xmlrpc_enabled', '__return_false'); zu functions.php hinzu
Ändern Sie das Standard-wp_-Tabellenpräfix (erfordert Datenbankumbenennung — tun Sie dies vor dem Import, wenn möglich)
Installieren Sie Wordfence oder Solid Security für Firewall- und Login-Schutz
Setzen Sie Dateiberechtigungen: Verzeichnisse 755, Dateien 644, wp-config.php 600

find /var/www/html/wordpress -type d -exec chmod 755 {} ;
find /var/www/html/wordpress -type f -exec chmod 644 {} ;
chmod 600 /var/www/html/wordpress/wp-config.php

Schritt 10: DNS-Cutover und Launch

Führen Sie den DNS-Cutover während Ihres Zeitfensters mit dem geringsten Traffic durch. Der Prozess sollte unter 15 Minuten tatsächlicher Arbeit dauern, mit einem Propagationsfenster von bis zu 48 Stunden (typischerweise 1–4 Stunden für die meisten Resolver).

Abschließende Prüfungen vor dem Cutover

• Führen Sie einen vollständigen Crawl der Staging-URL durch und bestätigen Sie null 404-Fehler
• Überprüfen Sie, ob alle 301-Redirects korrekte Location-Header zurückgeben
• Testen Sie Kontaktformulare, Suchfunktionalität und alle E-Commerce-Abläufe
• Bestätigen Sie, dass die Google Search Console auf der neuen Website verifiziert ist
• Generieren und übermitteln Sie eine neue XML-Sitemap via Yoast SEO oder Rank Math

DNS-Update-Prozess

Wenn Sie Ihre Domain über Domain-Registrierung registriert haben, aktualisieren Sie den A-Record direkt im DNS-Verwaltungspanel. Senken Sie die TTL mindestens 24 Stunden vor dem Cutover auf 300 Sekunden, um die Propagationsverzögerung zu minimieren.

A record: yourdomain.com → [new WordPress server IP]
TTL: 300 (pre-cutover), restore to 3600 post-cutover

Überwachung nach dem Launch

• Aktivieren Sie das Google Search Console-Tool zur Adressänderung, wenn sich die Domain selbst geändert hat
• Überwachen Sie die Core Web Vitals in der Search Console für die ersten 30 Tage — erwarten Sie vorübergehende Ranking-Schwankungen, während Google neu crawlt und neu indexiert
• Richten Sie UptimeRobot oder ein gleichwertiges Tool für die Verfügbarkeitsüberwachung ein
• Überprüfen Sie die Server-Fehlerprotokolle täglich in der ersten Woche:

tail -f /var/log/apache2/error.log
# or for Nginx:
tail -f /var/log/nginx/error.log

Suchmaschinen-Neueinreichung

Reichen Sie Ihre aktualisierte Sitemap in der Google Search Console ein:

1. Gehen Sie zu Search Console > Sitemaps
2. Geben Sie sitemap.xml ein (oder sitemap_index.xml für große Websites)
3. Klicken Sie auf Einreichen

Reichen Sie auch bei Bing Webmaster Tools ein und verifizieren Sie die Website dort unabhängig — Bings Index wird von mehreren KI-Suchmaschinen einschließlich Copilot verwendet.

Empfehlungen zur Hosting-Infrastruktur

Die Performance Ihrer migrierten WordPress-Website hängt stark von der zugrunde liegenden Infrastruktur ab. Eine Migration von Drupal zu WordPress ist ein idealer Zeitpunkt, um auch Ihren Hosting-Stack zu modernisieren.

Für Websites mit moderatem Traffic (10.000–100.000 monatliche Besuche) bietet ein VPS Hosting-Plan mit mindestens 2 vCPUs, 4 GB RAM und NVMe-Speicher ausreichend Spielraum für WordPress mit vollständigem Seiten-Caching. Für Websites mit hohem Traffic oder ressourcenintensive Websites eliminieren Dedizierte Server das Noisy-Neighbor-Problem vollständig und geben Ihnen volle Kontrolle über Kernel-Parameter, MySQL-Konfiguration und Netzwerk-Stack-Tuning.

Wenn Sie mehrere Client-Websites verwalten oder eine GUI-gesteuerte Server-Management-Erfahrung bevorzugen, bieten VPS Control Panels eine Reihe von Optionen einschließlich cPanel, Plesk und DirectAdmin — jede unterstützt Multi-Site-WordPress-Verwaltung, automatisierte Backups und SSL-Bereitstellung über eine einzige Oberfläche.

Technische Entscheidungsmatrix: Wann welchen Migrationsansatz verwenden

Wichtigste technische Erkenntnisse

• Zuerst sichern, bevor Sie irgendetwas anderes tun. Ein komprimierter SQL-Dump und ein Tarball von sites/default/files/ sind Ihr Sicherheitsnetz. Überprüfen Sie, ob beide vollständig und wiederherstellbar sind, bevor Sie beginnen.
• Testen Sie die Datenbankverbindung, bevor Sie den Importer ausführen. Die Mehrheit der fehlgeschlagenen Migrationen stockt beim Verbindungstest aufgrund von Firewall-Regeln oder fehlenden SELECT-Berechtigungen.
• Paragraphenbasierte Drupal-Inhalte erfordern das Premium-Plugin. Die kostenlose Version überspringt Paragraphenfelder lautlos und hinterlässt unvollständige Inhalte ohne Fehlermeldung.
• 301-Redirects sind nicht optional. Jede Drupal-URL, die externe Backlinks oder Suchmaschinen-Indexierung hat, muss mit einem permanenten 301 auf ihr WordPress-Äquivalent weiterleiten. Ein fehlender Redirect ist ein verlorenes Ranking-Signal.
• Senken Sie die DNS-TTL 24 Stunden vor dem Cutover. Setzen Sie sie auf 300 Sekunden, damit die Propagation in Minuten statt Stunden abgeschlossen ist, wenn Sie den A-Record umschalten.
• Prüfen Sie wp_postmeta auf nicht zugeordnete Drupal-Felder. Benutzerdefinierte Felddaten landen nach dem Import dort — überprüfen Sie, ob sie vorhanden und korrekt verschlüsselt sind, bevor Sie die Drupal-Instanz außer Betrieb nehmen.
• Nehmen Sie Drupal nicht sofort außer Betrieb. Halten Sie die Drupal-Umgebung (im Wartungsmodus, nicht öffentlich zugänglich) mindestens 30 Tage nach dem Launch als Referenz und Rollback-Option am Laufen.
• Reichen Sie Ihre Sitemap am selben Tag ein, an dem Sie live gehen. Warten Sie nicht darauf, dass Googlebot die neue Struktur organisch entdeckt — eine aktive Einreichung beschleunigt das Neu-Crawling.

FAQ

Kann ich eine Drupal-Multisite-Installation zu WordPress migrieren?

Ja, aber jede Drupal-Subsite muss einzeln migriert werden. Das FG Drupal to WordPress-Plugin unterstützt Drupal Multisite nicht nativ in einem einzigen Durchlauf. Führen Sie einen separaten Import für jede Subsite durch, der entweder auf ein WordPress-Multisite-Netzwerk oder eigenständige WordPress-Installationen abzielt, abhängig von Ihrer Architektur.

Werden meine Drupal-Benutzerpasswörter zu WordPress übertragen?

Nein. Drupal verwendet einen gesalzenen SHA-512-Hash (oder bcrypt in neueren Versionen), der mit dem phpass-basierten Hashing von WordPress inkompatibel ist. Das FG Premium-Plugin migriert Benutzerkonten, setzt aber Passwörter zurück und löst eine Passwort-Reset-E-Mail an jeden Benutzer aus. Planen Sie die Benutzerkommunikation entsprechend.

Wie gehe ich mit Drupal-Inhaltstypen ohne WordPress-Äquivalent um?

Registrieren Sie äquivalente Custom Post Types (CPTs) in WordPress, bevor Sie den Import ausführen. Das FG Premium-Plugin ermöglicht es Ihnen, Drupal-Inhaltstypen auf WordPress-CPTs abzubilden. Ohne dieses Mapping werden alle Nodes standardmäßig dem post-Post-Type zugeordnet, was Ihre Inhaltsstaxonomie zusammenbricht.

Was passiert mit Drupals Taxonomie-Termen während der Migration?

Drupal-Vokabulare werden WordPress-Taxonomien zugeordnet. Das Standard-Mapping konvertiert Drupal-tags in WordPress-Tags und Drupal-categories in WordPress-Kategorien. Benutzerdefinierte Vokabulare erfordern eine manuelle Taxonomie-Registrierung in WordPress vor dem Import, oder sie werden verworfen.

Wie lange dauert die Migration für eine große Drupal-Website?

Für eine Website mit 5.000 Nodes und 2 GB Medien rechnen Sie auf einem gut ausgestatteten Server mit 2–4 Stunden Importzeit, plus 4–8 Stunden für das Inhaltsaudit und die Redirect-Konfiguration nach der Migration. Der eigentliche DNS-Cutover dauert unter 15 Minuten. Die gesamte verstrichene Zeit vom Start bis zum Go-Live beträgt typischerweise ein bis zwei Werktage für eine gründliche, produktionsreife Migration.