Fallstudie zur SaaS-Migration auf einen VPS für sicherere Umschaltungen

Veröffentlicht am 28. September 2026

Die Produktionsdatenbank wuchs schon lange über ihre Shared-Hosting-Umgebung hinaus, bevor sie tatsächlich ausfiel. Während ausgelasteter Zeiträume stiegen die Antwortzeiten, Bereitstellungsfenster fühlten sich riskant an, und das Team hatte keine saubere Wiederherstellungsübung für den Fall, dass ein Plugin-Update oder ein Datenbankproblem schiefging. Diese Fallstudie zur SaaS-Migration auf einen VPS begleitet einen beispielhaften B2B-Softwareanbieter, der seine Anwendung auf einen Managed VPS umstellte, ohne die Migrationsnacht zu einem Glücksspiel zu machen.

Das Unternehmen verfügte über ein Kundenportal, eine API, Worker-Prozesse, eine PostgreSQL-Datenbank und Hintergrund-E-Mail-Jobs, die über eine Hosting-Umgebung liefen, die für diese Arbeitslast zu voll geworden war. Es war keine dramatische Ausfallgeschichte. Solche Geschichten sind selten die nützlichen. Es war eine Geschichte über Risikomanagement: umziehen, bevor normales Wachstum zu einem Vorfall wird.

Der Ausgangspunkt: Ein SaaS-Stack mit wenig Spielraum

Der SaaS-Anbieter betreute rund 3.500 aktive Nutzer, wobei sich der Datenverkehr während der US-Geschäftszeiten konzentrierte. Die Anwendung lief auf einem herkömmlichen Web-Stack: Nginx, PHP-FPM, PostgreSQL, Redis und mehrere geplante Worker-Jobs. Das Team verfügte über Versionsverwaltung und Bereitstellungsskripte, doch die Infrastruktur war auf die übliche praktische Weise gewachsen – ein Dienst nach dem anderen, bis niemand am Freitag noch den Server anfassen wollte.

Der unmittelbare Druck entstand durch die Datenbankleistung. Die CPU-Auslastung war nicht dauerhaft hoch, aber kurze Spitzen führten dazu, dass sich langsame Abfragen anstauten. Immer wenn Backups zeitlich mit Reporting-Jobs zusammenfielen, trat eine Konkurrenz um die Festplatten-Ein-/Ausgabe auf. Die Anwendung konnte sich normalerweise erholen, doch „normalerweise“ ist kein Wiederherstellungsziel.

Das Team benötigte außerdem mehr Kontrolle über PHP-Versionen, Dienstkonfiguration, Firewall-Regeln und Monitoring. Shared Hosting war in der Anfangsphase nützlich gewesen, hatte aber seine natürliche Grenze erreicht. Ein VPS bot dedizierte zugewiesene Ressourcen und Kontrolle auf Root-Ebene, ohne dass das Unternehmen physische Hardware betreiben musste.

Es gab eine Einschränkung, die jede Entscheidung prägte: Kundensitzungen und kostenpflichtige Workflows durften nicht lange unterbrochen werden. Eine Migration mit stundenlangem Ausfall wäre technisch möglich, aber wirtschaftlich unattraktiv gewesen.

Was vor der VPS-Migration geprüft wurde

Vor der Bereitstellung der neuen Umgebung teilte der Migrationsplan das System in Komponenten auf, die unabhängig verschoben werden konnten, und in Komponenten, die eine abschließende Umschaltung erforderten. Statische Anwendungsdateien, Container-Images und der Großteil der Konfiguration konnten frühzeitig kopiert werden. Die Datenbank erforderte mehr Sorgfalt, da sie bis zur abschließenden Umschaltung weiter verändert wurde.

Das Team ermittelte zunächst die tatsächliche Nutzung, statt einen VPS-Tarif aus Optimismus auszuwählen. Es prüfte die CPU-Spitzen, den RAM-Verbrauch, die Datenbankgröße, das Speicherwachstum, das IOPS-Verhalten, die Netzwerkübertragung und die Anzahl gleichzeitig laufender Worker-Prozesse. Der resultierende VPS wurde mit Reserven für Verkehrsspitzen und Wartungsarbeiten dimensioniert, nicht nur mit genügend Kapazität zur Reproduktion der aktuellen Durchschnittswerte.

Die Wahl fiel auf einen Managed VPS, weil das interne Entwicklungsteam die Anwendung verwalten konnte, aber nicht über Nacht für jeden Alarm des Betriebssystems eskalierender Ansprechpartner sein wollte. Dieser Kompromiss sollte klar benannt werden: Unmanaged-VPS-Hosting kann auf dem Papier weniger kosten, verlagert aber Patching, Monitoring, Backup-Validierung und die Triage von Vorfällen auf die eigenen Mitarbeiter. Für Teams mit dedizierten Infrastrukturmitarbeitern kann das sinnvoll sein. Für ein kleines SaaS-Team wird es oft zu einer teuren Ablenkung mit einem niedrigen monatlichen Preisschild.

Der neue VPS wurde abgesichert, bevor Anwendungsdaten eintrafen. Der Zugriff wurde auf SSH-Schlüssel beschränkt, unnötige Dienste wurden entfernt, Firewall-Regeln ließen nur erforderlichen Datenverkehr zu, und automatische Sicherheitsupdates wurden auf ihre Kompatibilität mit dem Stack geprüft. Für Bereitstellungen und Dienstprozesse wurden getrennte Systembenutzer angelegt. Geheimnisse wurden aus der Codebasis in geschützte Konfigurationsdateien verschoben.

Backups wurden in zwei Formen eingerichtet: geplante Off-Server-Backups zur Wiederherstellung nach einem Serververlust sowie datenbankspezifische Backups für eine schnellere Datenwiederherstellung. Ein Backup, das noch nie wiederhergestellt wurde, ist lediglich eine hoffnungsvolle Datei. Das Team stellte ein Datenbank-Backup in einer isolierten Testdatenbank wieder her und bestätigte, dass die Anwendung es korrekt lesen konnte.

Der Migrationsplan nutzte eine gestaffelte Umschaltung

Die Anwendung wurde mehrere Tage vor der Migrationsnacht auf dem neuen VPS bereitgestellt. So hatte das Team Zeit, das Verhalten unter realistischer Last zu vergleichen und kleinere Unterschiede bei PHP-Erweiterungen, Dateiberechtigungen, der Cron-Ausführung, der Redis-Konfiguration und der E-Mail-Zustellung zu beheben. Diese Details sind langweilig, bis sie es nicht mehr sind.

Für End-to-End-Tests wurde ein Staging-Hostname verwendet. Interne Mitarbeiter prüften die Anmeldung, die Kontoerstellung, Abrechnungs-Callbacks, Datei-Uploads, geplante Berichte, die API-Authentifizierung und das Verwaltungsportal. Sie testeten außerdem den Rollback-Pfad. Diesen Teil überspringen viele Migrationen, weil eine Rollback-Planung pessimistisch wirkt. Tatsächlich ermöglicht sie in einer Problemsituation eine ruhige Entscheidung.

Die abschließende Umschaltung umfasste vier operative Phasen:

• Die DNS-TTL im Voraus reduzieren, damit sich Änderungen an den Einträgen schneller verbreiten.
• Eine erste Datenbanksynchronisierung durchführen, während die alte Plattform weiterhin aktiv war.
• Schreibintensive Funktionen für die kurze abschließende Synchronisierung in den Wartungsmodus versetzen.
• DNS aktualisieren, den Produktionsdatenverkehr prüfen und die alte Umgebung verfügbar lassen, bis bestätigt wurde, dass der neue Dienst stabil war.

Bei der anfänglichen Datenübertragung wurde der Großteil der Datenbank verschoben, ohne die Nutzer zu beeinträchtigen. Zum vereinbarten Wartungszeitpunkt pausierte das Team neue Schreibvorgänge, führte eine abschließende inkrementelle Synchronisierung durch und startete die Produktionsdienste auf dem VPS. Die Schreibpause dauerte 11 Minuten. Nutzer, die bereits auf der Website unterwegs waren, konnten die meisten öffentlichen Seiten und Kontoseiten weiterhin lesen, während Aktionen wie die Aktualisierung von Abrechnungsdaten oder das Absenden neuer Datensätze einen kurzen Wartungshinweis anzeigten.

Dieser Ansatz war nicht völlig kompromissfrei. Eine Migration mit nahezu null Ausfallzeit durch Datenbankreplikation kann das abschließende Wartungsfenster weiter verkürzen, erhöht aber die Komplexität und erfordert mehr Vorbereitungszeit. Für diesen SaaS-Anbieter war eine kontrollierte Schreibpause von 11 Minuten sicherer, als ein Replikationsdesign aufzubauen, das das Team später nicht betreiben konnte. Gute Infrastruktur ist nicht immer die komplizierteste Infrastruktur.

Was während der Umschaltung geschah

Der DNS-Eintrag wurde nach der abschließenden Datenbankprüfung aktualisiert. Das Migrationsteam überwachte Zugriffsprotokolle, Fehlerprotokolle, PostgreSQL-Verbindungen, PHP-FPM-Worker-Aktivität, Antwortzeiten und die Tiefe der Hintergrundwarteschlange, während der Datenverkehr den neuen VPS erreichte.

In der ersten Stunde traten zwei Probleme auf. Ein geplanter Reporting-Job verwendete einen fest codierten Pfad vom alten Server, und ein externer API-Anbieter hatte die frühere ausgehende IP-Adresse zugelassen. Keines der beiden Probleme erforderte einen Rollback. Der Pfad des Reporting-Jobs wurde korrigiert und die Zulassungsliste des Anbieters mit der neuen VPS-Adresse aktualisiert. Die Protokolle erzählten nun dieselbe Geschichte.

Das Team ließ die alte Umgebung intakt, deaktivierte dort jedoch öffentliche Schreibvorgänge. So entstand eine geschützte Rollback-Option, während gleichzeitig eine Aufteilung der Daten auf zwei Systeme verhindert wurde. Nach 24 Stunden stabilen Anwendungsverhaltens, erfolgreicher Backups und normaler Verarbeitung der Warteschlangen wurde die alte Umgebung aus dem Produktionsbetrieb genommen.

Ergebnisse nach dem Umzug auf den VPS

Der unmittelbare Gewinn war Konsistenz. Die mediane Antwortzeit der Anwendung verbesserte sich, weil Datenbank und Web-Worker nicht mehr mit anderen Mandanten um Ressourcen konkurrierten. Nützlicher als die Geschwindigkeitssteigerung war die Transparenz: Das Team konnte CPU, RAM, Festplatte, Netzwerk, Dienststatus und Datenbankverhalten in einer einzigen Betriebsansicht sehen.

Der SaaS-Anbieter erhielt außerdem einen saubereren Wartungsablauf. Updates konnten vor der Produktion im Staging getestet werden, Backups liefen außerhalb der Spitzenzeiten des Reportings, und für Warnmeldungen waren Verantwortliche festgelegt. Dank des verwalteten Betriebssupports und des aktiven Monitorings durch kodu.cloud verfügte das interne Team über einen klareren Eskalationsweg, wenn die Infrastruktur Aufmerksamkeit erforderte.

Die Migration beseitigte nicht jede Verantwortung. Der Kunde blieb für Anwendungs-Releases, Datenkorrektheit, Benutzerberechtigungen und Anbieterintegrationen verantwortlich. Die Hosting-Schicht konnte überwacht, gepatcht, gesichert und unterstützt werden, aber kein Anbieter kann feststellen, ob eine neu bereitgestellte Funktion einen Fehler in der Geschäftslogik enthält. Klare Verantwortungsgrenzen sind Bestandteil einer gesunden Umgebung.

Erkenntnisse für SaaS-Teams, die einen Umzug auf einen VPS planen

Die wichtigste Erkenntnis ist, dass die Qualität der Migration vor dem Umschaltungsfenster entschieden wird. Der beste Zeitpunkt, um einen nicht dokumentierten Cron-Job, eine abgelaufene API-Zugangsdaten oder eine übergroße Datenbanktabelle zu entdecken, ist während des Stagings – nicht, wenn Kunden ihren Browser aktualisieren.

Beginnen Sie mit gemessener Ressourcennutzung und lassen Sie anschließend Raum für Wachstum. Richten Sie den neuen Server früh genug ein, um reale Workflows zu testen. Bestätigen Sie Backups, indem Sie sie wiederherstellen. Legen Sie fest, was einen Rollback auslöst und wer diese Entscheidung treffen darf. Überwachen Sie den Dienst schließlich nach DNS-Änderungen, statt den Sieg zu erklären, sobald der Bereitstellungsbefehl abgeschlossen ist.

Eine VPS-Migration sollte Ihrem Team mehr Kontrolle und weniger nächtliches Rätselraten verschaffen. Wenn der Plan getestete Wiederherstellung, eine gestaffelte Übertragung und Mitarbeiter umfasst, die den Server nach Eintreffen des Datenverkehrs überwachen, kann der Dienst wieder ruhig laufen.

Andres Saar Kundenbetreuungsingenieur