Souveräne Cloud-Migration auf STACKIT: die Fallstricke, die vor dem Umzug entschieden werden

Eine Migration auf STACKIT scheitert selten an der Plattform und fast immer an dem, was vorher nicht aufgeschrieben wurde: Abhängigkeiten, Speicherprofile, Verantwortlichkeiten. Wer diese drei Dinge vor dem Umzug klärt, bekommt eine souveräne Cloud ohne Überraschungen; wer sie überspringt, bekommt dieselben Probleme wie bei jedem anderen Anbieter, nur mit deutschem Rechenzentrum.

Was STACKIT von einem Umzug zu einem Hyperscaler unterscheidet

STACKIT ist die Cloud der Schwarz-Gruppe, betrieben in Rechenzentren in Deutschland und Österreich, technisch auf OpenStack und Kubernetes aufgebaut. Für IT-Leitungen in regulierten Branchen ist das der Grund, hinzuschauen: Die Daten bleiben unter europäischem Recht, und die Bausteine sind offene Standards, die Sie kennen.

Der Umkehrschluss ist wichtig. Was Sie bei einem US-Anbieter als Managed Service dazubuchen, gibt es bei STACKIT nicht in jeder Ausprägung. Wer sein Altsystem unverändert hinüberschiebt und erwartet, dass die Plattform Datenbank, Identitäten und Monitoring von allein regelt, wird enttäuscht. Die Migration ist deshalb weniger ein Umzug als eine Gelegenheit, die Architektur auf den Stand zu bringen, auf dem sie sein sollte.

Der häufigste Fehler: keine Abhängigkeitsanalyse vor der Migration

Ohne vollständige Liste der Abhängigkeiten fallen Dinge aus, von denen niemand wusste, dass sie zusammenhängen. Typisch ist der Anmeldedienst: Eine Anwendung läuft in der neuen Umgebung, meldet aber niemanden mehr an, weil sie still auf ein lokales Active Directory zugreift, das im Rechenzentrum zurückgeblieben ist. Genauso: Cronjobs, die auf eine Netzwerkfreigabe schreiben, fest eingetragene IP-Adressen in Konfigurationsdateien, eine Schnittstellenversion, die nur der frühere Dienstleister kennt.

Die Gegenmaßnahme ist unspektakulär. Jede Anwendung bekommt eine Karte: Welche Dienste ruft sie auf, welche rufen sie auf, über welche Ports, mit welchen Zugangsdaten. Diese Karte entsteht aus Konfigurationsdateien, Firewall-Logs und Gesprächen mit den Leuten, die das System betreiben. Erst wenn die Karte für eine Anwendung vollständig ist, wird sie für die Migration eingeplant.

Sicherheit: Voreinstellungen sind keine Konfiguration

Die Plattform bringt Verschlüsselung, Netzsegmente und Zugriffsverwaltung mit. Ob sie eingeschaltet sind, entscheiden Sie. Ein häufiges Muster: Die Verschlüsselung ruhender Daten ist vorhanden, aber der eigene Schlüssel wurde nie hinterlegt, und im Audit fehlt der Nachweis, wer ihn kontrolliert. Oder: Alle Instanzen landen in einem Netzsegment, weil die Segmentierung „später“ kommen sollte.

Schreiben Sie Ihre Mindestanforderungen als Code auf: ein Skript, das jede neue Ressource mit Verschlüsselung, Netzregeln und Protokollierung anlegt, wie es Ihre internen Vorgaben verlangen. Dann ist die Frage „Haben wir das aktiviert?“ keine Frage mehr, sondern ein Blick ins Repository.

Kosten: falsch dimensionierte Instanzen fressen den Vorteil auf

STACKIT rechnet transparent ab. Teuer wird es trotzdem, wenn Entwicklungs- und Testumgebungen dieselbe Größe bekommen wie die Produktion oder wenn Backups auf Blockspeicher liegen, obwohl Objektspeicher reicht. Legen Sie vor der Migration je Umgebung ein Budget fest, lassen Sie sich bei Überschreitung benachrichtigen und fahren Sie Testumgebungen nachts herunter. Das klingt banal und ist der häufigste Grund, warum die erste Cloud-Rechnung höher ausfällt als das alte Rechenzentrum.

Legacy-Software modernisieren ohne Ausfall: phasenweise mit Rückweg

Migrieren Sie nach Geschäftskritikalität, nicht nach Alphabet. Zuerst kommen Anwendungen, deren Ausfall niemand um drei Uhr nachts bemerkt: Reporting, interne Werkzeuge, Testsysteme. Dort lernen Sie die Plattform kennen, prüfen Latenz und Sicherheitskonfiguration und korrigieren Ihre Vorgehensweise. Kernsysteme folgen, wenn die ersten Phasen sauber liefen.

Jede Phase braucht einen Rückweg, den Sie vorher geübt haben: Wie kommt die Anwendung zurück in die alte Umgebung, wie kommen die Daten zurück, wer entscheidet den Abbruch und bis wann. Bei Kernsystemen bewährt sich der Parallelbetrieb: Beide Umgebungen laufen, die Daten werden synchronisiert, der Umschalttag ist ein Tag wie jeder andere. Das kostet für einige Wochen doppelte Infrastruktur und spart die Nacht, in der ein Rückweg improvisiert werden müsste.

Wie dataso solche Migrationen anpackt

Wir beginnen jede Modernisierung mit einem zweistufigen Assessment: Erst die Karte der Abhängigkeiten und die ehrliche Bewertung, was migriert, was neu gebaut und was abgeschaltet wird. Dann ein Prüflauf mit einer unkritischen Anwendung, an dem sich Zeitplan und Budget für den Rest messen lassen. Betrieb und Wartung übernehmen wir danach mit verbindlichen Reaktionszeiten, wenn Sie das wollen; wenn Ihre IT das selbst kann, übergeben wir dokumentiert.

Der nächste Schritt

Nehmen Sie die Anwendung, die Sie zuerst migrieren wollen, und versuchen Sie, ihre Abhängigkeiten auf einer Seite aufzuzeichnen. Wenn die Seite Lücken hat, ist das die Aufgabe vor der Migration. Wir gehen sie in einer halben Stunde mit Ihnen durch: Potenzial-Check buchen.