Cloud-Migration

Wir erfassen, was Sie betreiben, womit es spricht und was beim Verschieben bricht: Dienste, Cronjobs, Datei-Uploads, Rückrufe Dritter, fest verdrahtete Adressen und DNS-Einträge, an deren Anlage sich niemand erinnert. Ergebnis ist eine Abhängigkeitskarte und eine kurze, unbeschönigte Liste der Punkte, die diese Migration wirklich schwierig machen.

Wir entwerfen das Ziel — verwaltete Datenbank, Anwendungshosting, Objektspeicher, Hintergrundjobs — und stellen es Ihrer heutigen Rechnung gegenüber, inklusive der gern vergessenen Posten: Egress, Backups, Log-Aufbewahrung und Nicht-Produktivumgebungen. Cloud ist nicht automatisch günstiger, und wenn das Modell für Ihren Bestand spricht, bekommen Sie die Zahlen statt einer Vertriebsantwort.

Rehost ist am schnellsten und verändert am wenigsten, Replatform ersetzt selbst betriebene Komponenten wie den eigenen Datenbankserver durch verwaltete Dienste, Refactor passt Teile der Anwendung an die Plattform an. Wir entscheiden je Workload statt pauschal, denn ein Refactor für ein stabiles Backoffice-Werkzeug ist der klassische Weg, ein Migrationsbudget aufzubrauchen.

Schema und Daten wandern über wiederholbare Skripte ins Ziel, bei passendem Stack über Prisma-Migrationen, und der vollständige Durchlauf wird zunächst gegen eine Kopie gefahren, um die reale Umstellungsdauer zu messen. Das Rollback wird schriftlich festgehalten, zeitlich gemessen und getestet, bevor ein Termin vereinbart wird.

Wir senken DNS-TTLs vorab, stellen Zertifikate auf der neuen Plattform aus und prüfen sie, betreiben beide Umgebungen parallel, soweit das Datenmodell es erlaubt, und schalten den Verkehr in einem definierten Fenster um. Schreibzugriffe pausieren nur so lange wie zwingend nötig; Sessions, Webhooks, geplante Jobs und ausgehende Mail stehen auf derselben Checkliste.

In den ersten Wochen beobachten wir Fehlerraten, Latenz, Datenbankverbindungen und Kosten und passen Dimensionierung sowie Caching an, sobald echter Traffic zeigt, was der Workload braucht. Wir spielen ein Backup tatsächlich zurück, um es zu belegen, und übergeben Runbooks für Deployment, Rollback und Störungsfälle.