Kundenbereich
Linux•29. August 2026• 12 Aufrufe

Eine Website vom Shared Hosting auf einen VPS migrieren (2026)

Eine Website vom Shared Hosting auf einen VPS migrieren (2026)

Warum auf einen VPS migrieren?

Shared Hosting eignet sich für Websites mit geringem Traffic und Projekte, die keine Kontrolle über die Serverumgebung benötigen. Manche Anforderungen sprengen diesen Rahmen: eine bestimmte PHP-Version, die nicht verfügbar ist, Root-Zugriff für eine Systemabhängigkeit, Leistungseinbußen durch Nachbarn auf dem geteilten Knoten oder die Notwendigkeit, mehrere Projekte mit isolierten Konfigurationen zu hosten. Die Migration auf einen VPS beantwortet genau diese Fälle, ohne dass Shared Hosting für die von ihm abgedeckten Anwendungen ungeeignet wäre.

Schritt 1: Inventar vor der Migration

Erstellen Sie das vollständige Inventar, bevor Sie irgendetwas anfassen. Eine gescheiterte Migration geht fast immer auf ein in dieser Phase vergessenes Element zurück.

Dateien und Verzeichnisse

  • Haupt-Webverzeichnis (oft public_html/, www/ oder htdocs/)
  • Konfigurationsdateien außerhalb des Web-Roots (.env-Dateien, Anwendungskonfigurationen)
  • Von Benutzern hochgeladene Dateien (oft in einem Unterordner uploads/ oder storage/)
  • Auf dem Shared Hosting konfigurierte Cronjobs (über das Control Panel des aktuellen Hosters auflisten)

Datenbank

  • Datenbankname, Benutzername, Passwort (im Panel oder in der Konfigurationsdatei der Anwendung verfügbar)
  • Auf dem Shared Hosting verwendete MySQL/MariaDB-Version (Kompatibilität mit der Zielversion prüfen)

E-Mails

  • Beim Shared-Hosting-Anbieter gehostete Postfächer migrieren nicht automatisch auf den VPS
  • Die aktiven E-Mail-Adressen auflisten und entscheiden: auf den VPS migrieren (Postfix/Dovecot), zu einem Drittanbieter umziehen oder beim aktuellen Anbieter belassen und die MX-Einträge unverändert lassen

DNS und TTL

Vor jeder Migration die TTL des A-Eintrags der Domain auf 300 Sekunden (5 Minuten) senken. Das verkürzt die Propagationszeit bei der finalen Umstellung.

Den A-Eintrag in der DNS-Zone der Domain lokalisieren (normalerweise im Panel des Registrars oder des aktuellen Hosters) und den TTL-Wert ändern:

; Vor der Migration: übliche TTL (oft 3600 oder 86400)
meineseite.de.  3600  IN  A  1.2.3.4

; Mindestens 24h vor der Umstellung auf 300 ändern
meineseite.de.  300   IN  A  1.2.3.4

Nach der Änderung mindestens die Dauer der alten TTL abwarten, bevor Sie mit der Umstellung fortfahren, damit die Propagation wirksam ist.

Schritt 2: Den VPS vorbereiten

Den VPS installieren und absichern, bevor Daten übertragen werden. Nicht auf einen unkonfigurierten Server migrieren.

Schritt 3: Die Dateien übertragen

Mit rsync (SSH-Zugriff auf dem Shared Hosting verfügbar)

rsync ist die empfohlene Methode: Es überträgt nur geänderte Dateien, unterstützt die Wiederaufnahme nach einer Unterbrechung und erhält die Berechtigungen. Quelle: man rsync

Vom VPS aus (die Dateien vom Shared Hosting ziehen):

rsync -avz --progress \
  [email protected]:/home/benutzer/public_html/ \
  /var/www/meineseite.de/

Oder von einem lokalen Rechner aus (bei SSH-Zugriff auf beide Server):

rsync -avz --progress \
  [email protected]:/home/benutzer/public_html/ \
  [email protected]:/var/www/meineseite.de/

Verwendete Optionen:

  • -a: Archivmodus (erhält Berechtigungen, Zeitstempel, symbolische Links)
  • -v: ausführlich (zeigt die übertragenen Dateien an)
  • -z: Kompression während der Übertragung
  • --progress: zeigt den Fortschritt an

Ohne SSH-Zugriff auf dem Shared Hosting (SFTP oder manueller Download)

Bietet das Shared Hosting keinen SSH-Zugriff, verwenden Sie einen SFTP-Client (FileZilla, Cyberduck), um die Dateien lokal herunterzuladen, und senden Sie sie dann auf den VPS:

# Vom lokalen Rechner auf den VPS
rsync -avz --progress /lokaler/pfad/public_html/ \
  benutzer@vps-ip:/var/www/meineseite.de/

Berechtigungen anpassen

sudo chown -R www-data:www-data /var/www/meineseite.de
sudo find /var/www/meineseite.de -type d -exec chmod 755 {} \;
sudo find /var/www/meineseite.de -type f -exec chmod 644 {} \;

Schritt 4: Die Datenbank exportieren und importieren

Export vom Shared Hosting

Wenn das Shared Hosting SSH-Zugriff bietet:

mysqldump -u db_benutzer -p db_name > export-$(date +%F).sql

Ohne SSH-Zugriff phpMyAdmin verwenden (auf den meisten Shared-Hosting-Angeboten verfügbar): Exportieren > SQL-Format > Herunterladen.

Quelle: dev.mysql.com: mysqldump

Die Exportdatei auf den VPS übertragen

scp export-$(date +%F).sql benutzer@vps-ip:/home/benutzer/

Die Datenbank auf dem VPS erstellen

sudo mariadb -u root
CREATE DATABASE db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'db_benutzer'@'localhost' IDENTIFIED BY 'starkes_passwort';
GRANT ALL PRIVILEGES ON db_name.* TO 'db_benutzer'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Die Daten importieren

mariadb -u db_benutzer -p db_name < /home/benutzer/export-$(date +%F).sql

Schritt 5: Die Anwendung auf dem VPS neu konfigurieren

Konfigurationsdatei der Anwendung

Die Datenbank-Verbindungsparameter in der Konfigurationsdatei der Anwendung aktualisieren (.env, wp-config.php, config.php je nach Framework):

  • Datenbank-Host: localhost (die Datenbank liegt auf demselben Server)
  • Datenbankname, Benutzer und Passwort: die im vorherigen Schritt erstellten

Absolute Pfade

Alle in der Konfiguration fest codierten absoluten Pfade prüfen und aktualisieren. Auf einem Shared Hosting beginnen die Pfade oft mit /home/benutzer/public_html/; auf dem VPS beginnen sie mit /var/www/meineseite.de/.

URLs in der Datenbank (falls zutreffend)

Manche Anwendungen (insbesondere WordPress) speichern die Website-URL in der Datenbank. Ändert sich die URL bei der Migration, müssen diese Werte aktualisiert werden. Für WordPress WP-CLI verwenden:

sudo -u www-data wp search-replace 'http://alte-domain.de' 'https://meineseite.de' \
  --path=/var/www/meineseite.de

Für andere Anwendungen die Dokumentation des jeweiligen Frameworks konsultieren.

Nginx-vhost

Den Nginx-vhost für die Website erstellen. Für eine generische PHP-Website:

server {
    listen 80;
    server_name meineseite.de www.meineseite.de;
    root /var/www/meineseite.de;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.4-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}
sudo ln -s /etc/nginx/sites-available/meineseite.de /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Für WordPress: WordPress-auf-VPS-Anleitung (spezifischer vhost mit Permalink-Verwaltung).

Schritt 6: Die Website vor der DNS-Umstellung testen

Niemals das DNS umstellen, ohne geprüft zu haben, dass die Website auf dem VPS funktioniert. Die lokale hosts-Datei bearbeiten, um die Auflösung auf die neue IP zu erzwingen, ohne das öffentliche DNS anzufassen.

Die lokale hosts-Datei bearbeiten

Unter Linux oder macOS:

sudo nano /etc/hosts

Unter Windows: C:\Windows\System32\drivers\etc\hosts (als Administrator öffnen)

Die Zeile hinzufügen:

vps-ip  meineseite.de www.meineseite.de

Der Browser löst meineseite.de jetzt zum VPS auf, ohne dass andere Benutzer betroffen sind.

Zu prüfende Punkte

  • Startseite und interne Seiten werden korrekt angezeigt
  • Kontaktformulare funktionieren (E-Mail-Versand)
  • Anmeldung im Verwaltungsbereich
  • Hochgeladene Dateien sind erreichbar (Bilder, Dokumente)
  • Weiterleitungen sind aktiv (301, 302)
  • Keine Fehler in den Nginx-Logs: sudo tail -f /var/log/nginx/error.log

Den hosts-Eintrag nach den Tests entfernen

# Die zu /etc/hosts hinzugefügte Zeile entfernen
sudo nano /etc/hosts

Schritt 7: Das SSL-Zertifikat ausstellen

Das Let's-Encrypt-Zertifikat vor der DNS-Umstellung auszustellen ist nicht möglich (Certbot muss die Domain zum VPS auflösen können). Das Zertifikat direkt nach der Umstellung ausstellen, solange die niedrige TTL noch aktiv ist.

sudo certbot --nginx -d meineseite.de -d www.meineseite.de

Komplette Anleitung: OuiHeberg-Certbot-Anleitung.

Schritt 8: Das DNS umstellen

Sobald die Tests validiert sind, den A-Eintrag der Domain auf die VPS-IP ändern:

; Vorher
meineseite.de.  300  IN  A  1.2.3.4   (alte Shared-Hosting-IP)

; Nachher
meineseite.de.  300  IN  A  5.6.7.8   (neue VPS-IP)

Mit der TTL von 300 Sekunden ist die Propagation für die meisten DNS-Resolver innerhalb von 5 bis 10 Minuten wirksam. Die Nginx-Logs während dieser Zeit beobachten, um zu bestätigen, dass der Traffic auf dem VPS ankommt:

sudo tail -f /var/log/nginx/access.log

Sobald die Propagation bestätigt ist, die TTL wieder auf einen Standardwert (3600 oder 86400) anheben:

meineseite.de.  3600  IN  A  5.6.7.8

Schritt 9: Übergangsphase

Das Shared Hosting nach der Umstellung noch 1 bis 2 Wochen aktiv lassen. Diese Phase ermöglicht:

  • Beim ursprünglichen Inventar vergessene Dateien wiederzubeschaffen
  • Zu prüfen, dass auf dem Shared Hosting gehostete E-Mails weiterhin ankommen (wenn die MX-Einträge unverändert sind)
  • Bei einem kritischen Problem einen schnellen Rückkehrpunkt zu haben

Die Daten auf dem Shared Hosting nicht löschen, bevor bestätigt ist, dass auf dem VPS alles korrekt funktioniert.

Häufige Fallen

Die E-Mails bleiben beim alten Anbieter

Hatte die Domain Postfächer auf dem Shared Hosting, zeigen die MX-Einträge nach der Umstellung des A-Eintrags weiterhin auf den alten Anbieter. Das ist oft gewollt (E-Mails während der Übergangszeit beim aktuellen Anbieter belassen), aber prüfen Sie, dass es beabsichtigt ist. Die E-Mail-Strategie explizit vor der DNS-Umstellung festlegen.

Die Cronjobs laufen nicht mehr

Im Panel des Shared Hostings konfigurierte geplante Aufgaben migrieren nicht automatisch. Sie im Crontab des VPS neu anlegen:

crontab -e

Die Cronjobs des alten Hosters vor der Migration über dessen Control Panel auflisten (Inventar-Schritt).

Das SSL-Zertifikat wird nicht sofort ausgestellt

Certbot kann kein Zertifikat für eine Domain ausstellen, die noch nicht auf den VPS zeigt. Das Zertifikat direkt nach der DNS-Umstellung ausstellen, solange die niedrige TTL noch aktiv ist. Zwischen der Umstellung und der Zertifikatsausstellung ist die Website nur über HTTP erreichbar.

Absolute Pfade in der Datenbank

Manche Anwendungen speichern absolute Pfade in der Datenbank (Pfad zu hochgeladenen Dateien, Bild-URLs). Diese Pfade müssen nach der Migration aktualisiert werden. Die Suchen/Ersetzen-Funktion der Anwendung oder ein SQL-Skript verwenden:

UPDATE wp_options SET option_value = REPLACE(option_value,
  '/home/alt/public_html',
  '/var/www/meineseite.de')
WHERE option_value LIKE '%/home/alt/public_html%';

Häufige Fragen

Wie lange dauert eine Migration?

Für eine Standard-Website (einige hundert MB, eine Datenbank vernünftiger Größe) dauert die technische Migration 1 bis 3 Stunden. Die Vorbereitung (Inventar, TTL-Senkung, VPS-Konfiguration) macht den Großteil der Zeit aus. Die DNS-Umstellung selbst dauert mit einer TTL von 300 Sekunden weniger als 10 Minuten.

Kann man ohne Serviceunterbrechung migrieren?

Ja, wenn das Verfahren in der richtigen Reihenfolge befolgt wird: Die Website bleibt während der gesamten Vorbereitung und der Tests auf dem Shared Hosting aktiv. Die einzige potenzielle Unterbrechung ist das Fenster zwischen der DNS-Umstellung und der Ausstellung des SSL-Zertifikats (wenige Minuten). Mit einer TTL von 300 Sekunden ist dieses Fenster kurz.

Sollte man die Besucher informieren?

Bei einer Website mit geringem Traffic: nein. Bei einem E-Commerce-Shop oder einer Anwendung mit angemeldeten Benutzern (aktive Sitzungen) die Migration außerhalb der Stoßzeiten planen und während der Umstellung eine Wartungsseite anzeigen.

Was tun, wenn die Website nach der Umstellung nicht funktioniert?

Den A-Eintrag wieder auf die alte Shared-Hosting-IP setzen (die TTL von 300 Sekunden erlaubt eine schnelle Rückkehr). Das Problem auf dem VPS ohne Zeitdruck diagnostizieren und die Umstellung erneut durchführen, sobald das Problem gelöst ist. Genau dafür muss das Shared Hosting während der Übergangsphase aktiv bleiben.

Noch nicht entschieden? Unser Artikel VPS oder Shared Hosting zeigt, wann sich die Migration lohnt.

Migrieren Sie mehrere Websites auf denselben VPS? Legen Sie Verzeichnisstruktur und Isolation vorab fest: Multi-Site-Konfiguration mit Nginx.

Zurück zur Dokumentation