Vor jeder Cloud-Migration stehen einige zentrale Entscheidungen an – und die wichtigsten richten sich nach dem geschäftlichen Nutzen. Erfahren Sie, worauf es sonst noch ankommt.
Prüfen Sie die Eignung jedes Workloads, bevor Sie ihn in die Cloud oder auf eine andere Cloud-Plattform verlagern
Der Schritt in die Public Cloud ist kein Selbstzweck, sondern der Auftakt eines fortlaufenden Prozesses. Wenn Sie für einen Teil Ihrer workloads die zentralen Schritte einer Cloud-Migration gemeistert haben, werden Sie sich später vermutlich dazu entscheiden, weitere zu verlagern. Oder Sie wechseln aufgrund geringerer Kosten, besserer Funktionalität oder höherer Sicherheit zu einer anderen Cloud. Doch bevor Sie auch nur einen einzigen workload bewegen, sollten Sie sich einige zentrale Fragen stellen.
1. Steht die Geschäftsführung hinter dem Vorhaben?
Wenn Sie diese Frage nicht mit "Ja" beantworten können, wird Ihre Cloud-Migration scheitern. Zwar haben sich die meisten Unternehmen vorgenommen, bis 2024 80 % ihres IT-Hostings in die Cloud zu verlagern, doch nur wenige Führungskräfte auf C-Level sind davon überzeugt, dass die Cloud-Migrationsinitiativen ihres Unternehmens die versprochenen Ergebnisse liefern. Genau deshalb ist es so wichtig, die Cloud als weit mehr als ein reines IT-Programm zu verstehen. Holen Sie sich die Rückendeckung der Führungsebene für die Cloud als Plattform, die Effizienz, Innovation und Wachstum vorantreibt – und damit den künftigen Erfolg des Unternehmens sichert.
Eine solche Rückendeckung steht und fällt mit der Überzeugungskraft Ihres Migrationsplans. Er muss ein sorgfältiges, systematisches und strategisches Vorgehen aufzeigen: was Sie wohin migrieren – und vor allem, welche geschäftliche Herausforderung damit gelöst wird. Beziehen Sie das aktuelle Wachstum, die Größenordnung und die größten Pain Points Ihres Unternehmens mit ein, um den realen geschäftlichen Nutzen der Migration überzeugend darzulegen.
2. Was möchte das Unternehmen mit dieser Migration erreichen?
Gartner prognostiziert, dass der Anteil neuer digitaler workloads, die auf cloud-native Plattformen ausgerollt werden, von 30 % im Jahr 2021 auf über 95 % im Jahr 2025 steigen wird. Bevor workloads in andere Clouds verschoben oder verbliebene On-Premises-workloads in die Cloud verlagert werden, müssen Unternehmen die Beweggründe für ihre konkrete Migration genau kennen.
Zu den Treibern zählen Kosteneinsparungen, eine geringere Infrastrukturlast, Skalierbarkeit, Verfügbarkeit und eine bessere User Experience. Vielleicht stoßen die On-Premises-Systeme und die Infrastruktur des Unternehmens durch das Wachstum an ihre Grenzen, sodass neue Systeme aufgebaut werden müssen, die mit dem Wachstum mitskalieren. Oder das Ziel besteht darin, Abläufe und Prozesse für Entwickler und Nutzer zu verschlanken, die IT effizienter zu machen, um Kundenanforderungen schneller zu erfüllen, oder die Agilität zu erhöhen, um auf Veränderungen am globalen Markt schneller zu reagieren.
Eine Cloud-Migration eröffnet Innovation in großem Maßstab und hohem Tempo. Sie ermöglicht es Unternehmen, Meilensteine zu erreichen, die für ihren Erfolg entscheidend sind, ohne die Cloud aber Jahre dauern würden. Welches Ziel auch immer verfolgt wird – die Verantwortlichen müssen den Zweck der Migration klar benennen, damit der Fortschritt nachverfolgt und gemessen werden kann.
3. Eignet sich dieser Workload überhaupt für die Cloud?
Viele Frontend-Anwendungen sind in der Public Cloud gut aufgehoben, da sie häufig verändert werden und damit von der Flexibilität der Cloud profitieren. workloads, die sich besonders gut für die Cloud eignen, haben in der Regel kurze Lebenszyklen, weisen häufig Nutzungsspitzen auf und benötigen eine schnelle Bereitstellung der Infrastruktur.
Doch nicht jeder workload-Typ passt in die Cloud. Anwendungen mit Latenzanforderungen im Sub-Millisekundenbereich sollten in der Regel On-Premises bleiben. Wenn Sie etwa ein Finanzhandelssystem betreiben, ist die Cloud für diesen Teil der Plattform nicht die optimale Lösung. Auch die Fertigung ist eine Branche, die hochsensibel auf Zeitverzögerungen reagiert. Deshalb setzen einige der namhaften Automobilhersteller auf Systeme wie AWS Outposts, um Anwendungen vor Ort zu entwickeln und zu betreiben, ohne die im Vergleich zu On-Premises höhere Latenz der Cloud in Kauf nehmen zu müssen.
workloads zumindest kurz- oder mittelfristig On-Premises zu belassen, kann auch dann sinnvoll sein, wenn Sie hohe Capex-Investitionen (Investitionsausgaben) in Ihre eigene Infrastruktur getätigt haben und daraus zunächst maximale Erträge ziehen möchten, bevor Sie auf das Opex-Modell (Betriebsausgaben) der Cloud umstellen.
Entgegen einer weit verbreiteten Annahme zählt Compliance allerdings meist nicht zu den Gründen, einen workload On-Premises zu halten. Im Gegenteil: Dank höherer Transparenz und strengerer Kontrollmöglichkeiten ist die Cloud für solche workloads oft sogar der bessere Standort. Nehmen Sie etwa die EU-Datenschutz-Grundverordnung (DSGVO): Mit Sorgfalt bei der Einhaltung der Vorgaben und einem soliden Cloud-Verständnis lässt sich mit einer Cloud-Bereitstellung in vielen Fällen eine bessere Rendite erzielen als im eigenen Rechenzentrum.
Es lohnt sich, einen Cloud-Partner für eine gründliche workload-Analyse hinzuzuziehen, um das optimale Bereitstellungsmodell zu bestimmen. So erhalten Sie ein klares Bild der technischen Landschaft Ihrer aktuellen workloads, ihrer Herausforderungen und Abhängigkeiten, des Migrationsnutzens im Verhältnis zum Aufwand sowie der optimalen Reihenfolge der Migration.
4. Warum gerade diese Cloud?
Die meisten Unternehmen nutzen mehrere Clouds – aber nicht immer effizient oder strategisch. Das liegt unter anderem daran, dass viele Public-Cloud-Initiativen aus der Schatten-IT entstehen: Software, Geräte und Services werden ohne Wissen oder Kontrolle der IT-Abteilung beschafft.
workloads werden zudem oft pragmatisch statt analysebasiert auf Clouds verteilt. Ohne belastbare Daten dazu, wie die Infrastruktur für jeden workload performt, wird die Wahl der richtigen Cloud zur Glückssache statt zu einer fundierten Entscheidung.
Hinterfragen Sie deshalb, warum Sie Ihre workloads in eine bestimmte Cloud verlagern. Die großen Cloud-Anbieter haben jeweils spezifische Stärken, die zu Ihrem Use Case passen können. So migrieren viele Kunden zu Amazon Web Services (AWS) wegen der Breite und Tiefe des Service-Portfolios, bestehende Microsoft-Kunden wählen häufig Azure, um auf bereits genutzten Services aufzubauen, und Google Cloud sticht mit seinen Datenanalyse-Fähigkeiten hervor.
Theoretisch lässt sich derselbe workload in mehreren Clouds betreiben – doch dann bedienen Sie nur den kleinsten gemeinsamen Nenner. Jeder Cloud-Anbieter verfügt über native Services, die in Konkurrenz-Clouds schlicht nicht verfügbar sind. Es ist daher unrealistisch, zu erwarten, dass workloads nahtlos über beliebige Cloud-Anbieter hinweg laufen. Wer die Public Cloud zur Innovation nutzt, sollte bei der Wahl des Bereitstellungsorts auf die Stärken der jeweiligen Cloud setzen.
5. Welchen Migrationsansatz wählen Sie?
Je nach bisheriger Erfahrung mit Cloud-Migrationen und dem Zugang Ihres Unternehmens zu entsprechender Expertise fällt Ihr Migrationsansatz in eine (oder eine Kombination) von fünf Kategorien: Rehost (Lift-and-Shift), Refactor, Replatform, Rebuild, Replace oder Retire:
- Rehosting ist der einfachste Ansatz: Bestehende Daten und Anwendungen werden ohne Anpassungen auf Cloud-Speicher- und Rechenressourcen umgezogen. Es erfordert relativ wenig Cloud-Know-how, schöpft aber die Möglichkeiten der Cloud nicht aus und eignet sich nicht für alle workloads.
- Refactoring ist komplexer, da Anwendungen vor dem Umzug in die Cloud neu architektiert werden. Dafür liefert der Ansatz eine hohe Rendite, weil er cloud-basierte Funktionen sowie deren Flexibilität und Elastizität gezielt nutzt.
- Replatforming ist der Mittelweg zwischen Rehosting und Refactoring: workloads werden punktuell angepasst, um Cloud-Vorteile wie Automatisierung und bessere Skalierung zu nutzen.
- Rebuilding bedeutet im Grunde, den workload von Grund auf neu zu bauen, um die Funktionalität der Cloud-Umgebung voll auszuschöpfen. Das erfordert hohes Know-how und großes Engagement.
- Replacing – also der Ersatz von workloads durch eine cloud-native Anwendung – heißt, eine bestehende Anwendung außer Betrieb zu nehmen und nur die für den Betrieb erforderlichen Daten zu migrieren. Eine sinnvolle Option, wenn ein vom Cloud-Anbieter bereitgestelltes Tool einfacher zu nutzen ist als der Versuch, dieselben On-Premises-Werkzeuge erneut bereitzustellen.
- Retiring – das Außerbetriebnehmen von workloads, die ihren Zweck erfüllt haben – ist wichtig, um während der Migration keine Zeit und Ressourcen zu verschwenden. Identifizieren Sie jedoch vorher unbedingt alle vorgelagerten Abhängigkeiten.
Der gewählte Migrationsansatz beeinflusst alles – von Ihren Cloud-Kosten bis zu Ihren Architekturentscheidungen.
6. Was wird es kosten?
Die Budgetplanung für eine Cloud-Migration muss sämtliche Phasen abdecken – von der Vorbereitung bis zum Betrieb der workloads in der Cloud nach der Migration. Selbst wenn die Führungsebene sich einig ist, dass eine Migration nötig ist, müssen die anfallenden Kosten bekannt sein, um über Vorgehen und Tempo entscheiden zu können.
Cloud Total Cost of Ownership (TCO) ist eine Methode, um die verschiedenen Kosten für den Betrieb von workloads in der Cloud über deren Lebenszyklus hinweg zu kalkulieren. Jede Cloud-Bereitstellung ist anders, doch ein Vergleich der Kosten für den Betrieb derselben Anwendung On-Premises und in der Cloud ist entscheidend. Die Funktionalität der Anwendung muss dabei vollständig betrachtet werden – insbesondere Anforderungen wie Sicherheit, weitere Anwendungsabhängigkeiten und andere Bereiche, die erheblich zu den Kosten beitragen können. Ein weiterer wichtiger Aspekt der Cloud-TCO sind die Kosten, die entstehen, um Skill-Lücken zu schließen und Teams auf den verschiedenen Cloud-Plattformen rund um die Migration auf Stand zu bringen.
7. Welche Auswirkungen hat die Migration auf Sicherheit und Compliance?
Die Sicherheitskontrollen und -praktiken, die Sie für Ihre On-Premises-Umgebungen aufgebaut haben, funktionieren in der Cloud nicht. Einer der wichtigsten Unterschiede ist das Modell der geteilten Verantwortung (Shared Responsibility): Der Cloud-Anbieter trägt den Großteil der Verantwortung für die Sicherheit der Infrastruktur, während der Kunde für Konfigurationen und Einstellungen unter seiner direkten Kontrolle verantwortlich ist – etwa Daten und Anwendungen. Das lässt sich auch als "Security of the Cloud" gegenüber "Security in the Cloud" beschreiben: Der Anbieter ist für die Sicherheit der Cloud verantwortlich, der Kunde für die Absicherung dessen, was sich in der Cloud befindet.
Ein weiteres Merkmal von Cloud-Sicherheit: Da die Cloud softwarebasiert ist, entstehen spezifische Anforderungen an Kontrollen und Prozesse, die Sie unter Umständen mit neuen Technologien adressieren müssen. Eventuell sind auch Governance-Workflows und -Strukturen so umzubauen, dass sie agiler und kontinuierlicher arbeiten. Beziehen Sie Vertreter aus einem breiten Spektrum an Stakeholdern und technischen Disziplinen ein.
8. Haben Sie Zugriff auf die Ressourcen, die für die Migration nötig sind?
Der Mangel an qualifizierten IT-Fachkräften bremst die Einführung cloudbezogener Technologien. In seiner Emerging Technology Roadmap 2021–2023 hat Gartner aufgezeigt, dass IT-Führungskräfte den Fachkräftemangel als größte Hürde für die Einführung neuer Technologien sehen – darunter Datenbanken, Machine Learning, fortschrittliche Speicher- und Analyselösungen, die alle cloud-fähig sind.
Sind die richtigen Skills im Haus, müssen Sie sicherstellen, dass Ihr Team als geschlossene Einheit arbeitet: Der Prozess fällt auseinander, wenn etwa Ihre Data Engineers isoliert von Ihren Networking-Experten arbeiten und jeder seinen Job für erledigt hält, sobald sein Teilstück fertig ist. Fördern Sie die aktive Beteiligung aller und etablieren Sie das Mantra: Niemand ist fertig, bevor nicht alle fertig sind. Genau deshalb sind das Engagement und die Rückendeckung der Senior-Stakeholder so wichtig – nur so gibt es keine Blockaden, wenn ganzheitliche Teams für die Cloud-Reise aufgestellt werden müssen. Sonst läuft das Migrationsprojekt sich an immer mehr Hindernissen tot.
Fehlen die internen Skills für Ihre Cloud-Migration, können Sie Ihr Team durch Schulungen und Weiterqualifizierung auf die Aufgabe vorbereiten. Bedenken Sie jedoch: Das braucht Zeit und zieht Mitarbeitende von der wertvollen Arbeit ab, die sie aktuell leisten. Die Zusammenarbeit mit einem Cloud-Partner, der Sie mit Expertise und Erfahrung durch die Migration begleitet, kann ein kluger Schritt sein – fundierte, praxiserprobte Beratung erfahrener Architekten beschleunigt Ihre Reise spürbar.
9. Was sollten Sie als Nächstes tun?
Nach all diesen Fragen fragen Sie sich vielleicht, ob Sie über die nötigen Skills und Ressourcen verfügen, um eine Cloud-Migration erfolgreich umzusetzen. Es gibt jedoch eine Alternative: Mit einem Cloud-Partner wie DoiT erhalten Sie Zugang zu Migrationsexperten, die Sie ohne Zusatzkosten durch den gesamten Prozess begleiten.
Als Premier Partner von AWS und Google Cloud bieten wir Multicloud-Expertise, ergänzt durch wertvolle Optimierungs-, Analyse- und Governance-Technologie. Wir unterstützen Sie bei der Anforderungsaufnahme und der Definition geschäftlicher Ziele, beim Aufbau der passenden Cloud-Architektur und bei der Skalierung Ihrer Infrastruktur. Mit dieser Unterstützung lautet Ihre nächste Frage vermutlich nur noch: "Wo fangen wir an?"