Migration: Plattformwechsel und Umzüge ohne Datenverlust

Jede Software wechselt im Laufe ihres Lebens den Untergrund. Ein Hoster wird zu teuer oder zu langsam, eine Datenbank braucht eine neue Version, eine PHP-Laufzeit nähert sich dem Ende, ein Framework bekommt keine Updates mehr. Wer eine Migration gut plant, merkt am Stichtag wenig davon. Wer sie schlecht plant, verbringt das Wochenende mit Telefonkonferenzen.

Wir behandeln Migrationen wie das, was sie sind: kleine Projekte mit klar definierten Phasen, ausgiebigen Tests und einem ehrlichen Rollback-Plan. Kein „wir ziehen das nächste Woche mal um", sondern eine vorbereitete Aktion, deren Schritte alle Beteiligten kennen.

Was wir konkret tun

Hoster-Umzüge. Sie wechseln vom alten Provider zu einem moderneren Setup, oder direkt in unser Managed Hosting. Wir bauen die neue Umgebung auf, ziehen Daten und Konfiguration sauber um und testen, bevor wir umschalten.

Datenbank-Migrationen. Versionssprünge in MySQL, MariaDB oder PostgreSQL, Wechsel des Datenbanksystems, Konsolidierung mehrerer Datenbanken. Mit Vorab-Test gegen eine Kopie Ihrer Produktivdaten, damit Sie wissen, was Sie am Cutover-Tag erwartet.

PHP-Versionssprünge. Ein eigenes Modul dafür finden Sie unter PHP-Upgrade. Wenn das Upgrade Teil einer größeren Migration ist (etwa zusammen mit einem Hoster-Wechsel), bündeln wir das in einem Migrationsprojekt.

Framework- und Plattformwechsel. Wechsel zwischen Frameworks oder Versionen, Umzug von einer selbstgebauten Plattform auf eine etablierte Lösung. Größere strukturelle Umbauten gehören in die Modernisierung, die wir parallel anbieten.

Ablauf in Schritten

1. Ist-Aufnahme (3–5 Tage). Wir dokumentieren den aktuellen Zustand: Komponenten, Versionen, Konfigurationen, Datenmengen, Abhängigkeiten, kritische Schnittstellen.
2. Migrationsplan. Sie bekommen ein schriftliches Vorgehen mit Phasen, Testschritten, Cutover-Plan und Rollback-Strategie. Inklusive Risiken und Annahmen.
3. Aufbau Zielumgebung. Die neue Umgebung wird sauber aufgesetzt, parallel zur alten. Konfiguration und Geheimnisse werden dokumentiert.
4. Generalprobe. Wir machen mindestens einen vollständigen Probelauf mit aktuellen Produktivdaten in einer Staging-Umgebung. Hier zeigen sich fast immer Punkte, die im Plan ergänzt werden müssen.
5. Cutover im Wartungsfenster. Der eigentliche Umzug läuft in einem vereinbarten Fenster, häufig Sonntagmorgen oder Feiertagsabend. Mit Stoppuhr, Checkliste und definierten Go-/No-Go-Punkten.
6. Stabilisierung. In den ersten Tagen nach dem Cutover beobachten wir das System verstärkt und beheben kleinere Effekte sofort.

Was Sie bekommen

• Schriftlicher Migrationsplan mit Phasen, Aufwänden und Risiken
• Aufbau der Zielumgebung mit dokumentierter Konfiguration
• Mindestens eine vollständige Generalprobe in Staging
• Cutover-Plan mit definierten Go-/No-Go-Kriterien
• Rollback-Plan für den Fall, dass eine Phase nicht abgenommen werden kann
• Stabilisierungsphase nach dem Cutover, typisch 1–2 Wochen
• Übergabe in laufende Wartung oder Managed Hosting, falls gewünscht

Für wen es geeignet ist

Migrationen sind sinnvoll, wenn der aktuelle Untergrund einer Anwendung ans Ende kommt: Hoster zu langsam oder zu teuer, Datenbank- oder Laufzeitversion bald ohne Support, organisatorische Änderungen erfordern einen Wechsel. Auch bei Übernahmen und Zusammenführungen von Unternehmen sind Migrationen häufig nötig.

Nicht jeder Wechsel braucht ein Migrationsprojekt. Ein einfacher Umzug einer statischen Webseite lässt sich in wenigen Stunden erledigen. Wir sagen Ihnen ehrlich, wenn Ihr Vorhaben kein Projekt rechtfertigt.

Was es kostet

Eine kleine Migration (etwa ein PHP-Upgrade mit Datenbank-Versionssprung auf bekannter Infrastruktur) beginnt bei 1.490 € netto. Mittelgroße Projekte liegen zwischen 4.000 und 12.000 €. Komplexe Plattformwechsel mit mehreren Komponenten werden nach detaillierter Schätzung in Phasen abgerechnet. Sie bekommen vor jeder Phase einen Festpreis, den Sie freigeben.

FAQ

Wie lange dauert eine typische Migration?

Vom Erstgespräch bis zum Cutover vergehen meist 4 bis 10 Wochen Kalenderzeit. Die eigentliche Arbeitszeit liegt häufig bei 5 bis 20 Personentagen. Den größten Teil der Zeit machen Generalprobe, Tests und Wartefenster aus, nicht der Cutover selbst.

Können wir während der Migration weiterarbeiten?

In den meisten Fällen ja. Die Vorarbeit findet auf einer Staging-Umgebung statt, ohne Einfluss auf den Live-Betrieb. Nur das Cutover-Fenster selbst bedeutet eine kurze Auszeit, typisch zwischen 30 Minuten und wenigen Stunden. Bei komplexeren Migrationen lässt sich das mit einer Übergangsphase auch ohne vollständige Auszeit gestalten, dann steigt aber der Aufwand.

Was passiert, wenn beim Cutover etwas schiefgeht?

Genau dafür gibt es den Rollback-Plan. Vor jedem Cutover definieren wir Go-/No-Go-Punkte. Wenn ein Punkt nicht erreicht wird, gehen wir zurück auf den vorigen Stand, in den meisten Fällen innerhalb von Minuten. Sie verlieren keine Daten und keinen produktiven Tag. Den nicht gelungenen Versuch nutzen wir, um den Plan nachzubessern und einen neuen Cutover-Termin anzusetzen.

Wir wollen gleichzeitig modernisieren, geht das in einem Projekt?

Manchmal sinnvoll, oft riskant. Eine Migration kombiniert mit einer Modernisierung verdoppelt schnell die Komplexität und die Fehlerquellen. Wir empfehlen meistens, Migration und Modernisierung in zwei aufeinanderfolgenden Phasen abzuwickeln, mit einem stabilen Zwischenzustand. Bei kleineren Vorhaben ist eine Bündelung möglich, das prüfen wir individuell.

Können Sie auch Migrationen übernehmen, die jemand anderes angefangen hat?

Ja, und das passiert öfter als man denkt. Wir machen dann zuerst eine Standortbestimmung: Was wurde bisher gemacht, welche Annahmen liegen dem Plan zugrunde, wo sind die offenen Punkte. Daraus entsteht ein angepasster Plan, der nicht bei null anfängt, aber auch keine offenen Risiken unter den Teppich kehrt.

Bereit, anzufangen?

Lassen Sie uns 30 Minuten sprechen. Sie beschreiben Ihr Vorhaben, wir geben eine erste Einschätzung zu Aufwand, Risiken und realistischem Zeitrahmen. Kostenlos, ohne Vertragsbindung.

Migration planen →