Webseite mit Datenbank auf neuen Server umziehen — Schritt für Schritt

Rolf Heisig · · Aktualisiert: 2. Februar 2026 · 7 Min. Lesezeit
Backup
Serverumzug mit Datenbank — Anleitung für reibungslose Migration

Serverumzug. Allein das Wort sorgt bei vielen Webmastern für Schweissausbrueche. Dabei ist ein Umzug kein Hexenwerk — solange du systematisch vorgehst und nichts vergisst. Das Problem ist nicht die Technik, sondern die Reihenfolge. Wer die falsch macht, hat danach eine kaputte Seite auf zwei Servern statt einer funktionierenden auf einem.

Hier ist die komplette Anleitung, die ich bei jedem Serverumzug abarbeite. Funktioniert für WordPress, Joomla, phpBB, Magento und jede andere PHP-Anwendung mit MySQL-Backend.

Schritt 1: Dateien per FTP/SSH sichern

Zuerst lädst du alle Dateien deiner Webseite vom alten Server herunter. Per FTP geht das, ist aber bei vielen Dateien quälend langsam. Wenn du SSH-Zugang hast, ist ein Archiv deutlich schneller:

# Per SSH: Alle Dateien als Archiv packen
cd /var/www/html/
tar -czf /home/user/website_backup.tar.gz meine-seite/

# Dann per SCP auf deinen lokalen Rechner
scp user@alter-server:/home/user/website_backup.tar.gz ./

Per FTP verwendest du FileZilla oder WinSCP und lädst den kompletten Ordner herunter. Tipp: Bei vielen kleinen Dateien (WordPress hat tausende) ist die Übertragung per FTP extrem langsam. Das Archiv per SSH ist hundertmal schneller.

Schritt 2: Datenbank sichern

Der wichtigste Schritt. Ohne Datenbank-Backup ist der Umzug zum Scheitern verurteilt. Du hast mehrere Möglichkeiten:

Option A: mysqldump (Kommandozeile)

mysqldump -u dbuser -p --single-transaction --routines --triggers meine_datenbank > datenbank_backup.sql

Mehr Details dazu findest du im mysqldump-Tutorial.

Option B: MySQLDumper (Weboberfläche)

Ideal für Shared-Hosting ohne SSH-Zugang. MySQLDumper umgeht PHP-Timeouts und kann auch große Datenbanken zuverlässig sichern. Das Backup wird als .sql.gz-Datei auf dem Server abgelegt — diese dann per FTP herunterladen.

Option C: phpMyAdmin

Im Hosting-Panel phpMyAdmin öffnen, Datenbank auswählen, auf „Exportieren“ klicken. Bei Datenbanken über 50 MB wird das allerdings unzuverlässig — dann lieber mysqldump oder MySQLDumper verwenden.

Wichtig: Prüfe nach dem Export, dass die Dump-Datei vollständig ist:

# Dateigröße prüfen
ls -lh datenbank_backup.sql

# Ende der Datei prüfen — muss "Dump completed" enthalten
tail -3 datenbank_backup.sql

Schritt 3: Dateien auf den neuen Server hochladen

Die gesicherten Dateien auf den neuen Server übertragen:

# Per SCP
scp website_backup.tar.gz user@neuer-server:/var/www/html/

# Auf dem neuen Server entpacken
ssh user@neuer-server
cd /var/www/html/
tar -xzf website_backup.tar.gz

Bei Shared-Hosting ohne SSH lädst du die Dateien per FTP in das Webroot-Verzeichnis hoch. Das kann bei großen Seiten mehrere Stunden dauern — plane das ein.

Schritt 4: Neue Datenbank anlegen und Backup einspielen

Auf dem neuen Server musst du zuerst eine neue Datenbank und einen Benutzer anlegen:

# Per MySQL-Kommandozeile
mysql -u root -p

CREATE DATABASE meine_datenbank CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'dbuser_neu'@'localhost' IDENTIFIED BY 'sicheres_passwort';
GRANT ALL PRIVILEGES ON meine_datenbank.* TO 'dbuser_neu'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Bei den meisten Hostern erstellst du Datenbank und Benutzer über das Hosting-Panel (cPanel, Plesk, etc.).

Dann das Backup einspielen:

mysql -u dbuser_neu -p meine_datenbank < datenbank_backup.sql

Bei großen Dumps kann das eine Weile dauern. Falls Timeout-Probleme auftreten, hilft die Anleitung unter MySQL-Datenbank sichern und wiederherstellen.

Schritt 5: Konfigurationsdatei anpassen

Auf dem neuen Server haben sich die Zugangsdaten geändert. Du musst die Konfigurationsdatei deiner Anwendung anpassen:

WordPress (wp-config.php)

define('DB_NAME', 'meine_datenbank');
define('DB_USER', 'dbuser_neu');        // Neuer Benutzer
define('DB_PASSWORD', 'sicheres_passwort'); // Neues Passwort
define('DB_HOST', 'localhost');          // Beim neuen Hoster prüfen!

Joomla (configuration.php)

public $host = 'localhost';
public $user = 'dbuser_neu';
public $password = 'sicheres_passwort';
public $db = 'meine_datenbank';

phpBB (config.php)

$dbhost = 'localhost';
$dbuser = 'dbuser_neu';
$dbpasswd = 'sicheres_passwort';
$dbname = 'meine_datenbank';

Achtung beim DB_HOST: Bei vielen Hostern ist der Datenbank-Host nicht localhost, sondern ein spezieller Server wie rdbms.strato.de oder db1234.hosting.de. Das steht in deinem Hosting-Panel.

Schritt 6: Pfade in der Datenbank aktualisieren (Search-Replace)

Das ist der Schritt, den die meisten vergessen — und der die meisten Probleme verursacht. In der Datenbank stehen an vielen Stellen absolute URLs und Dateipfade. Wenn sich die Domain oder der Serverpfad ändert, müssen diese aktualisiert werden.

WordPress: wp_options anpassen

Die wichtigsten Einträge sind siteurl und home in der Tabelle wp_options:

UPDATE wp_options SET option_value = 'https://www.neue-domain.de' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://www.neue-domain.de' WHERE option_name = 'home';

Das Problem mit serialisierten Daten

WordPress speichert viele Einstellungen als serialisierte PHP-Arrays in der Datenbank. Das sieht so aus:

a:2:{s:4:"home";s:24:"https://www.alte-url.de";s:7:"siteurl";s:24:"https://www.alte-url.de";}

Siehst du das s:24? Das ist die Länge des Strings. Wenn du jetzt einfach per SQL-Replace die URL änderst und die neue URL eine andere Länge hat, stimmt die Zeichenanzahl nicht mehr — und PHP kann die Daten nicht mehr deserialisieren. Die Folge: Widgets verschwinden, Theme-Einstellungen sind weg, Plugin-Konfigurationen kaputt.

Lösung: Verwende das Tool WP-CLI oder das PHP-Skript Search-Replace-DB von interconnect/it:

# WP-CLI (empfohlen)
wp search-replace 'https://www.alte-domain.de' 'https://www.neue-domain.de' --all-tables

# Auch den Serverpfad ersetzen, falls geändert
wp search-replace '/var/www/alte-seite' '/var/www/neue-seite' --all-tables

WP-CLI berücksichtigt automatisch die serialisierten Daten und passt die Zeichenlängen korrekt an. Ein einfaches UPDATE ... SET ... REPLACE() in SQL tut das nicht.

Alternatives Tool: Search-Replace-DB

# Herunterladen und in WordPress-Root entpacken
# Dann im Browser aufrufen: https://deine-seite.de/Search-Replace-DB/

# WICHTIG: Nach der Ersetzung das Verzeichnis sofort löschen!
rm -rf /var/www/html/Search-Replace-DB/

Schritt 7: DNS umstellen

Erst wenn alles auf dem neuen Server funktioniert, stellst du den DNS um. Ändere die A-Records (und AAAA für IPv6) bei deinem Domain-Registrar auf die neue Server-IP:

Typ    Name    Wert              TTL
A      @       123.456.789.10    3600
A      www     123.456.789.10    3600
AAAA   @       2001:db8::1       3600

Tipp: Setze die TTL (Time to Live) schon ein paar Tage vor dem Umzug auf einen niedrigen Wert (z.B. 300 Sekunden). So dauert die DNS-Propagation nach der Umstellung nur wenige Minuten statt bis zu 48 Stunden.

Bis die DNS-Änderung weltweit propagiert ist, können beide Server Anfragen bekommen. Deshalb sollte der alte Server noch einige Tage weiterlaufen.

WordPress-spezifische Hinweise

  • Permalinks: Nach dem Umzug unter Einstellungen → Permalinks die Struktur einmal speichern (auch ohne Änderung). Das regeneriert die .htaccess.
  • Cache leeren: Falls du ein Caching-Plugin nutzt, den Cache komplett leeren.
  • SSL-Zertifikat: Auf dem neuen Server muss ein gültiges SSL-Zertifikat eingerichtet sein, bevor du die DNS umstellst. Let's Encrypt ist kostenlos und schnell eingerichtet.
  • Cronjobs: Falls du Server-Cronjobs statt WP-Cron nutzt, müssen diese auf dem neuen Server neu eingerichtet werden.
  • E-Mail: Wenn der alte Server auch als Mailserver diente, vergiss nicht die MX-Records.

Goldene Regel: Nie Update und Umzug gleichzeitig

Ich sage das bei jeder Gelegenheit, weil es so wichtig ist: Mache niemals ein Software-Update und einen Serverumzug gleichzeitig. Wenn danach etwas nicht funktioniert, weißt du nicht, ob es am Update oder am Umzug liegt. Die richtige Reihenfolge:

  1. Webseite auf dem alten Server komplett aktualisieren und testen
  2. Warten, bis alles stabil läuft
  3. Dann erst den Umzug durchführen

Oder umgekehrt: Erst umziehen, testen, und dann auf dem neuen Server aktualisieren.

Checkliste Serverumzug

Schritt Erledigt?
Dateien vom alten Server gesichert
Datenbank exportiert und Dump geprüft
Dateien auf neuen Server hochgeladen
Neue Datenbank + Benutzer angelegt
Datenbank-Dump importiert
Konfigurationsdatei angepasst
URLs in der Datenbank ersetzt (Search-Replace)
Seite per hosts-Datei getestet
SSL-Zertifikat auf neuem Server eingerichtet
DNS umgestellt
Alter Server nach 7 Tagen abgeschaltet

Fazit

Ein Serverumzug ist kein Grund zur Panik, solange du die sieben Schritte der Reihe nach abarbeitest. Die häufigsten Fehler sind vergessene Datenbank-Backups, nicht angepasste Konfigurationsdateien und fehlendes Search-Replace für URLs in der Datenbank. Falls nach dem Umzug Probleme auftreten, hilft der Artikel MySQL-Fehler beheben bei der Diagnose. Besonders bei WordPress sind die serialisierten Daten ein Stolperstein — verwende immer WP-CLI oder ein spezialisiertes Tool für die URL-Ersetzung.

Ausführliche Anleitungen für die einzelnen Schritte findest du im mysqldump-Tutorial und im Artikel MySQL-Datenbank sichern.