Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Bewährte Methoden für große Migrationen Umfangreiche Migrationen können je nach den Faktoren, die die Funktionsweise einer Organisation bestimmen, zu einer Herausforderung werden. In diesem Abschnitt werden einige der wichtigsten Faktoren behandelt, die umfangreiche Migrationen vereinfachen können, wenn sie in der Anfangsphase des Projekts behandelt und während des gesamten Projekts verfolgt werden. Die folgenden bewährten Methoden für umfangreiche Migrationen basieren auf Daten, die von anderen Kunden erfasst wurden. Die Best Practices sind in drei Kategorien unterteilt: + Personen + Technologie + Prozesse # Die Perspektive der Menschen Dieser Abschnitt konzentriert sich auf die folgenden Schlüsselbereiche der Personalperspektive: + Unterstützung durch die Geschäftsleitung — Identifizierung einer einzigen Führungskraft, die in der Lage ist, Entscheidungen zu treffen + Zusammenarbeit und Eigenverantwortung im Team — Zusammenarbeit zwischen verschiedenen Teams + Schulung — Proaktive Schulung der Teams in den verschiedenen Tools ## Unterstützung durch die Geschäftsleitung **Contents** + [Identifizieren Sie eine Führungskraft mit nur einem einzigen Thema](#leader) + [Stimmen Sie das Führungsteam ab](#align-leadership) ### Identifizieren Sie eine Führungskraft mit nur einem einzigen Thema Wenn Sie eine umfangreiche Migration starten, ist es wichtig, einen technischen Leiter zu finden, der sich zu 100 Prozent dem Projekt widmet und verantwortlich ist. Dieser Leiter ist in der Lage, Entscheidungen zu treffen, Silos zu vermeiden und Arbeitsabläufe zu rationalisieren, indem er einheitliche Prioritäten einhält. Ein großer globaler Migrationskunde konnte von einem Server pro Woche zu Beginn des Programms auf mehr als 80 Server pro Woche zu Beginn des zweiten Monats skalieren. Die uneingeschränkte Unterstützung des CIO als führendes Unternehmen mit einem einzigen Thread war entscheidend für die schnelle Skalierung der zu migrierenden Server. Der CIO nahm an wöchentlichen Gesprächen mit dem Migrationsteam zur Umstellung der Migration teil, um sicherzustellen, dass Probleme in Echtzeit eskaliert und gelöst wurden, was die Migrationsgeschwindigkeit beschleunigte. ### Stimmen Sie das Führungsteam ab Es ist wichtig, eine Abstimmung zwischen den verschiedenen Teams in Bezug auf die Erfolgskriterien der Migration herzustellen. Die Planung und Umsetzung der Migration kann zwar von einem kleinen, engagierten Team durchgeführt werden, aber bei der Definition der Strategie und der Durchführung von Randaktivitäten ergeben sich Herausforderungen. Diese potenziellen Hindernisse können Maßnahmen oder Eskalationen aus verschiedenen Bereichen der IT-Organisation erfordern, einschließlich der folgenden: + Geschäft + Anwendungen + Netzwerk + Sicherheit + Infrastruktur + Drittanbieter Direktes Handeln von Seiten der Anwendungseigentümer, der Unternehmensleitung, der Abstimmung und eine klare Eskalation an den Leiter, der nur ein einziges Thema hat, werden immer wichtiger. ## Zusammenarbeit und Eigenverantwortung im Team **Contents** + [Stellen Sie ein funktionsübergreifendes Cloud-Enablement-Team zusammen](#cross-function) + [Definieren Sie im Voraus die Anforderungen für Teams und Einzelpersonen außerhalb des Kernmigrationsteams](#define-reqs) + [Stellen Sie sicher, dass bei der Migration von Workloads keine Lizenzprobleme vorliegen](#licensing) ### Stellen Sie ein funktionsübergreifendes Cloud-Enablement-Team zusammen **Contents** Ein wichtiger erster Schritt in einem großen Migrationsprojekt besteht darin, das Unternehmen in die Lage zu versetzen, in der Cloud zu arbeiten. Um dies zu erreichen, empfehlen wir den Aufbau einer [Cloud Enablement Engine](https://d1.awsstatic.com/whitepapers/cloud-enablement-engine-practical-guide.pdf) (CEE). Das CEE ist ein kompetentes und rechenschaftspflichtiges Team, das sich auf die operative Bereitschaft der Organisation für Migrationen zu konzentriert. AWS Das CEE sollte ein funktionsübergreifendes Team sein, das Vertreter aus den Bereichen Infrastruktur, Anwendungen, Betrieb und Sicherheit umfasst. Das Team ist mit den folgenden Aufgaben betraut: + Entwicklung von Richtlinien + Definition und Implementierung von Tools, Prozessen und Architekturen, die das Cloud-Betriebsmodell eines Unternehmens etablieren + Weitere Förderung der Abstimmung zwischen den Interessengruppen in allen Bereichen, die sie vertreten Ein Kunde aus dem Gesundheitswesen hat nicht mit einem CEE angefangen. Bei ersten Pilotmigrationen wurde die Lücke jedoch identifiziert. Im Vorfeld des endgültigen Umstellungstermins und unter Einhaltung strenger Fristen richtete das Team einen *Migrationskampf* ein. In dieser Phase der Migration konnten Interessengruppen aus den Bereichen Infrastruktur, Sicherheit, Anwendungen und Unternehmen bei der Lösung von Problemen behilflich sein. ### Definieren Sie im Voraus die Anforderungen für Teams und Einzelpersonen außerhalb des Kernmigrationsteams Identifizieren Sie Teams und Einzelpersonen, die nicht zum Kernprogramm gehören, und definieren Sie deren Beteiligung in den Phasen der Migrationsplanung. Um die Dynamik der Migration in den späteren Phasen zu fördern, sollten Sie der Beteiligung der Anwendungsteams besondere Aufmerksamkeit schenken. Ihr Wissen über die Anwendung, ihre Fähigkeit, Probleme zu diagnostizieren, und sie müssen die Umstellung genehmigen. Die Migration wird zwar von einem Kernteam geleitet, die Anwendungsteams werden jedoch wahrscheinlich an der Validierung des Migrationsplans und an den Tests während der Umstellung beteiligt sein. Kunden betrachten die Cloud-Migration häufig als Infrastrukturprojekt und nicht als Anwendungsmigration. Dies kann zu Problemen bei der Migration führen. Wir empfehlen, bei der Auswahl einer Migrationsstrategie die erforderliche Beteiligung des Anwendungsteams zu berücksichtigen. Beispielsweise erfordert eine Rehost-Strategie weniger Beteiligung des Anwendungsteams als eine Replattform- oder Refactoring-Strategie, bei der ein Großteil der Anwendungslandschaft geändert wird. Wenn die Verfügbarkeit des Anwendungsbesitzers begrenzt ist, sollten Sie erwägen, Rehost oder Replatform anstelle von Refactoring-, Relocate- oder Rebuy-Strategien zu verwenden. ### Stellen Sie sicher, dass bei der Migration von Workloads keine Lizenzprobleme vorliegen Die Lizenzierung kann sich ändern, wenn Sie Standardprodukte für Unternehmen in die Cloud migrieren. Ihre Lizenzverträge konzentrieren sich möglicherweise auf Ihren lokalen Bestand. Eine Lizenz kann beispielsweise nach CPU geordnet sein oder mit einer bestimmten MAC-Adresse verknüpft sein. Alternativ beinhalten Lizenzvereinbarungen möglicherweise nicht das Recht, in einer öffentlichen Cloud-Umgebung zu hosten. Die Neuverhandlung von Lizenzen mit Anbietern kann jedoch lange Vorlaufzeiten mit sich bringen und stellt ein hartes Hindernis für die Migration dar. Wir empfehlen, mit Ihren Beschaffungs- oder Lieferantenmanagementteams zusammenzuarbeiten, sobald der Umfang der Migration festgelegt ist. Die Lizenzierung kann sich auch auf Ihre Zielarchitektur und Ihre Migrationsmuster auswirken. ## Training **Contents** + [Schulen Sie Teams in neuen Tools und Prozessen](#tools-training) ### Schulen Sie Teams in neuen Tools und Prozessen Nachdem die Migrationsstrategie definiert wurde, sollten Sie Zeit investieren, um zu verstehen, welche Schulungen für die Migration und für Ihr angestrebtes Betriebsmodell erforderlich sein könnten. Während der Migration werden Sie wahrscheinlich Tools verwenden, z. B. solche AWS Database Migration Service, die für Ihr Unternehmen neu sind. Durch proaktives Training der Teams werden die Verzögerungen während der Migrationsphasen reduziert. Wir empfehlen, nach Methoden des aktiven Wissenstransfers zu suchen, die die Möglichkeit bieten, praxisnah mit den Tools zu experimentieren. Beispielsweise bot AWS Professional Services mehrere Cloud Migration Factory-Schulungen für drei Systemintegratoren (SI) an, die für eine AWS umfangreiche Migration verantwortlich waren. Dadurch wurde sichergestellt, dass das Team zu Beginn der Migrationsphase über grundlegende Kenntnisse verfügte. Es half auch dabei, Fachexperten (SMEs) zu finden, die als erste Anlaufstelle innerhalb der einzelnen AWS SI-Partnerteams fungieren könnten. # Technologische Perspektive Technologie bietet eine hervorragende Grundlage für die Beschleunigung großer Migrationen. Die Cloud Migration Factory-Lösung konzentriert sich beispielsweise darauf, wie Migrationen end-to-end automatisiert werden können. In diesem Abschnitt werden einige der bewährten Methoden für den Einsatz von Technologie untersucht, um den erforderlichen Umfang und die erforderliche Geschwindigkeit zu erreichen, wobei der Umfang, die Strategie und die Zeitpläne berücksichtigt werden. Das übergeordnete Prinzip besteht darin, Bereiche der Automatisierung zu untersuchen, wo immer dies möglich ist. Wenn Sie Tausende von Servern im Einsatz haben, kann die manuelle Ausführung von Aufgaben kostspielig und zeitaufwändig sein. Für die Durchführung einer Migration werden in der Regel mehrere Tools verwendet, z. B. die folgenden: + Erkennung + Implementierung der Migration + Datenbank für das Konfigurationsmanagement (CMDB) + Inventar-Tabelle + Projektmanagement Diese Tools werden in verschiedenen Phasen der Migration eingesetzt, von der Bewertung über die Mobilisierung bis hin zur Implementierung. Die Auswahl dieser Tools richtet sich nach den Geschäftszielen und Zeitplänen. Nach der Planung der Migrationsphasen besteht der nächste Schritt darin, sicherzustellen, dass das Migrationsteam über die erforderlichen Fähigkeiten verfügt, um die Tools zu verwenden, die es benötigt. Wenn einem Team die Fähigkeiten oder die Erfahrung fehlen, planen Sie gezielte Schulungen, um die Fähigkeiten zu erweitern. Wenn möglich, organisieren Sie Veranstaltungen, bei denen Teams in einer sicheren Umgebung Erfahrungen mit den Migrationstools sammeln können. Gibt es beispielsweise Sandkasten- oder Laborserver, die Teams migrieren können, um Erfahrungen mit den Tools zu sammeln? Ist es alternativ akzeptabel, dass anfängliche Entwicklungs-Workloads zu Lernzwecken genutzt werden? ## Automatisierung, Nachverfolgung und Integration von Tools **Contents** + [Automatisieren Sie die Migrationserkennung, um den Zeitaufwand zu reduzieren](#discovery) + [Automatisieren Sie sich wiederholende Aufgaben](#repeating) + [Automatisieren Sie die Nachverfolgung und Berichterstattung, um die Entscheidungsfindung zu beschleunigen](#decision) + [Entdecken Sie Tools, die Ihre Migration erleichtern können](#tooling) ### Automatisieren Sie die Migrationserkennung, um den Zeitaufwand zu reduzieren Die meisten großen Migrationsprogramme beginnen damit, den Umfang der Migration zu verstehen (was migriert werden muss) und eine Strategie zu entwickeln (wie sie migriert werden soll). Die Entdeckung ist dabei ein wichtiger Aspekt. Die erforderlichen Metadatenpunkte werden erfasst, um einen Entscheidungsbaum für die Migrationsstrategie zu bilden. Um Workloads schnell migrieren zu können, müssen Sie die erforderlichen Migrationsmetadaten identifizieren und in Ihre Implementierungsprozesse importieren, z. B. in eine Migration Factory. Ein vollständig automatisierter Mechanismus zum Extrahieren, Transformieren und Laden (ETL) der Migrationsmetadaten reduziert den Zeit- und Arbeitsaufwand für den Erkennungsprozess erheblich. Ein Kunde entwickelte einen vollautomatischen Dateneingabeprozess für seine Migrationsfabrik. Der Migrationswellenplan mit allen Migrationsmetadaten wurde in einer Tabelle auf Microsoft SharePoint gehostet und verwaltet. Wenn Änderungen an der Quelle vorgenommen wurden, wurde eine AWS Lambda Funktion gestartet, um die Daten ohne manuelles Eingreifen in die Migration Factory zu laden. Dieser automatisierte Dateneingabeprozess half dem Kunden, den manuellen Aufwand zu reduzieren, menschliche Fehler zu minimieren und die Geschwindigkeit zu erhöhen. Sie waren in der Lage, mehr als 1.000 Server zu migrieren AWS. ### Automatisieren Sie sich wiederholende Aufgaben In der Phase der Migrationsimplementierung müssen viele kleine Prozesse häufig wiederholt werden. Wenn Sie beispielsweise AWS Application Migration Service (MGN) verwenden, müssen Sie den Agenten auf jedem Server installieren, der Teil der Migration ist. Der Aufbau einer Migrationsfabrik, die auf Ihre spezifischen geschäftlichen und technischen Anforderungen zugeschnitten ist, ist der effektivste Weg, um die Effizienz und Geschwindigkeit zu erreichen, die für eine erfolgreiche umfangreiche Migration erforderlich sind. Eine Migration Factory bietet ein Integrations- und Orchestrierungs-Framework, das einen standardisierten Datensatz verwendet, um die Migration zu beschleunigen. Nachdem alle Aufgaben identifiziert wurden, sollten Sie Zeit darauf verwenden, alle manuellen Aufgaben zu automatisieren, die zusammen mit den vorgeschriebenen Runbooks automatisiert werden können. Die [Cloud Migration Factory-Lösung](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-factory-cloudendure/welcome.html) ist ein Beispiel dafür. Cloud Migration Factory wurde entwickelt, um die Grundlagen für die Migrationsautomatisierung bereitzustellen, auf der Sie Aspekte automatisieren können, die für Ihr Unternehmen spezifisch sind. Möglicherweise möchten Sie beispielsweise ein Kennzeichen in Ihrer CMDB aktualisieren, um darauf hinzuweisen, dass die lokalen Server jetzt außer Betrieb genommen werden können. In diesem Szenario könnten Sie eine Automatisierung erstellen, die diese Aufgabe am Ende der Migrationswelle ausführt. Cloud Migration Factory verfügt über einen zentralen Metadatenspeicher mit allen Wellen-, Anwendungs- und Server-Metadaten. Das Automatisierungsskript kann eine Verbindung zu Cloud Migration Factory herstellen, um eine Liste der Server in dieser Welle abzurufen und die entsprechenden Aktionen auszuführen. Cloud Migration Factory unterstützt [AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html). ### Automatisieren Sie die Nachverfolgung und Berichterstattung, um die Entscheidungsfindung zu beschleunigen Wir empfehlen, ein automatisiertes Dashboard für Migrationsberichte einzurichten, um Live-Daten, einschließlich wichtiger Leistungsindikatoren (KPIs) für das Programm, nachzuverfolgen und zu melden. An Migrationsprojekten sind Interessengruppen aus dem gesamten Unternehmen beteiligt, darunter die folgenden: + Anwendungsteams + Tester + Teams für die Außerbetriebnahme + Architekten + Infrastrukturteams + Führung Um ihre Aufgaben wahrnehmen zu können, benötigen diese Stakeholder Live-Daten. Netzwerkteams müssen beispielsweise die bevorstehenden Migrationswellen kennen, um die Auswirkungen auf die gemeinsame Verbindung zwischen lokalen Ressourcen und AWS zu verstehen. Führungsteams möchten wissen, wie viel von der Migration bereits abgeschlossen ist. Ein zuverlässiger, automatisierter Live-Feed mit Daten verhindert Missverständnisse und bietet eine Grundlage, auf der Entscheidungen getroffen werden können. Ein großer Kunde aus dem Gesundheitswesen arbeitete auf die Schließung seines Rechenzentrums hin, dessen Frist bald abläuft. Angesichts des Umfangs und der Komplexität wurde zunächst viel Zeit darauf verwendet, den Migrationsstatus zu verfolgen und zwischen den Beteiligten zu kommunizieren. Später nutzte das Migrationsteam [Amazon Quick Sight](https://docs.aws.amazon.com/quicksuite/latest/userguide/quick-bi.html), um automatisierte Dashboards zu erstellen, die die Daten visualisierten, was die Nachverfolgung und Kommunikation erheblich vereinfachte und gleichzeitig die Migrationsgeschwindigkeit erhöhte. ### Entdecken Sie Tools, die Ihre Migration erleichtern können Die Auswahl der richtigen Tools für Ihre Migration ist nicht einfach, vor allem, wenn niemand in Ihrem Unternehmen zuvor eine große Migration durchgeführt hat. Wir empfehlen, Zeit für die Auswahl geeigneter Tools zur Unterstützung der Migration aufzuwenden. Diese Untersuchung kann mit Lizenzkosten verbunden sein, kann aber einen Kostenvorteil bieten, wenn Sie die umfassendere Initiative in Betracht ziehen. Alternativ könnten Sie feststellen, dass in Ihrem Unternehmen integrierte Tools zu einem ähnlichen Ergebnis führen können. Möglicherweise haben Sie in Ihrem Unternehmen bereits Tools zur Überwachung der Anwendungsleistung eingesetzt, die Ihnen umfangreiche Informationen liefern können. Ein Technologiekunde zögerte zunächst, während seiner Migration automatisierte Discovery-Tools einzusetzen, da er nicht mit ihnen vertraut war. In der Folge musste ein AWS SI-Partner pro Anwendung 510 Stunden an Besprechungen abhalten, um den Bestand manuell zu ermitteln, einschließlich Servernamen, Betriebssystemversionen und Abhängigkeiten. Schätzungen zufolge hätte der Ermittlungsaufwand durch den Einsatz von Discovery-Tools um mehr als 1.000 Stunden reduziert werden können. ## Voraussetzungen und Validierung nach der Migration **Contents** + [Errichten Sie die landing zone während der Phase vor der Migration](#landing-zone) + [Skizzieren Sie die erforderlichen Aktivitäten](#outline) + [Führen Sie Prüfungen nach der Migration durch, um weitere Verbesserungen zu erzielen](#post-checks) ### Errichten Sie die landing zone während der Phase vor der Migration Wir empfehlen, die AWS Zielumgebung oder landing zone im Voraus zu erstellen, anstatt die virtuellen privaten Ziel-Clouds (VPCs) und Subnetze während der Migrationswelle zu erstellen. Der Bau einer gut gestalteten landing zone ist eine Grundvoraussetzung für die Migration. Die landing zone sollte Überwachungs-, Verwaltungs-, Betriebs- und Sicherheitskontrollen umfassen. Durch den Aufbau und die Validierung der landing zone vor der Migration wird die Unsicherheit minimiert, die mit der Ausführung Ihrer Workloads in einer neuen Umgebung einhergeht. Wenn die landing zone ist, können sich die Beteiligten auf die Migration der Workloads konzentrieren, ohne sich Gedanken über Aspekte machen zu müssen, die auf Konto- oder VPC-Ebene verwaltet werden. ### Skizzieren Sie die erforderlichen Aktivitäten Neben der landing zone ist es wichtig, vor der Migration auch andere technische Voraussetzungen aufeinander abzustimmen, insbesondere Prozesse mit langen Vorlaufzeiten. Nehmen Sie beispielsweise die erforderlichen Firewall-Änderungen vor, damit die Daten von vor Ort auf repliziert werden können. AWS Die frühzeitige Kommunikation der technischen Voraussetzungen hilft bei der Vorbereitung und Zuweisung der benötigten Ressourcen. Es kommt häufig vor, dass Migrationen ins Stocken geraten, weil die Voraussetzungen nicht erfüllt wurden. Dies wirkt sich nicht nur auf die laufende Migrationswelle aus, sondern kann auch die Termine aller future Migrationen verschieben, während das Problem behoben wird. Ein Finanzdienstleistungsunternehmen beabsichtigte, eine Massenmigration nach mehreren Rechenzentren durchzuführen AWS, mit dem Ziel, mehrere Rechenzentren zu räumen. Ihre Bandbreite war jedoch zwischen lokalen Standorten verfügbar und AWS reichte nicht für die von ihnen beabsichtigte Geschwindigkeit aus. Leider erforderte die Erhöhung der Bandbreite eine neue Verbindung und hatte eine Vorlaufzeit von drei Monaten. Dies bedeutete, dass die Migrationsgeschwindigkeit in den ersten drei Monaten eingeschränkt war. ### Führen Sie Prüfungen nach der Migration durch, um weitere Verbesserungen zu erzielen Denken Sie außerdem daran, nach der Migration Validierungen wie Betriebsintegration, Kostenoptimierung sowie Kontroll- und Compliance-Prüfungen durchzuführen. Die Validierung nach der Migration umfasst die Bewertung zuvor migrierter Workloads, um technische Erkenntnisse aufzudecken, die auf future Wellen angewendet werden sollten. Darüber hinaus ist dies eine hervorragende Gelegenheit, Maßnahmen zur Kostenkontrolle umzusetzen. Während der Migration könnten Sie sich beispielsweise dafür entscheiden, die Größe der AWS Instanzen an Ihre lokale Umgebung anzupassen, um den Bedarf an Leistungstests zu reduzieren. Jetzt, da Tests nicht mehr auf dem kritischen Pfad der Schließung von Rechenzentren stehen, können Sie Amazon verwenden, CloudWatch um die Instance-Auslastung zu bewerten und festzustellen, ob eine kleinere Instance geeignet wäre. Um die Bedeutung dieser Phase zu verdeutlichen, führte ein großer Technologiekunde eine umfangreiche Migration durch, beinhaltete aber zunächst keine Validierungen nach der Migration. Nach der Migration von mehr als 100 Servern stellte das Unternehmen fest, dass der AWS Systems Manager Agent (SSM-Agent) nicht richtig konfiguriert war. Alle zuvor migrierten Server mussten repariert werden, und die Migration wurde gestoppt. Der Kunde stellte außerdem fest, dass die Anzahl der Instanzen das Fünffache der ursprünglichen Schätzungen betrug, weshalb er am Ende jeder Migrationswelle einen Kostenkontrollpunkt einführte. # Prozessperspektive Prozesse sorgen für Konsistenz, entwickeln sich aber auch weiter und sind anfällig für Änderungen, da jedes Projekt einzigartig ist. Wenn Sie den Prozess wiederholt ausführen, werden Sie Lücken und Verbesserungsmöglichkeiten erkennen, die sich zu enormen Vorteilen summieren können, wenn Sie scheitern, lernen, sich anpassen und iterieren. Diese Veränderungen können zu neuen Ideen oder Innovationen führen, von denen das Projekt und das Unternehmen in future profitieren können. Dies ist ein Wachstumskatalysator, der Qualität und Teamsicherheit fördert. Migrationsprozesse können komplex sein, da sie Technologien und Grenzen überschreiten, die zuvor möglicherweise nicht miteinander verknüpft waren. Diese Perspektive bietet Prozesse und Anleitungen zu spezifischen Anforderungen für große Migrationen. ## Vorbereitung Ihrer großen Migration In den folgenden Abschnitten werden die wichtigsten Prinzipien beschrieben, die erforderlich sind, um sicherzustellen, dass Sie Ihre Migration mit einer klaren Richtung und der Zustimmung der Beteiligten beginnen, was für den Erfolg entscheidend ist. **Contents** + [Definieren Sie die Geschäftstreiber und kommunizieren Sie Zeitplan, Umfang und Strategie](#bus-drivers) + [Definieren Sie einen klaren Eskalationspfad, um die Hindernisse zu beseitigen](#escalation) + [Minimiere unnötige Änderungen](#change) + [Dokumentieren Sie und end-to-end verarbeiten Sie frühzeitig](#end-to-end) + [Dokumentieren Sie standardmäßige Migrationsmuster und Artefakte](#artifacts) + [Richten Sie eine zentrale Informationsquelle für Migrationsmetadaten und den Status ein](#metadata) ### Definieren Sie die Geschäftstreiber und kommunizieren Sie Zeitplan, Umfang und Strategie Wenn Sie sich einer großen Migration zu nähern AWS, werden Sie schnell feststellen, dass es zahlreiche Möglichkeiten gibt, Ihre Server zu migrieren. Sie können z. B. Folgendes tun: + Rehosten Sie Workloads mithilfe von. [AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html) + Containerisieren Sie Ihre Anwendung und hosten Sie sie auf der verwalteten [Container-Plattform Amazon Elastic Container Service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) (Amazon ECS) oder [Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) (Amazon EKS). + Gestalten Sie Ihren Workload in eine vollständig serverlose Anwendung um. Um den richtigen Migrationspfad zu ermitteln, ist es wichtig, von Ihren Geschäftstreibern ausgehend rückwärts zu arbeiten. Wenn Ihr oberstes Ziel darin besteht, die Agilität Ihres Unternehmens zu erhöhen, könnten Sie die beiden zweiten Muster bevorzugen, die mehr Transformationsebenen beinhalten. Wenn es Ihr Ziel ist, ein Rechenzentrum bis Ende des Jahres zu verlassen, könnten Sie sich aufgrund der Geschwindigkeit, die das Rehosting bietet, für ein Rehosting von Workloads entscheiden. An einer großen Migration sind in der Regel eine Vielzahl von Beteiligten beteiligt, darunter die folgenden: + Besitzer von Anwendungen + Netzwerk-Teams + Datenbankadministratoren + Exekutive Sponsoren Es ist wichtig, die wirtschaftlichen Triebkräfte der Migration zu identifizieren und diese Liste in ein Dokument aufzunehmen, z. B. in eine Projektcharta, auf die die Mitglieder des Migrationsprogramms zugreifen können. Erstellen Sie außerdem wichtige Leistungsindikatoren (KPIs), die eng mit Ihren Geschäftsergebnissen übereinstimmen. Ein Kunde wollte beispielsweise innerhalb von 12 Monaten 2.000 Server migrieren, um sein angestrebtes Geschäftsergebnis, die Räumung seines Rechenzentrums, zu erreichen. Ihre Sicherheitsteams waren jedoch nicht auf dieses Ziel ausgerichtet. Das Ergebnis waren monatelange technische Diskussionen darüber, ob das Datum der Schließung des Rechenzentrums versäumt, aber die Anwendungen weiter modernisiert werden sollten, oder ob zunächst ein Rehosting durchgeführt werden sollte, um die rechtzeitige Schließung des Rechenzentrums zu ermöglichen, und dann die Anwendungen weiter zu modernisieren. AWS ### Definieren Sie einen klaren Eskalationspfad, um die Hindernisse zu beseitigen An großen Cloud-Migrationsprogrammen sind in der Regel eine Vielzahl von Interessengruppen beteiligt. Schließlich ändern Sie möglicherweise Anwendungen, die seit mehreren Jahrzehnten vor Ort gehostet werden. Es ist üblich, dass jeder der Beteiligten widersprüchliche Prioritäten hat. Obwohl alle Prioritäten einen Mehrwert bieten können, wird das Programm wahrscheinlich nur über ein begrenztes Budget und ein definiertes Zielergebnis verfügen. Es kann schwierig sein, die verschiedenen Interessengruppen zu verwalten und sich auf die angestrebten Geschäftsergebnisse zu konzentrieren. Diese Herausforderung wird noch verschärft, wenn Sie sie mit den Hunderten oder Tausenden von Anwendungen multiplizieren, die Gegenstand der Migration sind. Darüber hinaus unterstehen die Beteiligten wahrscheinlich unterschiedlichen Führungsteams, die andere Prioritäten haben. Vor diesem Hintergrund ist es neben der klaren Dokumentation der angestrebten Geschäftsergebnisse wichtig, eine klare Eskalationsmatrix zu definieren, um Hindernisse aus dem Weg zu räumen. Dies kann viel Zeit sparen und dazu beitragen, die verschiedenen Teams auf ein gemeinsames Ziel auszurichten. Ein Beispiel dafür ist ein Finanzdienstleistungsunternehmen, dessen Ziel es war, sein primäres Rechenzentrum innerhalb von 12 Monaten zu räumen. Es gab kein klares Mandat oder keinen Eskalationspfad, was dazu führte, dass die Beteiligten unabhängig von Zeit- und Budgetbeschränkungen ihre gewünschten Migrationspfade ausarbeiteten. Nach einer Eskalation an den CIO wurde ein klares Mandat festgelegt und es wurde ein Mechanismus eingerichtet, mit dem die erforderlichen Entscheidungen angefordert werden können. ### Minimiere unnötige Änderungen Veränderung ist gut, aber mehr Änderungen bedeuten mehr Risiken. Wenn das Geschäftsszenario für die umfangreiche Migration bestätigt wird, steht diese Initiative höchstwahrscheinlich auf einem angestrebten Geschäftsergebnis, wie z. B. die Räumung eines Rechenzentrums bis zu einem bestimmten Datum. Es ist zwar üblich, dass Technologen alles neu schreiben wollen, um die Vorteile der AWS Services voll auszuschöpfen, aber das ist möglicherweise nicht Ihr Geschäftsziel. Ein Kunde konzentrierte sich auf eine zweijährige Migration der gesamten Web-Scale-Infrastruktur des Unternehmens auf. AWS Sie haben eine Zwei-Wochen-Regel eingeführt, um zu verhindern, dass Anwendungsteams monatelang ihre Anwendungen neu schreiben müssen. Durch die Anwendung der Zwei-Wochen-Regel war der Kunde in der Lage, eine langfristige Migration mit einem gleichbleibenden Rhythmus aufrechtzuerhalten, bei der Hunderte von Anwendungen über einen Zeitraum von mehreren Jahren verschoben werden mussten. Weitere Informationen finden Sie im Blogbeitrag [Die Zwei-Wochen-Regel: Refactoring Your Applications](https://aws.amazon.com/blogs/enterprise-strategy/the-two-week-rule-refactor-your-applications-for-the-cloud-in-10-days/) for the Cloud in 10 Days. Wir empfehlen, alle Änderungen, die nicht dem Geschäftsergebnis entsprechen, auf ein Minimum zu beschränken. Entwickeln Sie stattdessen Mechanismen, um diese zusätzlichen Änderungen in future Projekten zu verwalten. ### Dokumentieren Sie und end-to-end verarbeiten Sie frühzeitig Dokumentieren Sie den vollständigen Migrationsprozess und die Zuweisung der Eigentumsrechte in der Anfangsphase eines großen Migrationsprogramms. Diese Dokumentation ist wichtig, um alle Beteiligten über den Ablauf der Migration sowie über ihre Rollen und Verantwortlichkeiten aufzuklären. Die Dokumentation hilft Ihnen auch dabei, zu verstehen, wo Probleme auftreten könnten, und bietet Ihnen Updates und Wiederholungen des Prozesses, während Sie die Migrationen durchführen. Stellen Sie bei der Entwicklung des Migrationsprojekts sicher, dass alle bestehenden Prozesse verstanden werden und dass Integrationspunkte und Abhängigkeiten klar dokumentiert sind. Geben Sie Stellen an, an denen die Zusammenarbeit mit externen Prozessverantwortlichen erforderlich sein wird, z. B. bei Änderungsanfragen, Serviceanfragen, Lieferantensupport sowie Netzwerk- und Firewall-Support. Sobald der Prozess verstanden ist, empfehlen wir, die Verantwortung in einer Matrix für verantwortungsvolle, rechenschaftspflichtige, konsultierte und informierte Informationen (RACI) zu dokumentieren, um die verschiedenen Aktivitäten verfolgen zu können. Um den Prozess abzuschließen, erstellen Sie einen Countdown-Plan, in dem Sie die Zeitpläne für jeden Schritt der Migration festlegen. Der Countdown-Plan funktioniert in der Regel rückwärts ab Datum und Uhrzeit der Umstellung auf die Workload-Migration. Dieser Dokumentationsansatz hat sich bei einem multinationalen Unternehmen für Haushaltsgeräte bewährt, das in weniger als einem Jahr AWS erfolgreich auf dieses System umgestellt und vier Rechenzentren verlassen hat. Es waren sechs verschiedene Organisationsteams und mehrere Dritte beteiligt, was zu einem Verwaltungsaufwand führte, der zu back-and-forth Entscheidungen und Verzögerungen bei der Implementierung führte. Das AWS Professional Services-Team identifizierte zusammen mit dem Kunden und seinen Drittanbietern die wichtigsten Prozesse für die Migrationsaktivitäten und dokumentierte sie mit den jeweiligen Eigentümern. Die daraus resultierende RACI-Matrix wurde von allen beteiligten Teams gemeinsam genutzt und vereinbart. Mithilfe der RACI-Matrix und einer Eskalationsmatrix konnte der Kunde die Hindernisse und Probleme, die zu Verzögerungen führten, ausräumen. Anschließend waren sie in der Lage, die Rechenzentren vorzeitig zu verlassen. In einem anderen Beispiel für die Verwendung von RACI und Eskalationsmatrizen konnte eine Versicherungsgesellschaft das Rechenzentrum in weniger als 4 Monaten verlassen. Der Kunde verstand und implementierte ein Modell der gemeinsamen Verantwortung. Außerdem wurde eine detaillierte RACI-Matrix verwendet, um den Fortschritt der einzelnen Prozesse und Aktivitäten während der Migration nachzuverfolgen. Dadurch war der Kunde in der Lage, in den ersten 12 Wochen der Implementierung über 350 Server zu migrieren. ### Dokumentieren Sie standardmäßige Migrationsmuster und Artefakte Stellen Sie sich das so vor, als würden Sie Ausstechformen für die Implementierung erstellen. Wiederverwendbare Referenzen, Dokumentationen, Runbooks und Muster sind der Schlüssel zur Skalierung. Diese dokumentieren die Erfahrungen, Erkenntnisse, Fallstricke, Probleme und Lösungen, die future Migrationsprojekte wiederverwenden und vermeiden können, wodurch die Migration erheblich beschleunigt wird. Die Muster und Artefakte sind auch eine Investition, die dazu beitragen wird, den Prozess zu verbessern und future Projekte zu leiten. Ein Kunde führte beispielsweise eine einjährige Migration durch, bei der Anwendungen von drei verschiedenen AWS SI-Partnern migriert wurden. In der Anfangsphase verwendete jeder AWS Partner seine eigenen Standards, Runbooks und Artefakte. Dies belastete die Kundenteams erheblich, da ihnen dieselben Informationen auf unterschiedliche Weise präsentiert werden konnten. Nach diesen anfänglichen Schwierigkeiten legte der Kunde die zentrale Verantwortung für alle Dokumente und Artefakte fest, die bei der Migration verwendet werden sollten, und legte einen Prozess für die Einreichung empfohlener Änderungen fest. Zu diesen Ressourcen gehören: + Ein Standardmigrationsprozess und Checklisten + Stil- und Formatstandards für Netzwerkdiagramme + Architektur- und Sicherheitsstandards für Anwendungen, die auf der Wichtigkeit des Unternehmens basieren Darüber hinaus wurden Änderungen an diesen Dokumenten und Standards in wöchentlichem Rhythmus an alle Teams versandt, und jeder Partner musste den Eingang und die Einhaltung aller Änderungen bestätigen. Dadurch wurden die Kommunikation und die Konsistenz des Migrationsprojekts erheblich verbessert. Als in einer anderen Geschäftseinheit eine separate, umfangreiche Migrationsmaßnahme gestartet wurde, konnte das Team den bestehenden Prozess und die vorhandenen Dokumente übernehmen, was den Erfolg erheblich beschleunigte. ### Richten Sie eine zentrale Informationsquelle für Migrationsmetadaten und den Status ein Wenn es um die Planung einer großen Migration geht, ist es wichtig, eine Informationsquelle einzurichten, um die verschiedenen Teams aufeinander abzustimmen und datengestützte Entscheidungen zu ermöglichen. Zu Beginn dieser Reise finden Sie möglicherweise zahlreiche Datenquellen, die Sie verwenden können, z. B. die Configuration Management Database (CMDB), Tools zur Überwachung der Anwendungsleistung, Inventarlisten usw. Alternativ stellen Sie möglicherweise fest, dass es nur wenige Datenquellen gibt und Sie Mechanismen entwickeln müssen, um die benötigten Daten zu erfassen. Beispielsweise müssen Sie möglicherweise Discovery-Tools verwenden, um technische Informationen zu ermitteln und IT-Führungskräfte zu befragen, um Geschäftsinformationen zu erhalten. Es ist wichtig, die verschiedenen Datenquellen in einem einzigen Datensatz zusammenzufassen, den Sie für die Migration verwenden können. Anschließend können Sie die Single Source of Truth verwenden, um die Migration während der Implementierung zu verfolgen. Sie können beispielsweise nachverfolgen, welche Server migriert wurden. Ein Kunde aus dem Finanzdienstleistungssektor, der alle Workloads migrieren wollte, AWS konzentrierte sich auf die Planung der Migration anhand des bereitgestellten Datensatzes. Dieser Datensatz wies wichtige Lücken auf, z. B. Informationen zur Geschäftskritikalität und Abhängigkeit, weshalb das Programm eine Untersuchung einleitete. In einem anderen Beispiel ging ein Unternehmen derselben Branche auf der Grundlage von out-of-date Kenntnissen seines Serverinfrastrukturbestands zur Implementierung der Migrationswelle über. Das Unternehmen stellte schnell fest, dass die Migrationszahlen zurückgingen, weil die Daten falsch waren. In diesem Fall wurden die Besitzer der Anwendungen nicht verstanden, was bedeutete, dass sie die Tester nicht rechtzeitig finden konnten. Darüber hinaus waren die Daten nicht auf die Außerbetriebnahme abgestimmt, die ihre Anwendungsteams abgeschlossen hatten, sodass die Server weiterliefen, ohne für geschäftliche Zwecke genutzt zu werden. ## Durchführung Ihrer großen Migration Nachdem Sie Ihre Geschäftsergebnisse festgelegt und die Strategie den Beteiligten mitgeteilt haben, können Sie mit der Planung beginnen, wie Sie den Umfang der großen Migration in nachhaltige Migrationsereignisse oder -wellen aufteilen. Die folgenden Beispiele bieten wichtige Hinweise für die Erstellung des Wellenplans. **Contents** + [Planen Sie Migrationswellen im Voraus, um einen stetigen Fluss zu gewährleisten](#plan-waves) + [Sorgen Sie dafür, dass Wave-Implementierung und Wave-Planung als separate Prozesse und Teams voneinander getrennt sind](#separate) + [Fangen Sie klein an, um großartige Ergebnisse zu erzielen](#start-small) + [Minimiere die Anzahl der Umstellungsfenster](#cutover-numbers) + [Scheitern Sie schnell, wenden Sie Erfahrung an und wiederholen Sie](#iterate) + [Vergessen Sie nicht die Retrospektive](#retrospective) ### Planen Sie Migrationswellen im Voraus, um einen stetigen Fluss zu gewährleisten Die Planung Ihrer Migration ist eine der wichtigsten Phasen des Programms. Es entspricht dem Sprichwort „Wenn Sie nicht planen, planen Sie zu scheitern“. Durch die frühzeitige Planung von Migrationswellen kann das Projekt schnell ablaufen, da das Team proaktiver auf die Migrationssituation eingeht. Es hilft, das Projekt einfacher zu skalieren, und es verbessert die Entscheidungsfindung und Prognosen, wenn die Projektanforderungen steigen und komplex werden. Eine vorausschauende Planung verbessert auch die Fähigkeit des Teams, sich an Veränderungen anzupassen. Beispielsweise arbeitete ein großer Kunde aus dem Finanzdienstleistungssektor an einem Ausstiegsprogramm für Rechenzentren. Anfänglich plante der Kunde die Migrationswellen sequentiell, wobei er eine Welle abschloss, bevor er mit der Planung der nächsten begann. Dieser Ansatz führte zu einer kürzeren Vorbereitungszeit. Als die Beteiligten darüber informiert wurden, dass ihre Anwendungen migriert wurden AWS, mussten sie noch mehrere Schritte ausführen, bevor sie mit der Migration begannen. Dies führte zu erheblichen Verzögerungen im Programm. Nachdem der Kunde dies erkannt hatte, implementierte er eine ganzheitliche und zukunftsorientierte Migrationsplanung, bei der Migrationswellen mehrere Monate im Voraus geplant wurden. Dadurch hatten die Anwendungsteams genügend Zeit, um ihre Aktivitäten vor der Migration wie die Benachrichtigung der AWS Partner, Lizenzanalysen usw. durchzuführen. Anschließend konnten sie diese Aufgaben aus dem kritischen Pfad des Programms entfernen. ### Sorgen Sie dafür, dass Wave-Implementierung und Wave-Planung als separate Prozesse und Teams voneinander getrennt sind Wenn die Teams für Wellenplanung und Wellenimplementierung getrennt sind, können die beiden Prozesse parallel ablaufen. Durch Kommunikation und Koordination wird so eine Verlangsamung der Migration vermieden, da nicht genügend Server oder Anwendungen bereit sind, die erwartete Geschwindigkeit zu erreichen. Beispielsweise muss das Migrationsteam möglicherweise jede Woche 30 Server migrieren, aber in der aktuellen Welle sind nur 10 Server bereit. Diese Herausforderung wird häufig durch Folgendes verursacht: + Das Team für die Implementierung der Migration war nicht an der Planung der Welle beteiligt, und die in der Phase der Wellenplanung gesammelten Daten sind nicht vollständig. Das Team für die Implementierung der Migration muss mehr Serverdaten sammeln, bevor die Welle gestartet wird. + Die Implementierung der Migration soll unmittelbar nach der Planung der Welle beginnen, ohne dass dazwischen ein Puffer erforderlich ist. Es ist wichtig, die Phasen im Voraus zu planen und einen Puffer zwischen der Vorbereitung und dem Beginn der Implementierungswelle zu schaffen. Es ist auch wichtig sicherzustellen, dass das Wave-Planungsteam und das Migrationsteam zusammenarbeiten, um die richtigen Daten zu sammeln und Nacharbeiten zu vermeiden. ### Fangen Sie klein an, um großartige Ergebnisse zu erzielen Planen Sie, klein anzufangen und die Migrationsgeschwindigkeit mit jeder nachfolgenden Welle zu erhöhen. Bei der ersten Welle sollte es sich um eine einzelne, kleine Anwendung mit weniger als 10 Servern handeln. Fügen Sie in den nachfolgenden Wellen weitere Anwendungen und Server hinzu, sodass Sie Ihre volle Migrationsgeschwindigkeit erreichen. Durch die Priorisierung weniger komplexer oder riskanter Anwendungen und die Erhöhung der Geschwindigkeit nach einem Zeitplan hat das Team Zeit, sich auf die Zusammenarbeit einzustellen und den Prozess zu erlernen. Darüber hinaus kann das Team mit jeder Welle Prozessverbesserungen identifizieren und umsetzen, wodurch die Geschwindigkeit späterer Wellen erheblich verbessert werden kann. Ein Kunde migrierte in einem Jahr mehr als 1.300 Server. Das Migrationsteam begann mit einer Pilotmigration und einigen kleineren Wellen und konnte so mehrere Möglichkeiten zur Verbesserung späterer Migrationen identifizieren. So wurden beispielsweise bereits früher neue Netzwerksegmente für Rechenzentren identifiziert. Zu Beginn des Prozesses arbeiteten sie mit ihrem Firewall-Team zusammen, um Firewall-Regeln festzulegen, die die Kommunikation mit den Migrationstools ermöglichten. Dies trug dazu bei, unnötige Verzögerungen bei future Wellen zu vermeiden. Darüber hinaus war das Team in der Lage, Skripte zu entwickeln, um mit jeder Welle weitere Erkennungs- und Umstellungsprozesse zu automatisieren. Klein anzufangen half dem Team, sich auf frühe Prozessverbesserungen zu konzentrieren, und das Selbstvertrauen wurde erheblich gestärkt. ### Minimiere die Anzahl der Umstellungsfenster Massenmigrationen erfordern einen disziplinierten Ansatz zur Skalierung. In einigen Bereichen zu flexibel zu sein, ist ein Anti-Muster für große Migrationen. Durch die Begrenzung der Anzahl der wöchentlichen Umstellungsfenster hat die für Umstellungsaktivitäten aufgewendete Zeit einen höheren Wert. Wenn das Zeitfenster für die Umstellung beispielsweise zu flexibel ist, könnten Sie am Ende 20 Umstellungen mit jeweils fünf Servern haben. Stattdessen könnten Sie zwei Übernahmen mit jeweils 50 Servern vornehmen. Da der Zeit und der Aufwand für jede Umstellung ähnlich sind, reduzieren weniger, größere Umstellungen den betrieblichen Aufwand bei der Planung und verhindern unnötige Verzögerungen. Ein großes Technologieunternehmen versuchte, vor Ablauf des Vertrags einige geleaste Rechenzentren zu verlassen. Ein Versäumnis des Ablaufs würde zu teuren, kurzfristigen Verlängerungsbedingungen führen. Zu Beginn der Migration durften die Anwendungsteams den Migrationsplan bis zur letzten Minute festlegen, einschließlich der Abmeldung von der Migration aus beliebigem Grund, nur wenige Tage vor der Umstellung. Dies führte zu zahlreichen Verzögerungen in der Anfangsphase des Projekts. Oft musste der Kunde in letzter Minute mit anderen Anwendungsteams verhandeln, um auszufüllen. Der Kunde erhöhte schließlich seine Planungsdisziplin, aber dieser frühe Fehler führte zu ständigem Stress für das Migrationsteam. Verzögerungen beim Gesamtzeitplan führten dazu, dass einige Anwendungen die Rechenzentren nicht rechtzeitig verlassen konnten. ### Scheitern Sie schnell, wenden Sie Erfahrung an und wiederholen Sie Jede Migration hat anfangs Fallstricke. Ein frühes Scheitern hilft dem Team, zu lernen, die Engpässe zu verstehen und die gewonnenen Erkenntnisse auf größere Wellen anzuwenden. Es wird erwartet, dass die ersten paar Wellen einer Migration aus den folgenden Gründen langsam ablaufen werden: + Die Teammitglieder passen sich aneinander und dem Prozess an. + Bei großen Migrationen sind in der Regel viele verschiedene Tools und Personen involviert. + Es braucht Zeit, um den Prozess zu integrieren, zu testen, zu scheitern, zu lernen und kontinuierlich zu verbessern. end-to-end Probleme treten häufig auf und werden in den ersten Phasen erwartet. Es ist wichtig, dies zu verstehen und der gesamten Organisation mitzuteilen, da einige Teams möglicherweise nicht gerne neue Dinge ausprobieren und scheitern. Misserfolge können das Team entmutigen und future Migrationen blockieren. Der Schlüssel zu einer erfolgreichen Migration besteht darin, sicherzustellen, dass alle verstehen, dass anfängliche Probleme Teil der Arbeit sind, und alle dazu zu ermutigen, es zu versuchen und zu scheitern. Ein Unternehmen plante, innerhalb von 24 bis 36 Monaten mehr als 10.000 Server zu migrieren. Um dieses Ziel zu erreichen, mussten fast 300 Server pro Monat migriert werden. Das bedeutet jedoch nicht, dass sie vom ersten Tag an 300 Server migriert haben. Die ersten paar Wellen waren Lernwellen, sodass das Team verstehen konnte, wie die Dinge funktionierten und wer die Erlaubnis hatte, was zu tun. Sie identifizierten auch Integrationen, die den Prozess verbessern würden, wie z. B. die Integration mit CMDB und. CyberArk Sie nutzten die Lernwellen, um zu scheitern, sich zu verbessern und erneut zu scheitern und den Prozess und die Automatisierung zu verfeinern. Nach 6 Monaten waren sie in der Lage, jede Woche mehr als 120 Server zu migrieren. ### Vergessen Sie nicht die Retrospektive Dies ist ein wichtiger Teil eines agilen Prozesses. Hier kommuniziert das Team, passt sich an, lernt, stimmt zu und schreitet voran. Eine Retrospektive auf der grundlegendsten Ebene ist ein Rückblick, die Diskussion darüber, was passiert ist, die Feststellung, was gut gelaufen ist und was verbessert werden muss. Auf der Grundlage dieser Diskussionen können dann Verbesserungen vorgenommen werden. Bei Retrospektiven geht es um eine gewisse Formalität oder einen Prozess rund um die Idee der gewonnenen Erkenntnisse. Rückblicke sind wichtig, da die Prozesse, Tools und Teams ständig weiterentwickelt und verbessert werden müssen, um den Umfang und die Geschwindigkeit zu erreichen, die für den Erfolg großer Migrationen erforderlich sind. Retrospektiven können dabei eine wichtige Rolle spielen. Traditionelle Lektionen finden erst am Ende eines Programms statt, weshalb diese Lektionen zu Beginn der nächsten Migrationswelle oft nicht überprüft werden. Bei großen Migrationen sollten die gewonnenen Erkenntnisse auf die nächste Welle übertragen werden und ein wichtiger Bestandteil der Planung der Migrationswelle sein. Für einen Kunden wurden wöchentliche Retrospektiven abgehalten, um die aus den Umstellungen gewonnenen Erkenntnisse zu erörtern und zu dokumentieren. In diesen Sitzungen wurden Bereiche aufgedeckt, in denen aus Prozesssicht oder Automatisierung Optimierungspotenzial bestand. Dies führte zur Implementierung eines Countdown-Zeitplans mit spezifischen Aktivitäten, Eigentümern und Automatisierungsskripten, um manuelle Aufgaben, einschließlich der Validierung von Tools von Drittanbietern und der Installation von CloudWatch Amazon-Agenten, während der Umstellung zu minimieren. Bei einem anderen großen Technologieunternehmen wurden mit dem Team regelmäßig Retrospektiven abgehalten, um Probleme bei früheren Migrationswellen zu identifizieren. Dies führte zu Prozess-, Skript- und Automatisierungsverbesserungen, die die durchschnittliche Migrationszeit im Laufe des Programms um 40 Prozent verkürzten. ## Weitere Überlegungen Bei einem großen Migrationsprogramm müssen viele Bereiche berücksichtigt werden. In den folgenden Abschnitten finden Sie Überlegungen zu anderen Punkten, die berücksichtigt werden müssen. **Contents** + [Räum auf, während du gehst](#clean-up) + [Implementieren Sie mehrere Phasen für jede weitere Transformation](#phases) ### Räum auf, während du gehst Eine Migration gilt nicht als erfolgreich, wenn sie das Zehnfache Ihrer Erwartungen kostet und das Projekt erst abgeschlossen ist, wenn die für die Migration verwendeten Ressourcen heruntergefahren und bereinigt wurden. Diese Säuberung sollte Teil der Aktivitäten nach der Migration sein. Dadurch wird sichergestellt, dass Sie keine ungenutzten Ressourcen und Dienste in Ihrer Umgebung belassen, was die Kosten in die Höhe treibt. Die Säuberung nach der Migration ist auch eine gute Sicherheitsmaßnahme, um Bedrohungen und Sicherheitslücken zu verhindern, die Ihre Umgebung gefährden könnten. Zwei wichtige Ergebnisse der Umstellung auf die AWS Cloud sind die Kosteneinsparungen und die Sicherheit. Wenn Sie ungenutzte Ressourcen belassen, kann dies den Geschäftszweck der Umstellung auf die Cloud zunichte machen. Zu den häufigsten Ressourcen, die nicht bereinigt werden, gehören die folgenden: + Daten testen + Datenbanken testen + Testen Sie Konten, einschließlich Firewallregeln, Sicherheitsgruppen und IP-Adressen der Netzwerkzugriffskontrollliste (Network Access Control List, Netzwerk-ACL) + Für Tests bereitgestellte Ports + Amazon Elastic Block Store (Amazon EBS)-Volumes + -Snapshots + Replikation (z. B. das Stoppen der Datenreplikation von lokal nach) AWS + Dateien, die Speicherplatz verbrauchen (z. B. temporäre Datenbanksicherungen, die für die Migration verwendet werden) + Instanzen, die die Migrationstools hosten Ein Beispiel für schlechte Säuberungspraktiken war, dass AWS SI-Partner nach einer erfolgreichen Migration keine Replikationsagenten entfernten. Bei einer AWS Prüfung wurde festgestellt, dass Replikationsserver und EBS-Volumes, die bereits migriert worden waren, 20.000\$1 (USD) pro Monat kosteten. Um das Problem zu beheben, führte AWS Professional Services einen automatisierten Prüfprozess ein, der AWS SI-Partner darüber informierte, wenn veraltete Server immer noch repliziert wurden. Die AWS SI-Partner konnten dann Maßnahmen gegen ungenutzte und veraltete Instances ergreifen. Für future Migrationen wurde ein Prozess eingeführt, um eine Hypercare-Phase von 48 Stunden nach der Migration festzulegen, um eine reibungslose Einführung der Plattform zu gewährleisten. Das Infrastrukturteam des Kunden reichte daraufhin einen Antrag auf Außerbetriebnahme der lokalen Server ein. Es wurde darauf hingewiesen, dass nach Genehmigung des Stilllegungsantrags die Server der jeweiligen Welle aus der Servicekonsole für die Anwendungsmigration entfernt werden sollten. ### Implementieren Sie mehrere Phasen für jede weitere Transformation Bei der Durchführung einer großen Migration ist es wichtig, dass Sie sich weiterhin auf Ihr Kernziel konzentrieren, z. B. die Schließung von Rechenzentren oder die Transformation der Infrastruktur. Bei kleineren Migrationen kann die Ausweitung des Umfangs nur minimale Auswirkungen haben. Ein paar Tage zusätzlichen Aufwands, multipliziert mit potenziell Tausenden von Servern, können das Programm jedoch erheblich verlängern. Darüber hinaus können die zusätzlichen Änderungen auch Aktualisierungen der Dokumentation, des Prozesses und der Schulung der Support-Teams erfordern. Um eine mögliche Ausweitung des Umfangs zu vermeiden, können Sie bei Ihrer Migration einen mehrphasigen Ansatz implementieren. Wenn Ihr Ziel beispielsweise darin bestand, ein Rechenzentrum zu räumen, kann Phase 1 darin bestehen, den Workload nur so schnell wie möglich neu zu hosten. AWS Nach dem erneuten Hosten eines Workloads können in Phase 2 Transformationsaktivitäten implementiert werden, ohne das angestrebte Geschäftsergebnis zu gefährden. Ein Kunde plante beispielsweise, sein Rechenzentrum innerhalb von 12 Monaten zu verlassen. Ihre Migration umfasste jedoch auch andere Transformationsaktivitäten, wie die Einführung neuer Tools zur Überwachung der Anwendungsleistung und die Aktualisierung von Betriebssystemen. Mehr als 1.000 Server waren von der Migration betroffen, sodass diese Aktivitäten die Migration erheblich verzögerten. Darüber hinaus erforderte dieser Ansatz eine Schulung im Umgang mit den neuen Tools. Später entschied sich der Kunde für die Implementierung eines mehrphasigen Ansatzes, wobei der Schwerpunkt zunächst auf dem Rehost lag. Dies erhöhte die Migrationsgeschwindigkeit und verringerte das Risiko, dass das Schließungsdatum des Rechenzentrums nicht eingehalten wurde.