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.
# Beschleunigung der Entdeckung und erste Planung
Diese erste Phase der Portfoliobewertung konzentriert sich auf die ersten Schritte der Erfassung und Analyse von Daten auf Portfolioebene. Das Hauptziel besteht darin, Geschäftstreiber zu identifizieren und allgemeine Daten aus Anwendungen und Infrastruktur zu sammeln, um einen ersten Überblick über das Portfolio zu erhalten. Zu diesen Daten gehören wichtige technische und geschäftliche Merkmale wie Anwendungsnamen, Umgebung, Produktversionen, Kritikalität, Leistungswerte und andere, wie im Abschnitt [Datenanforderungen](understanding-initial-assessment-data-requirements.md) beschrieben. Der Abschluss dieser Phase ist entscheidend, um den Umfang des Projekts zu verstehen, erste Migrationskandidaten zu identifizieren und das Geschäftsszenario zu ermitteln.
## Wichtigste Ergebnisse dieser Phase
+ Dokumentierte Geschäftsfaktoren, Ergebnisse, Ziele und technische Leitprinzipien.
+ Eine erste Bestandsaufnahme der Anwendungen und der Infrastruktur sowie identifizierte Datenlücken. Dies ist ein erster Überblick über das Portfolio, der in weiteren Phasen wiederholt und verfeinert wird.
+ Ein konkretes Geschäftsszenario und die geschätzten Kosten für die Migration.
+ Eine Liste der ersten Migrationskandidaten (z. B. drei bis fünf Bewerbungen).
+ Die nächsten Schritte wurden definiert.
# Grundlegendes zu den Datenanforderungen für die Erstbewertung
Die Datenerfassung kann viel Zeit in Anspruch nehmen und leicht zu einem Hindernis werden, wenn nicht klar ist, welche Daten wann benötigt werden. Der Schlüssel liegt darin, das Gleichgewicht zwischen zu wenig und was zu vielen Daten für die Ergebnisse dieser Phase zu verstehen. Um sich auf die Daten und die Genauigkeit zu konzentrieren, die für diese frühe Phase der Portfoliobewertung erforderlich sind, sollten Sie bei der Datenerhebung einen iterativen Ansatz verfolgen.
## Datenquellen und Datenanforderungen
Der erste Schritt besteht darin, Ihre Datenquellen zu identifizieren. Identifizieren Sie zunächst die wichtigsten Stakeholder in Ihrem Unternehmen, die die Datenanforderungen erfüllen können. Dabei handelt es sich in der Regel um Mitglieder der Teams für Servicemanagement, Betrieb, Kapazitätsplanung, Überwachung und Support sowie um die Anwendungseigentümer. Richten Sie Arbeitssitzungen mit Mitgliedern dieser Gruppen ein. Kommunizieren Sie die Datenanforderungen und besorgen Sie sich eine Liste mit Tools und vorhandener Dokumentation, die die Daten bereitstellen können.
Verwenden Sie als Leitfaden für diese Konversationen die folgenden Fragen:
+ Wie genau und aktuell ist der aktuelle Infrastruktur- und Anwendungsbestand? Wissen wir beispielsweise bereits, wo die Lücken bestehen, was die Unternehmenskonfigurationsmanagement-Datenbank (CMDB) angeht?
+ Verfügen wir über aktive Tools und Prozesse, die die CMDB (oder ein gleichwertiges System) auf dem neuesten Stand halten? Wenn ja, wie oft wird sie aktualisiert? Was ist das letzte Aktualisierungsdatum?
+ Enthält application-to-infrastructure das aktuelle Inventar, z. B. die CMDB, eine Zuordnung? Ist jedes Infrastruktur-Asset einer Anwendung zugeordnet? Ist jede Anwendung der Infrastruktur zugeordnet?
+ Enthält das Inventar einen Katalog mit Lizenzen und Lizenzvereinbarungen für jedes Produkt?
+ Enthält das Inventar Abhängigkeitsdaten? Beachten Sie das Vorhandensein von Kommunikationsdaten wie Server zu Server, Anwendung zu Anwendung, Anwendung oder Server zu Datenbank.
+ Welche anderen Tools, die Anwendungs- und Infrastrukturinformationen bereitstellen können, sind in der Umgebung verfügbar? Beachten Sie, dass es Leistungs-, Überwachungs- und Verwaltungstools gibt, die als Datenquelle verwendet werden können.
+ Was sind die verschiedenen Standorte, z. B. Rechenzentren, an denen unsere Anwendungen und Infrastruktur gehostet werden?
Nachdem diese Fragen beantwortet wurden, listen Sie Ihre identifizierten Datenquellen auf. Weisen Sie dann jedem von ihnen ein gewisses Maß an Treue oder Vertrauen zu. Daten, die vor Kurzem (innerhalb von 30 Tagen) aus aktiven programmatischen Quellen wie Tools validiert wurden, weisen ein Höchstmaß an Genauigkeit auf. Statische Daten gelten als weniger originalgetreu und weniger vertrauenswürdig. Beispiele für statische Daten sind Dokumente, Arbeitsmappen, manuell aktualisierte CMDBs oder andere nicht programmgesteuert verwaltete Datensätze oder deren letztes Aktualisierungsdatum älter als 60 Tage ist.
Die Datengenauigkeitsstufen in der folgenden Tabelle dienen als Beispiele. Wir empfehlen Ihnen, die Anforderungen Ihres Unternehmens im Hinblick auf die maximale Toleranz gegenüber Annahmen und die damit verbundenen Risiken zu bewerten, um zu ermitteln, welches Maß an Genauigkeit angemessen ist. In der Tabelle bezieht sich institutionelles Wissen auf alle Informationen über Anwendungen und Infrastruktur, die nicht dokumentiert sind.
| **Datenquellen** | **Grad der Treue** | **Abdeckung des Portfolios** | **Kommentare** |
| --- |--- |--- |--- |
| Institutionelles Wissen | Niedrig — Bis zu 25% der korrekten Daten, 75% der angenommenen Werte oder Daten sind älter als 150 Tage. | Niedrig | Selten, konzentriert sich auf kritische Anwendungen |
| Wissensdatenbank | Mittel bis niedrig — 35-40% der korrekten Daten, 65-60% angenommene Werte oder Daten sind 120-150 Tage alt. | Mittel | Manuell verwaltete, inkonsistente Detaillierungsgrade |
| CMDB | Mittel: \$1 50% der korrekten Daten, \$1 50% angenommene Werte oder Daten sind 90-120 Tage alt. | Mittel | Enthält Daten aus gemischten Quellen, mehrere Datenlücken |
| VMware vCenter-Exporte | Mittel bis hoch: 75-80% der korrekten Daten, 25-20% angenommene Werte oder Daten sind 60-90 Tage alt. | Hoch | Deckt 90% des virtualisierten Bestands ab |
| Überwachung der Anwendungsleistung | Hoch — Überwiegend genaue Daten, \$1 5% der angenommenen Werte oder Daten sind 0-60 Tage alt. | Niedrig | Beschränkt auf kritische Produktionssysteme (deckt 15% des Anwendungsportfolios ab) |
In den folgenden Tabellen sind die erforderlichen und optionalen Datenattribute für jede Anlageklasse (Anwendungen, Infrastruktur, Netzwerke und Migration), die spezifische Aktivität (Inventar oder Geschäftsszenario) und die empfohlene Datentreue für diese Bewertungsphase aufgeführt. In den Tabellen werden die folgenden Abkürzungen verwendet:
+ R, für erforderlich
+ (D), für direktionale Geschäftsszenarien, erforderlich für Vergleiche der Gesamtbetriebskosten (TCO) und zielgerichtete Geschäftsfälle
+ (F), für einen vollständigen, zielgerichteten Geschäftsszenario, erforderlich für Vergleiche der Gesamtbetriebskosten und für zielgerichtete Geschäftsszenarien, die Migrations- und Modernisierungskosten beinhalten
+ O, für optional
+ N/A, für nicht zutreffend
**Anwendungen**
| **Attributname** | **Beschreibung** | **Inventar und Priorisierung** | **Geschäftsszenario** | **Empfohlene Treuestufe (mindestens)** |
| --- |--- |--- |--- |--- |
| Eindeutige Kennung | Zum Beispiel Anwendungs-ID. In der Regel in bestehenden CMDBs oder anderen internen Inventaren und Kontrollsystemen verfügbar. Erwägen Sie die Erstellung einzigartiger IDs Produkte, wann immer diese in Ihrer Organisation nicht definiert sind. | R | R (D) | Hoch |
| Anwendungsname | Name, unter dem diese Anwendung Ihrer Organisation bekannt ist. Geben Sie gegebenenfalls den Handelsnamen off-the-shelf (COTS) und den Produktnamen an. | R | R (D) | Mittel-Hoch |
| Ist COTS? | Ja oder Nein. Ob es sich um eine kommerzielle Anwendung oder eine interne Entwicklung handelt | R | R (D) | Mittel-Hoch |
| COTS-Produkt und Version | Name und Version des kommerziellen Softwareprodukts | R | R (D) | Mittel |
| Description | Primäre Anwendungsfunktion und Kontext | R | O | Mittel |
| Kritikalität | Zum Beispiel eine strategische oder umsatzgenerierende Anwendung oder die Unterstützung einer wichtigen Funktion | R | O | Mittel-Hoch |
| Typ | Zum Beispiel Datenbank, Kundenbeziehungsmanagement (CRM), Webanwendung, Multimedia, gemeinsam genutzter IT-Service | R | O | Mittel |
| Umgebung | Zum Beispiel Produktion, Vorproduktion, Entwicklung, Test, Sandbox | R | R (D) | Mittel-Hoch |
| Einhaltung gesetzlicher Vorschriften und Vorschriften | Für den Workload geltende Frameworks (z. B. HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) und regulatorische Anforderungen | R | R (D) | Mittel-Hoch |
| Abhängigkeiten | Upstream- und Downstream-Abhängigkeiten zu internen und externen Anwendungen oder Diensten. Nichttechnische Abhängigkeiten wie betriebliche Elemente (z. B. Wartungszyklen) | O | O | Mittel-Niedrig |
| Kartierung der Infrastruktur | Zuordnung zu physischen and/or virtuellen Ressourcen, aus denen die Anwendung besteht | O | O | Mittel |
| License | Lizenztyp für Standardsoftware (z. B. Microsoft SQL Server Enterprise) | O | R | Mittel-Hoch |
| Cost (Kosten) | Kosten für Softwarelizenzen, Softwarebetrieb und Wartung | – | O | Mittel |
**Infrastruktur**
| | | | | |
| --- |--- |--- |--- |--- |
| **Name des Attributs** | **Beschreibung** | **Inventar und Priorisierung** | **Geschäftsszenario** | **Empfohlene Treuestufe (mindestens)** |
| Eindeutige Kennung | Zum Beispiel Server-ID. In der Regel in bestehenden CMDBs oder anderen internen Inventar- und Kontrollsystemen verfügbar. Ziehen Sie es in Betracht IDs , einzigartige Produkte zu erstellen, wann immer diese in Ihrer Organisation nicht definiert sind. | R | R | Hoch |
| Name des Netzwerks | Assetname im Netzwerk (z. B. Hostname) | R | O | Mittel-Hoch |
| DNS-Name (vollqualifizierter Domänenname oder FQDN) | DNS-Name | O | O | Mittel |
| IP-Adresse und Netzmaske | Interne and/or öffentliche IP-Adressen | R | O | Mittel-Hoch |
| Asset type (Objekttyp) | Physischer oder virtueller Server, Hypervisor, Container, Gerät, Datenbankinstanz usw. | R | R | Mittel-Hoch |
| Product Name (Produktname) | Kommerzieller Anbieter und Produktname (z. B. IBM Power Systems VMware ESXi, Exadata) | R | R | Mittel |
| Betriebssystem | Zum Beispiel REHL 8, Windows Server 2019, AIX 6.1 | R | R | Mittel-Hoch |
| Konfiguration | Zugewiesene CPU, Anzahl der Kerne, Threads pro Kern, Gesamtspeicher, Netzwerkkarten | R | R | Mittel-Hoch |
| Nutzung | Spitzenwert und Durchschnitt von CPU, Arbeitsspeicher und Speicher. Durchsatz der Datenbankinstanz. | R | O | Mittel-Hoch |
| License | Art der Warenlizenz (z. B. RHEL Standard) | R | R | Mittel |
| Handelt es sich um eine gemeinsame Infrastruktur? | Ja oder Nein, um Infrastrukturdienste zu bezeichnen, die gemeinsam genutzte Dienste wie Authentifizierungsanbieter, Überwachungssysteme, Backup-Dienste und ähnliche Dienste bereitstellen | R | R (D) | Mittel |
| Zuordnung von Anwendungen | Anwendungen oder Anwendungskomponenten, die in dieser Infrastruktur ausgeführt werden | O | O | Mittel |
| Cost (Kosten) | Vollständige Kosten für Bare-Metal-Server, einschließlich Hardware, Wartung, Betrieb, Speicher (SAN, NAS, Object), Betriebssystemlizenz, Anteil an Rackspace und Gemeinkosten für Rechenzentren | – | O | Mittel-Hoch |
**Netzwerke**
| | | | | |
| --- |--- |--- |--- |--- |
| **Name des Attributs** | **Beschreibung** | **Inventar und Priorisierung** | **Geschäftsszenario** | **Empfohlene Treuestufe (mindestens)** |
| Größe des Rohres (Mb/s), redundancy (Y/N) | Aktuelle WAN-Link-Spezifikationen (z. B. 1000 MB/s redundant) | O | R | Mittel |
| Link-Nutzung | Spitzen- und Durchschnittsauslastung, ausgehende Datenübertragung (GB/Monat) | O | R | Mittel |
| Latenz (ms) | Aktuelle Latenz zwischen verbundenen Standorten. | O | O | Mittel |
| Cost (Kosten) | Aktuelle Kosten pro Monat | – | O | Mittel |
**Migration**
| | | | | |
| --- |--- |--- |--- |--- |
| **Name des Attributs** | **Beschreibung** | **Inventar und Priorisierung** | **Geschäftsszenario** | **Empfohlene Treuestufe (mindestens)** |
| Erneut hosten | Aufwand für Kunden und Partner für jeden Workload (Personentage), Kostensätze für Kunden und Partner pro Tag, Werkzeugkosten, Anzahl der Workloads | – | R (F) | Mittel-Hoch |
| Plattformwechsel | Aufwand für Kunden und Partner für jeden Workload (Personentage), Kostensätze für Kunden und Partner pro Tag, Anzahl der Workloads | – | R (F) | Mittel-Hoch |
| Refaktorieren | Aufwand für Kunden und Partner für jeden Workload (Personentage), Kostensätze für Kunden und Partner pro Tag, Anzahl der Workloads | – | O | Mittel-Hoch |
| Ausmustern | Anzahl der Server, durchschnittliche Stilllegungskosten | – | O | Mittel-Hoch |
| Landezone | Wiederverwendung vorhandener (J/N), Liste der benötigten AWS Regionen, Kosten | – | R (F) | Mittel-Hoch |
| Menschen und Veränderung | Anzahl der Mitarbeiter, die im Bereich Cloud-Betrieb und -Entwicklung geschult werden müssen, Schulungskosten pro Person, Kosten für Schulungszeit pro Person | – | R (F) | Mittel-Hoch |
| Dauer | Dauer der Workload-Migration innerhalb des Geltungsbereichs (Monate) | O | R (F) | Mittel-Hoch |
| Parallele Kosten | Zeitrahmen und Geschwindigkeit, in der Ist-Kosten während der Migration wegfallen können | – | O | Mittel-Hoch |
| Zeitrahmen und Geschwindigkeit, in der AWS Produkte und Dienstleistungen sowie andere Infrastrukturkosten während der Migration eingeführt werden | – | O | Mittel-Hoch |
## Bewertung des Bedarfs an Discovery-Tools
Benötigt Ihr Unternehmen Discovery-Tools? Für die Portfoliobewertung sind zuverlässige up-to-date Daten über Anwendungen und Infrastruktur erforderlich. In der Anfangsphase der Portfoliobewertung können Annahmen verwendet werden, um Datenlücken zu schließen.
Wenn jedoch Fortschritte erzielt werden, ermöglichen präzise Daten die Erstellung erfolgreicher Migrationspläne und die korrekte Schätzung der Zielinfrastruktur, um die Kosten zu senken und den Nutzen zu maximieren. Es reduziert auch das Risiko, indem Implementierungen ermöglicht werden, die Abhängigkeiten berücksichtigen und Fallstricke bei der Migration vermeiden. Der Hauptanwendungsfall von Discovery-Tools in Cloud-Migrationsprogrammen besteht darin, Risiken zu reduzieren und das Vertrauen in Daten durch folgende Maßnahmen zu erhöhen:
+ Automatisierte oder programmatische Datenerfassung, die zu validierten, äußerst vertrauenswürdigen Daten führt
+ Beschleunigung der Datenerfassungsrate, wodurch die Projektgeschwindigkeit verbessert und die Kosten gesenkt werden
+ Höhere Vollständigkeit der Daten, einschließlich Kommunikationsdaten und Abhängigkeiten, die normalerweise nicht verfügbar sind in CMDBs
+ Gewinnung von Erkenntnissen wie automatisierter Anwendungsidentifikation, Gesamtbetriebskostenanalyse, prognostizierten Ausführungsraten und Optimierungsempfehlungen
+ Zuverlässige Planung von Migrationswellen
Wenn unsicher ist, ob an einem bestimmten Standort Systeme vorhanden sind, können die meisten Erkennungstools Netzwerksubnetze scannen und die Systeme ausfindig machen, die auf Ping- oder SNMP-Anfragen (Simple Network Management Protocol) reagieren. Beachten Sie, dass nicht alle Netzwerk- oder Systemkonfigurationen Ping- oder SNMP-Verkehr zulassen. Besprechen Sie diese Optionen mit Ihren Netzwerk- und Technikteams.
Weitere Phasen der Bewertung und Migration des Anwendungsportfolios hängen in hohem Maße von genauen Informationen zur Abhängigkeitszuweisung ab. Die Zuordnung von Abhängigkeiten vermittelt ein Verständnis der Infrastruktur und Konfiguration, die erforderlich sein werden AWS (z. B. Sicherheitsgruppen, Instanztypen, Kontoplatzierung und Netzwerk-Routing). Es hilft auch bei der Gruppierung von Anwendungen, die gleichzeitig verschoben werden müssen (z. B. Anwendungen, die über Netzwerke mit niedriger Latenz kommunizieren müssen). Darüber hinaus liefert die Zuordnung von Abhängigkeiten Informationen zur Weiterentwicklung des Geschäftsszenarios.
Bei der Entscheidung für ein Discovery-Tool ist es wichtig, alle Phasen des Bewertungsprozesses zu berücksichtigen und die Datenanforderungen zu antizipieren. Datenlücken können zu Hindernissen werden. Daher ist es wichtig, diese zu antizipieren, indem future Datenanforderungen und Datenquellen analysiert werden. Die Erfahrung in diesem Bereich zeigt, dass die meisten ins Stocken geratenen Migrationsprojekte nur über einen begrenzten Datensatz verfügen, in dem die betreffenden Anwendungen, die zugehörige Infrastruktur und ihre Abhängigkeiten nicht eindeutig identifiziert werden. Diese mangelnde Identifizierung kann zu falschen Kennzahlen, Entscheidungen und Verzögerungen führen. Die Beschaffung von up-to-date Daten ist der erste Schritt zu erfolgreichen Migrationsprojekten.
*Wie wähle ich ein Discovery-Tool aus?*
Verschiedene Discovery-Tools auf dem Markt bieten unterschiedliche Funktionen und Fähigkeiten. Berücksichtigen Sie Ihre Anforderungen. Und entscheiden Sie sich für die für Ihr Unternehmen am besten geeignete Option. Die häufigsten Faktoren bei der Entscheidung für ein Discovery-Tool für Migrationen sind die folgenden:
*Sicherheit*
+ Was ist die Authentifizierungsmethode für den Zugriff auf das Tool-Daten-Repository oder die Analyse-Engines?
+ Wer kann auf die Daten zugreifen und welche Sicherheitskontrollen gibt es für den Zugriff auf das Tool?
+ Wie sammelt das Tool Daten? Benötigt es spezielle Anmeldeinformationen?
+ Welche Anmeldeinformationen und Zugriffsebene benötigt das Tool, um auf meine Systeme zuzugreifen und Daten abzurufen?
+ Wie werden Daten zwischen den Komponenten des Tools übertragen?
+ Unterstützt das Tool die Datenverschlüsselung im Ruhezustand und bei der Übertragung?
+ Sind Daten in einer einzigen Komponente innerhalb oder außerhalb meiner Umgebung zentralisiert?
+ Was sind die Netzwerk- und Firewallanforderungen?
Stellen Sie sicher, dass Sicherheitsteams frühzeitig in Gespräche über Discovery-Tools einbezogen werden.
*Datensouveränität*
+ Wo werden die Daten gespeichert und verarbeitet?
+ Verwendet das Tool ein Software-as-a-Service-Modell (SaaS)?
+ Hat es die Möglichkeit, alle Daten innerhalb der Grenzen meiner Umgebung aufzubewahren?
+ Können Daten überprüft werden, bevor sie die Grenzen meines Unternehmens verlassen?
Berücksichtigen Sie die Anforderungen Ihres Unternehmens in Bezug auf die Anforderungen an die Datenresidenz.
*Architektur*
+ Welche Infrastruktur ist erforderlich und was sind die verschiedenen Komponenten?
+ Ist mehr als eine Architektur verfügbar?
+ Unterstützt das Tool die Installation von Komponenten in luftverriegelten Sicherheitszonen?
*Leistung*
+ Welche Auswirkungen hat die Datenerfassung auf meine Systeme?
*Kompatibilität und Umfang*
+ Unterstützt das Tool alle oder die meisten meiner Produkte und Versionen? Lesen Sie die Dokumentation des Tools, um zu überprüfen, ob die unterstützten Plattformen mit den aktuellen Informationen zu Ihrem Anwendungsbereich übereinstimmen.
+ Werden die meisten meiner Betriebssysteme für die Datenerfassung unterstützt? Wenn Sie Ihre Betriebssystemversionen nicht kennen, versuchen Sie, die Liste der Erkennungstools auf diejenigen zu beschränken, die ein breiteres Spektrum unterstützter Systeme anbieten.
*Methoden zur Erfassung*
+ Muss das Tool auf jedem Zielsystem einen Agenten installieren?
+ Unterstützt es Bereitstellungen ohne Agenten?
+ Bieten Agenten und ohne Agenten dieselben Funktionen?
+ Was ist der Inkassoprozess?
*Funktionen*
+ Welche Funktionen sind verfügbar?
+ Kann es die Gesamtbetriebskosten (TCO) und die geschätzte AWS Cloud Betriebsrate berechnen?
+ Unterstützt es die Migrationsplanung?
+ Misst es die Leistung?
+ Kann es eine AWS Zielinfrastruktur empfehlen?
+ Führt es eine Abhängigkeitszuweisung durch?
+ Welches Maß an Abhängigkeitszuweisung bietet es?
+ Bietet es API-Zugriff? (Kann zum Beispiel programmgesteuert darauf zugegriffen werden, um Daten abzurufen?)
Erwägen Sie Tools mit starken Funktionen zur Zuordnung von Anwendungs- und Infrastrukturabhängigkeiten und solche, die Anwendungen anhand von Kommunikationsmustern ableiten können.
*Kosten*
+ Was ist das Lizenzmodell?
+ Wie viel kostet die Lizenzierung?
+ Gilt der Preis für jeden Server? Handelt es sich um eine gestaffelte Preisgestaltung?
+ Gibt es Optionen mit eingeschränkten Funktionen, die bei Bedarf lizenziert werden können?
Discovery-Tools werden in der Regel während des gesamten Lebenszyklus von Migrationsprojekten eingesetzt. Wenn Ihr Budget begrenzt ist, sollten Sie mindestens 6 Monate in Betracht ziehen. Das Fehlen von Discovery-Tools führt jedoch in der Regel zu höherem manuellen Aufwand und internen Kosten.
*Modell Support*
+ Welche Support-Stufen werden standardmäßig bereitgestellt?
+ Ist ein Supportplan verfügbar?
+ Wie sind die Reaktionszeiten bei Vorfällen?
*Professionelle Dienstleistungen*
+ Bietet der Anbieter professionelle Dienstleistungen zur Analyse der Forschungsergebnisse an?
+ Können sie die Elemente dieses Handbuchs behandeln?
+ Gibt es Rabatte oder Pakete für Tooling\$1-Services?
**Tipp**
Verwenden Sie die Website Discovery, [Planning and Recommendation, um Discovery-Tools zu finden und](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/) zu testen.
*Empfohlene Funktionen für das Discovery-Tool*
Um zu vermeiden, dass Daten aus mehreren Tools im Laufe der Zeit bereitgestellt und kombiniert werden, sollte ein Discovery-Tool die folgenden Mindestfunktionen abdecken:
+ **Software** — Das Discovery-Tool sollte in der Lage sein, laufende Prozesse und installierte Software zu identifizieren.
+ **Zuordnung von Abhängigkeiten** — Es sollte in der Lage sein, Netzwerkverbindungsinformationen zu sammeln und eingehende und ausgehende Abhängigkeitszuordnungen der Server und laufenden Anwendungen zu erstellen. Außerdem sollte das Erkennungstool in der Lage sein, auf der Grundlage von Kommunikationsmustern auf Anwendungen aus Infrastrukturgruppen zu schließen.
+ **Profil- und Konfigurationserkennung** — Es sollte in der Lage sein, das Infrastrukturprofil wie die CPU-Familie (z. B. x86, PowerPC), die Anzahl der CPU-Kerne, die Speichergröße, die Anzahl der Festplatten und Größe sowie die Netzwerkschnittstellen zu melden.
+ **Erkennung von Netzwerkspeichern** — Es sollte in der Lage sein, Netzwerkfreigaben von Netzwerkspeichern (NAS) zu erkennen und ein Profil zu erstellen.
+ **Leistung** — Es sollte in der Lage sein, Spitzen- und Durchschnittsauslastung von CPU, Arbeitsspeicher, Festplatte und Netzwerk zu melden.
+ **Lückenanalyse** — Sie sollte Einblicke in die Menge und Genauigkeit der Daten liefern können.
+ **Netzwerk-Scanning** — Es sollte in der Lage sein, Netzwerk-Subnetze zu scannen und unbekannte Infrastrukturressourcen zu entdecken.
+ **Berichterstattung** — Es sollte in der Lage sein, den Status der Erfassung und Analyse zu ermitteln.
+ **API-Zugriff** — Es sollte in der Lage sein, programmatische Mittel für den Zugriff auf gesammelte Daten bereitzustellen.
*Zusätzliche zu berücksichtigende Funktionen*
+ **Analyse der Gesamtbetriebskosten**, um einen Kostenvergleich zwischen den aktuellen Kosten vor Ort und den voraussichtlichen AWS Kosten zu ermöglichen.
+ **Lizenzanalyse und Optimierungsempfehlungen** für Microsoft SQL Server- und Oracle-Systeme in Rehost- und Replattform-Szenarien.
+ **Empfehlung zur Migrationsstrategie** (Kann das Discovery-Tool Standardempfehlungen vom Typ R auf der Grundlage der aktuellen Technologie aussprechen?)
+ **Inventarexport** (in CSV oder ein ähnliches Format)
+ **Empfehlung zur richtigen Dimensionierung** (kann sie beispielsweise eine empfohlene AWS Zielinfrastruktur abbilden?)
+ **Visualisierung von Abhängigkeiten** (kann die Zuordnung von Abhängigkeiten beispielsweise in einem grafischen Modus visualisiert werden?)
+ **Architekturansicht** (können beispielsweise Architekturdiagramme automatisch erstellt werden?)
+ **Priorisierung von Anwendungen** (Kann es Anwendungs- und Infrastrukturattributen Gewicht oder Relevanz zuweisen, um Priorisierungskriterien für die Migration festzulegen?)
+ **Wellenplanung** (z. B. empfohlene Anwendungsgruppen und die Möglichkeit, Migrationswellenpläne zu erstellen)
+ **Schätzung der Migrationskosten (Schätzung** des Migrationsaufwands)
*Überlegungen zur Bereitstellung*
Nachdem Sie ein Discovery-Tool ausgewählt und erworben haben, sollten Sie sich die folgenden Fragen stellen, um Gespräche mit den Teams anzuregen, die für die Implementierung des Tools in Ihrem Unternehmen verantwortlich sind:
+ Werden Server oder Anwendungen von einem Drittanbieter betrieben? Dies könnte die beteiligten Teams und die einzuhaltenden Prozesse vorschreiben.
+ Was ist das allgemeine Verfahren, um die Genehmigung für den Einsatz von Discovery-Tools zu erhalten?
+ Was ist der wichtigste Authentifizierungsprozess für den Zugriff auf Systeme wie Server, Container, Speicher und Datenbanken? Sind Serveranmeldedaten lokal oder zentralisiert? Wie erfolgt das Abrufen von Anmeldeinformationen? Für die Erfassung von Daten aus Ihren Systemen (z. B. Containern, virtuellen oder physischen Servern, Hypervisoren und Datenbanken) sind Anmeldeinformationen erforderlich. Die Beschaffung von Anmeldeinformationen für das Discovery-Tool, mit dem eine Verbindung zu den einzelnen Ressourcen hergestellt werden kann, kann schwierig sein, insbesondere wenn diese Ressourcen nicht zentralisiert sind.
+ Wie sind die Sicherheitszonen im Netzwerk umrissen? Sind Netzwerkdiagramme verfügbar?
+ Wie wird das Anfordern von Firewallregeln in den Rechenzentren durchgeführt?
+ Was sind die aktuellen Service Level Agreements (SLAs) für den Support in Bezug auf den Betrieb von Rechenzentren (Installation von Discovery-Tools, Firewall-Anfragen)?
# Geschäftliche Faktoren und technische Leitprinzipien
## Geschäftliche Faktoren
Ganz gleich, ob sich Ihr Unternehmen bereits für den Umstieg auf die Cloud entschieden hat oder kurz davor steht, durch die Definition und Dokumentation der Geschäftsfaktoren für die Cloud-Migration werden die Gründe für die Migration geklärt. Nachdem die Gründe dokumentiert sind, können Sie definieren, was migriert werden soll und wie es migriert werden soll. Diese Aktivität ist wichtig. Wir empfehlen, dass sie so früh wie möglich im Prozess stattfindet, um Sie über die nächsten Schritte zu informieren und zu leiten.
Identifizieren Sie die Interessengruppen, die an der Diskussion teilnehmen sollten, um die treibenden Faktoren zu dokumentieren. In CxOs der Regel Führungskräfte und führende Technologieführer innerhalb des Unternehmens sowie Ihre eigenen Kunden. Auch wenn es unwahrscheinlich ist, dass Ihre Kunden an dieser Diskussion teilnehmen, empfehlen wir, dass eine oder mehrere Personen in Ihrem Unternehmen benannt werden, die die Ansichten und Ziele Ihrer Kunden vertreten.
Geschäftliche Faktoren sollten mit einer Kennzahl verknüpft werden, die während des gesamten Migrationsprozesses gemessen werden kann, um zu überprüfen, ob die Ergebnisse erzielt wurden. Die strategischen Ziele und Jahresberichte des Unternehmens können als Ausgangspunkt dienen.
Konzentrieren Sie das Gespräch darauf, wo sich das Unternehmen aufgrund der Umstellung auf die Cloud auf der Grundlage vorhandener und prognostizierter Kennzahlen befinden möchte. Berücksichtigen Sie Ziele und Geschäftsergebnisse. Denken Sie auch darüber nach, wie Erfolg aussieht, wenn die Cloud-Akzeptanz zunimmt.
Als Nächstes legen Sie die Wichtigkeitsstufe für jeden Treiber fest. Was sind die Prioritäten? Was sind die erwarteten Vorteile? Wie unterstützen die Vorteile die Unternehmensziele und -ergebnisse? Im Rahmen der Bewertung des Anwendungsportfolios werden die Antworten dazu beitragen, die zu migrierenden Workloads zu priorisieren und technische Leitprinzipien festzulegen. Geschäftliche Faktoren werden jedoch das Migrationsprogramm als Ganzes definieren und beeinflussen.
## Technische Leitprinzipien
Technische Leitprinzipien bilden die Grundlage für die Auswahl der Migrationsstrategie in späteren Phasen der Portfoliobewertung. In der aktuellen Phase liegt der Schwerpunkt darauf, sie zu identifizieren.
Leitprinzipien können als allgemeine technologiebezogene und konzeptionelle Entscheidungen festgelegt werden, die sich aus Geschäftszielen und -ergebnissen ableiten.
Ein Unternehmen hat beispielsweise das Hauptziel, die Kosten zu senken, und das angestrebte Ergebnis besteht darin, ein lokales Rechenzentrum innerhalb von 6—12 Monaten bis zu einem bestimmten Datum zu schließen. Ein daraus resultierendes Leitprinzip besteht darin, alle Anwendungen hochzuladen und in die Cloud zu verlagern, wobei, wann immer möglich, eine Strategie zur Neuhostung oder Verlagerung der Migration verwendet wird. In diesem Fall beschleunigt der lift-and-shift Ansatz die kurzfristigen Migrationsergebnisse. Nachdem die Anwendungen das lokale Rechenzentrum verlassen haben, kann sich das Unternehmen auf die wichtigsten Geschäftstreiber konzentrieren, um die migrierten Workloads zu optimieren oder zu modernisieren.
Um die technischen Leitprinzipien festzulegen, analysieren Sie zunächst die Geschäftstreiber. Identifizieren Sie eine Liste von Technologien und Techniken, mit denen die Geschäftsziele und -ergebnisse erreicht werden können. Verfeinern Sie als Nächstes die Liste und ordnen Sie sie auf der Grundlage von Eignung oder Präferenz eine Reihenfolge der Relevanz zu, um das gewünschte Ergebnis zu erzielen.
Dokumentieren Sie die Leitprinzipien und kommunizieren Sie sie mit den Personen, die an der Planung und Durchführung der Migration beteiligt sind. Machen Sie auf Bedenken und mögliche Konflikte zwischen den Grundsätzen und der tatsächlichen Umsetzung aufmerksam.
Die folgende Tabelle enthält ein Beispiel für Geschäftstreiber und technische Leitprinzipien.
| **Geschäftlicher Treiber** | **Ergebnis** | **Metriken** | **Technischer Leitgedanke** |
| --- |--- |--- |--- |
| Beschleunigen Sie Innovationen. | Verbesserte Wettbewerbsfähigkeit, erhöhte geschäftliche Flexibilität | Anzahl der Implementierungen pro Tag oder Monat, pro Quartal veröffentlichte neue Funktionen, Kundenzufriedenheitswerte, Anzahl der Experimente | Refaktorieren Sie Anwendungen, die sich von der Konkurrenz abheben, indem Sie Microservices und das DevOps Betriebsmodell nutzen, um die Agilität zu erhöhen und die Markteinführung neuer Funktionen zu beschleunigen. |
| Senken Sie die Betriebs- und Infrastrukturkosten. | Auf Angebot und Nachfrage abgestimmte, flexible Kostenbasis (zahlen Sie für das, was Sie nutzen) | Veränderung der Ausgaben im Laufe der Zeit | 1. Rehosten Sie Anwendungen mit der richtigen Größe der Infrastruktur. 2. Anwendungen, die wenig oder gar nicht genutzt werden, werden außer Betrieb genommen. |
| Erhöhen Sie die betriebliche Resilienz. | Verbesserte Verfügbarkeit, kürzere durchschnittliche Wiederherstellungszeit | SLAs, Anzahl der Vorfälle | 1. Platformieren Sie Anwendungen auf die neuesten und am besten unterstützten Betriebssystemversionen. 2. Implementieren Sie Hochverfügbarkeitsarchitekturen für kritische Anwendungen. |
| Verlassen Sie das Rechenzentrum. | Schließung des Rechenzentrums innerhalb von 6—12 Monaten | Geschwindigkeit der Servermigrationen | Rehosten Sie Anwendungen mithilfe der Cloud Migration Factory-Lösung. |
| Bleiben Sie vor Ort, erhöhen Sie jedoch die Agilität und Resilienz. | Verbesserte Wettbewerbsfähigkeit und Verfügbarkeit bei gleichzeitiger Beibehaltung des Betriebs vor Ort | Anzahl der Bereitstellungen pro Tag oder Monat, Veröffentlichung neuer Funktionen pro Quartal SLAs, Anzahl der Vorfälle | 1. Modernisieren Sie Systeme, indem Sie ihre Funktionalität auf die Cloud ausdehnen.2. Prüfen Sie, ob ein Rehosting oder eine neue Plattform erforderlich ist. AWS Outposts |
# Datenerfassung wird eingeleitet
Datenerfassung ist der Prozess der Erfassung von Metadaten aus Anwendungen und Infrastruktur. Der Prozess ist in allen Phasen der Bewertung iterativ. In jeder Phase werden Menge und Genauigkeit der Daten zunehmen. In dieser Phase liegt der Schwerpunkt auf der Erfassung allgemeiner Daten, die bei der Erstellung einer ersten Bestandsaufnahme helfen können. Das Inventar wird verwendet, um ein konkretes Geschäftsszenario zu erstellen und erste Migrationskandidaten zu identifizieren.
Nachdem die aktuellen Datenquellen identifiziert wurden, empfehlen wir, Informationen aus so vielen Systemen wie möglich zu sammeln. Weitere Informationen finden Sie in den [Datenanforderungen](understanding-initial-assessment-data-requirements.md) für diese Phase.
Dieser Ansatz hat den Vorteil, dass er dazu beiträgt, die aktuelle Portfolioansicht und das Wissen der Organisation über ihre Anwendungen und Dienste auf den neuesten Stand zu bringen. Es hilft auch bei der Bestimmung, was verschoben werden soll. Der empfohlene Ansatz besteht darin, vorhandene Daten zu überprüfen, z. B. die Ergebnisse der Configuration Management Database (CMDB) und Systeme für das Informationstechnologie-Servicemanagement (ITSM). Erstellen Sie anschließend eine Liste von Ressourcen, die für die Datenerfassung vorgesehen sind. Wenn Ihr Unternehmen sich darüber im Klaren ist, was in den Geltungsbereich der Migration fällt und was nicht, können Sie die Datenerfassung auf die Systeme beschränken, die in den Geltungsbereich fallen.
Berücksichtigen Sie beim Aufbau Ihres Portfolios die Anwendungen und ihre Umgebungen oder die Lebenszyklen von Softwareversionen. Anstatt beispielsweise eine CRM-Anwendung (Customer Relationship Management) zu identifizieren und anzugeben, dass sie über Test-, Entwicklungs- und Produktionsumgebungen verfügt, sollten Sie drei Anwendungen auflisten (z. B. CRM-Test, CRM-Dev, CRM-Prod). Verwenden Sie alternativ den CRM-Namen, weisen Sie jedoch jeder Umgebung eine eindeutige ID zu und präsentieren Sie sie als separate Datensätze in Ihrem Datenspeicher. Dies hilft bei der individuellen Planung und Nachverfolgung der Migration dieser Umgebungen. Beispielsweise möchten Sie möglicherweise zuerst Umgebungen migrieren, die keine Produktionsumgebungen sind. Indem Sie die Instanzen Ihrer Anwendung entsprechend der Umgebung auflisten, können Sie deren Umstellung übersichtlich verwalten und steuern.
Bei der Datenerfassung kann es zu Unklarheiten darüber kommen, welche Anwendungen oder Server sich in einem bestimmten Rechenzentrum oder an einem bestimmten Quellstandort befinden. In diesen Fällen ist es hilfreich, Bare-Metal- und Hypervisor-Listen aus vorhandenen Verwaltungstools abzurufen. Sie können beispielsweise eine Verbindung zu einem Hypervisor herstellen, um Listen mit virtuellen Maschinen abzurufen, die als Ziel für die Datenerfassung verwendet werden sollen.
Beachten Sie, dass die ursprüngliche Ausgabe bei der Kombination vorhandener Datenquellen unvollständig sein kann. Der Schlüssel liegt in der Durchführung einer Lückenanalyse in Bezug auf die [Datenanforderungen](understanding-initial-assessment-data-requirements.md) für diese Phase und darauf, was aus vorhandenen Quellen gewonnen werden kann. Es ist wichtig, den Grad der Vollständigkeit dem Grad der Datentreue gegenüberzustellen. Höhere Vollständigkeitsgrade aus Quellen mit geringer Genauigkeit beinhalten mehrere Annahmen, die zu fehlerhaften Analysen führen könnten. Für diese Bewertungsphase ist zwar nicht die größtmögliche Genauigkeit der Daten erforderlich, wir empfehlen jedoch, dass die Datenquellen mindestens eine mittlere bis mittlere Genauigkeit aufweisen. Vergleichen Sie diese Zahlen mit der Risikotoleranz Ihres Unternehmens, einschließlich der Verwendung von Annahmen, um Datenlücken zu schließen.
Die Lückenanalyse hilft Ihnen dabei, die Menge und Qualität der Daten, mit denen Sie arbeiten, besser zu verstehen. Die Analyse hilft Ihnen auch dabei, das Niveau der Annahmen zu ermitteln, die getroffen werden müssen, um ein aussagekräftiges Geschäftsszenario zu erstellen und Anwendungen für die Migration zu priorisieren. Discovery-Tools können dabei helfen, die Lücken zu schließen und originalgetreue Daten zu sammeln. Um das Vertrauen in Daten zu erhöhen und die Migrationsergebnisse zu beschleunigen, empfehlen wir, Discovery-Tools so früh wie möglich einzusetzen. Frühzeitiges Handeln ist auch wichtig, da interne Beschaffungs-, Sicherheits- und Implementierungsprozesse für neue Tools mehrere Wochen oder Monate in Anspruch nehmen können.
Wir empfehlen, in dieser Phase einen Kommunikationsplan oder einen Kommunikationsrhythmus und einen Kontrollmechanismus für die Änderung des Geltungsbereichs festzulegen. Dies hilft Ihnen, die Beteiligten auf dem Laufenden zu halten, sodass sie vorausschauend planen und Risiken mindern können. Ein Schlüsselelement für eine klare Kommunikation ist die Definition einer zentralen Informationsquelle für das Anwendungsportfolio und die zugehörige Infrastruktur. Vermeiden Sie es, mehrere Aufzeichnungssysteme sowie Anwendungs- und Infrastrukturlisten zu führen. Bewahren Sie Daten an einem Ort auf (z. B. in einer Datenbank, einem Tool oder einer Tabelle), der Versionsverwaltung und Online-Zusammenarbeit unterstützt, und weisen Sie ihr einen Besitzer zu.
# Priorisierung und Migrationsstrategie
Ein zentrales Element der Migrationsplanung ist die Festlegung von Priorisierungskriterien. Bei dieser Übung geht es darum, die Reihenfolge zu verstehen, in der Anwendungen migriert werden. Die Strategie besteht darin, das Priorisierungsmodell iterativ und progressiv weiterzuentwickeln.
## Priorisierung von Anwendungen
In dieser Bewertungsphase liegt der Schwerpunkt auf der Festlegung erster Kriterien für die Priorisierung von Workloads mit geringem Risiko und geringer Komplexität. Diese Workloads eignen sich gut für Pilotanwendungen. Die Verwendung von Workloads mit geringem Risiko und geringer Komplexität bei ersten Migrationen reduziert das Risiko und gibt Teams die Möglichkeit, Erfahrungen zu sammeln. Diese Kriterien werden in weiteren Bewertungsphasen weiterentwickelt, um die Priorisierung bei der Erstellung des Migrationswellenplans an den Geschäftsfaktoren auszurichten.
Bei den ersten Kriterien sollten Anwendungen mit einer geringen Anzahl von Abhängigkeiten, die in einer Cloud-gestützten Infrastruktur und in Umgebungen außerhalb der Produktionsumgebung ausgeführt werden, Priorität eingeräumt werden. Ein Beispiel wären Anwendungen mit 0—3 Abhängigkeiten, die bereit sind, unverändert in einer Entwicklungs- oder Testumgebung neu gehostet zu werden. Diese Kriterien gelten für die Definition der Pilotanwendungen und möglicherweise der ersten und zweiten Migrationswelle, je nach Reifegrad und Vertrauensgrad der Cloud-Einführung.
*Entscheidung, welche Ausgangskriterien verwendet werden sollen*
Wählen Sie 2—10 Datenpunkte aus, die Sie für die Priorisierung Ihrer ersten Workloads verwenden möchten. Diese Datenpunkte stammen aus Ihrem anfänglichen Anwendungs- und Infrastrukturbestand (weitere Informationen finden Sie im Abschnitt [Datenerfassung](initiating-data-collection.md)).
Definieren Sie als Nächstes eine Punktzahl oder Gewichtung für jeden möglichen Wert jedes Datenpunkts. Wenn beispielsweise das Umgebungsattribut ausgewählt ist und die möglichen Werte Produktion, Entwicklung und Test lauten, wird jedem Wert eine Bewertung zugewiesen, wobei eine größere Zahl für eine höhere Priorität steht. Obwohl dies optional ist, empfehlen wir, jedem Datenpunkt einen Multiplikationsfaktor für Wichtigkeit oder Relevanz zuzuweisen. Dieser optionale Schritt bietet ein übergeordnetes Unterscheidungsmerkmal, das hervorhebt, was wichtiger ist. Auf diese Weise können Sie die Kriterien bei der Zuordnung von Punktzahlen zu den Werten aufeinander abstimmen.
Basierend auf der Strategie, einfache Anwendungen mit geringem Risiko für die ersten Migrationswellen zu priorisieren, zeigt die folgende Tabelle Beispiele für die Auswahl von Attributen und deren Wertzuweisungen.
| **Attribut (Datenpunkt)** | **Mögliche Werte** | **Ergebnis (0-99)** | **Multiplikationsfaktor für Wichtigkeit oder Relevanz** |
| --- |--- |--- |--- |
| Umgebung | Test | 60 | Hoch (1x) |
| Entwicklung | 40 |
| Produktion | 20 |
| Geschäftliche Kritikalität | Niedrig | 60 | Hoch (1x) |
| Mittel | 40 |
| Hoch | 20 |
| Regulatorischer Rahmen oder Compliance-Rahmen | Keine | 60 | Hoch (1x) |
| FedRAMP | 10 |
| Unterstützung von Betriebssystemen | Bereit für die Cloud | 60 | Mittelhoch (0,8x) |
| In der Cloud nicht unterstützt | 10 |
| Anzahl der Recheninstanzen | 1-3 | 60 | Mittelhoch (0,8x) |
| 4-10 | 40 |
| 11 oder mehr | 20 |
| Migrationsstrategie | Erneut hosten | 70 | Mittel (0,6x) |
| Plattformwechsel | 30 |
| Refaktorieren oder neu strukturieren | 10 |
Achten Sie darauf, dass Sie Attribute auswählen, die als wichtige Unterscheidungsmerkmale zwischen Anwendungen dienen können. Andernfalls führen die Kriterien dazu, dass viele Workloads dieselbe Priorität haben. Nachdem Sie das Modell angewendet haben, empfehlen wir Ihnen, sich die oberen und unteren Rankings anzusehen, um zu sehen, ob Sie damit einverstanden sind. Wenn Sie nicht generell damit einverstanden sind, können Sie die Kriterien, die Sie zur Bewertung der Workloads verwendet haben, erneut überprüfen.
Nachdem Sie ein Ranking erstellt haben, schauen Sie sich die Verteilung der Punktzahlen über das gesamte Portfolio an. Die Punktzahlen selbst spielen keine Rolle. Es ist der Unterschied zwischen den Ergebnissen, der wichtig ist. Sie könnten beispielsweise feststellen, dass die höchste Gesamtpunktzahl 8.000 und die unterste Punktzahl 800 beträgt. Erwägen Sie, die resultierenden Punktzahlen als Histogramm darzustellen, damit Sie überprüfen können, ob Sie eine gute Verteilung haben. Die ideale Verteilung sieht aus wie eine normale Glockenkurve mit einigen Workloads mit sehr hoher Priorität und einigen Workloads mit sehr niedriger Priorität. Die meisten Anwendungen werden sich irgendwo in der Mitte befinden.
Ein weiterer wichtiger Aspekt der anfänglichen Priorisierung ist die Einbeziehung interner Teams oder Geschäftsbereiche, die Interesse daran zeigen, die Cloud als Early Adopters zu nutzen. Dies könnte ein erheblicher Hebel sein, wenn es darum geht, Unterstützung von Unternehmen für die Migration einer bestimmten Anwendung zu erhalten, insbesondere in der Anfangszeit. Wenn dies in Ihrer Organisation der Fall ist, fügen Sie das Geschäftsbereichsattribut in die obige Tabelle ein. Weisen Sie den Geschäftsbereichen, die bereit sind, ihre Bewerbungen einzureichen, eine hohe Punktzahl zu. Die Verwendung des Geschäftsbereichsattributs hilft dabei, diese Anwendungen ganz oben auf der Liste zu platzieren.
Wenn Sie mit der daraus resultierenden Rangfolge einverstanden sind, wählen Sie die fünf bis zehn besten Anwendungen aus. Dies werden Ihre ersten Kandidaten für die Migration Ihrer Bewerbung sein. Verfeinern Sie die Liste, sodass Sie 3—5 Bewerbungen bestätigen. Dies hilft Ihnen, bei der Durchführung einer detaillierten Anwendungsbeurteilung zielgerichtet vorzugehen. Weitere Informationen finden Sie unter [Bewertung priorisierter Anwendungen](prioritized-applications-assessment.md).
## Bestimmung des R-Typs für die Migration
Die Entscheidung über eine Migrationsstrategie für jede Anwendung und die zugehörige Infrastruktur wird Auswirkungen auf die Geschwindigkeit, die Kosten und die Höhe der Vorteile der Migration haben. Es ist wichtig, die Strategie auf der Grundlage einer ausgewogenen Kombination von Faktoren festzulegen, darunter Geschäftsfaktoren, technische Leitprinzipien, Priorisierungskriterien und Geschäftsstrategie.
Manchmal führen diese Faktoren zu widersprüchlichen Ansichten. Zum Beispiel könnten Innovation und Agilität der Haupttreiber für die Migration sein. Gleichzeitig müssen Sie möglicherweise schnell die Kosten senken. Durch die Modernisierung aller betroffenen Anwendungen werden die Kosten auf lange Sicht gesenkt, allerdings sind dafür größere Investitionen im Vorfeld erforderlich. In diesem Fall besteht ein Ansatz darin, Anwendungen mithilfe von Strategien zu migrieren, die weniger Aufwand erfordern, wie z. B. Rehost oder Replatform. Dies kann zu schnellen Effizienzsteigerungen und kurzfristigen Kostensenkungen führen. Investieren Sie die Einsparungen dann wieder in die Modernisierung der Anwendung zu einem späteren Zeitpunkt, um eine weitere Kostensenkung zu erreichen.
Wenn jedoch mit einem vollständigen Rehost aller Anwendungen begonnen wird, verzögert sich der Nutzen der Modernisierung. Der Schlüssel liegt darin, ein Gleichgewicht zwischen den Migrationsstrategien zu finden, sodass geschäftsstrategische Anwendungen bei der Modernisierung priorisiert werden, während andere Anwendungen zuerst neu gehostet oder auf eine neue Plattform umgestellt und dann modernisiert werden können.
*Wie legen Sie eine Migrationsstrategie für Ihre Anwendungen fest?*
In dieser Phase der Bewertung liegt der Schwerpunkt darauf, ein erstes Modell für die Auswahl der Migrationsstrategie zu integrieren. Um die Migrationsstrategie für die ersten Anwendungen zu validieren, verwenden Sie das Modell in Verbindung mit den Geschäftsfaktoren und den Priorisierungskriterien. Die Standardlogik des Entscheidungsbaums hilft Ihnen dabei, die anfängliche Behandlung für den Anwendungsbereich zu bestimmen. In der Baumstruktur sind die komplexesten Ansätze, wie Refactor oder Re-Architect, Ihren strategischen Workloads vorbehalten.
![\[Der in diesem Leitfaden erörterte 6-R-Entscheidungsprozess.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/application-portfolio-assessment-guide/images/6Rs-DecisionTree-baseModel.png)
Eine anpassbare [draw.io-Version](https://github.com/jgraph/drawio-desktop/releases) dieses Diagramms ist im Abschnitt *[Anlagen](#attachments)* verfügbar.
Der erste Schritt zu einem ersten Modell besteht darin, die Geschäftstreiber oben in der Baumstruktur mit den von Ihrer Organisation definierten Faktoren zu aktualisieren. Als Nächstes wenden Sie den Baum auf Anwendungskomponenten und nicht auf Anwendungen als Ganzes an. Im Fall einer dreistufigen Anwendung mit drei Komponenten (Frontend, Anwendungsebene und Datenbank) sollte jede Komponente den Baum unabhängig voneinander übertragen und ihr sollte eine bestimmte Strategie und ein bestimmtes Muster zugewiesen werden. Dies liegt daran, dass Sie in einigen Fällen möglicherweise eine bestimmte Ebene neu hosten oder auf eine andere Plattform umstellen und andere Ebenen umgestalten (neu strukturieren) möchten.
Die unabhängige Zuweisung von Komponenten führt Sie dazu, eine Migrationsstrategie für die zugehörige Infrastruktur zu definieren. Die Infrastrukturstrategie kann dieselbe Strategie sein wie die Anwendungskomponente, die sie unterstützt, oder sie kann sich unterscheiden. Beispielsweise folgt eine Anwendungskomponente, die auf eine neue virtuelle Maschine mit einem neueren Betriebssystem umgestellt wird, der Umplattformstrategie, während die aktuelle virtuelle Maschine, auf der sie gehostet wird, außer Betrieb genommen wird. Die Migrationsstrategie für die Infrastruktur wird auf der Grundlage der für die Anwendungskomponenten ausgewählten Strategie berechnet.
Bevor Sie den Entscheidungsbaum zur Festlegung von Migrationsstrategien verwenden, testen Sie die Logik mit einigen Anwendungen und prüfen Sie, ob Sie mit dem Ergebnis generell einverstanden sind. Der Entscheidungsbaum mit 6 Rs ist ein Leitfaden, der nicht die Analyse ersetzt, die zur Feststellung seiner Richtigkeit erforderlich ist. Die Baumlogik gilt möglicherweise nicht für bestimmte Fälle. Behandeln Sie diese Fälle als Ausnahmen und fahren Sie fort, die durch den Baum getroffene Entscheidung außer Kraft zu setzen, indem Sie die Gründe für die Überschreibung dokumentieren, anstatt die Baumlogik zu ändern. Dadurch werden mehrere Versionen der Entscheidungsstruktur vermieden, deren Verwaltung schwierig werden könnte. Allgemein gilt, dass der Baum für mindestens 70 bis 80 Prozent der Workloads gültig sein sollte. Für den Rest wird es Ausnahmen geben. Jegliche Anpassungen der Baumlogik in dieser Phase der Bewertung sollten sich auf die Erstellung eines ersten Modells konzentrieren. Weitere Iterationen und Verfeinerungen werden in späteren Phasen erfolgen, z. B. bei der [Portfolioanalyse und der Migrationsplanung](portfolio-analysis-migration-planning.md).
## Anlagen
[attachment.zip](samples/attachment.zip)
# Erstellung eines richtungsweisenden Geschäftsszenarios
Stakeholder aus dem gesamten Unternehmen sollten das Geschäftsszenario für die Transformation bei jedem Schritt verstehen und sich darauf einlassen.
In der Anfangsphase ist es wichtig, schnell den potenziellen Nutzen eines Migrationsprogramms aufzuzeigen, sodass Sie sich die Ressourcen sichern können, die für die Planung und Einrichtung des Programms erforderlich sind. Das vorausschauende Geschäftsszenario ist so konzipiert, dass mit den begrenzten Daten, die frühzeitig erfasst werden können, genügend Vertrauen in die Erzielung eines überzeugenden Geschäftswerts geschaffen werden kann.
Nach der Einrichtung des Programms wird das Geschäftsszenario weiterentwickelt. Der detaillierte Fall bietet eine höhere Genauigkeit, ein vollständigeres Bild des Programmwerts und einen Einblick in die Planungsprioritäten. Es definiert und quantifiziert die geplanten Geschäftsergebnisse, auf die sich das Unternehmen einlässt, und legt die Ausgangsbasis fest, anhand derer Ihr Program Governance Office das Programm dann steuern und seine Erfolge messen kann.
## Festlegung des Umfangs des zielgerichteten Geschäftsszenarios
Ein zielgerichtetes Geschäftsszenario wird in der Regel schnell, innerhalb von 2—4 Wochen, erstellt. Es muss genügend Vertrauen schaffen, damit Sie die Ressourcen sichern können, um das Kernteam zusammenzustellen, bei Bedarf AWS Partner hinzuzuziehen und zumindest die [priorisierten Phasen der Anwendungsbeurteilung](prioritized-applications-assessment.md), [Portfolioanalyse und Migrationsplanung](portfolio-analysis-migration-planning.md) abzuschließen.
In der Regel werden zielgerichtete Geschäftsszenarien, die Portfoliomigrationen unterstützen, wie folgt erstellt:
+ Ein einfacher**** Vergleich *der Gesamtbetriebskosten (TCO)* zwischen der Ist-Infrastrukturlandschaft und der Architektur nach der Migration. AWS-Service Der Vergleich zeigt den Unterschied zwischen den erwarteten Ausführungsraten für ein bestimmtes Workload-Volumen.
+ Ein Geschäftsszenario****, das den Nettobarwert (NPV), die Kapitalrendite (ROI), die Amortisationszeit, die modifizierte interne Rendite (MIRR) und die Cashflow-Analysen über 3 bis 5 Jahre für die Umstellung auf die Umstellung auf die Umstellung auf die Migration inklusive der Migrationskosten im Vergleich zur Beibehaltung des Ist-Zustands aufzeigt. AWS
Der Anwendungsbereich eines zielgerichteten Geschäftsszenarios ist in der Regel auf einen der folgenden Bereiche beschränkt:
+ Ein Vergleich der Kosten für die Infrastrukturtechnologie
+ Ein Vergleich der Kosten für Infrastrukturtechnologie und Betrieb
Generell gilt: Je größer das Portfolio, desto weniger ausgeklügelt muss der Fall sein. Dies liegt daran, dass umfassendere Annahmen getroffen werden können, ohne das Ergebnis wesentlich zu beeinflussen. Bei einem kleineren Portfolio wird jede Änderung größere Auswirkungen haben, sodass mehr Details erforderlich sind.
Erstellen Sie zunächst den Vergleich der Basiskosten für die Infrastruktur. Entscheiden Sie dann, ob der Vergleich überzeugend genug ist, bevor Sie fortfahren. In der Regel weisen Portfolios mit mehr als 400 Servern ein positives Geschäftsszenario auf, wenn es allein um die Senkung der Infrastrukturkosten innerhalb von 3 Jahren oder um 250 Server innerhalb von 5 Jahren geht, obwohl dies variieren kann. AWS Bei kleineren Portfolios sind möglicherweise detailliertere Angaben erforderlich.
Umgekehrt ist es in dieser Phase selten sinnvoll, andere Komponenten des geschäftlichen Nutzens zu untersuchen, wie z. B. den Nutzen, der sich aus einer verbesserten Ausfallsicherheit oder Geschäftsflexibilität ergibt, es sei denn, der gesamte Migrationsumfang beträgt weniger als etwa 5 Workloads oder 50 Server.
## Konzentrieren Sie sich auf Werttreiber
Beim Vergleich der Gesamtbetriebskosten für Infrastrukturtechnologie wird ein Modell der Ist-Infrastrukturkosten mit einem Basismodell der Materialliste verglichen, die AWS-Service erforderlich ist, um Ihre Workloads mit gleicher Leistung und Verfügbarkeit auszuführen. Es können viele Optimierungen vorgenommen werden. In dieser Phase liegt der Schwerpunkt jedoch auf der folgenden Liste, da sie einfacher zu bewerten sind und in der Regel zu Einsparungen bei den Gesamtbetriebskosten von etwa 30 Prozent führen, was ausreicht, um voranzukommen:
+ **Rechenelastizität** — Ordnen Sie Server, deren Nutzung nicht zu 100 Prozent beträgt, wie Entwicklungs- oder UAT-Server, auf denen 8 x 5 (24 Prozent Nutzung), 10 x 5 (30 Prozent) oder 10 x 6 (36 Prozent) ausgeführt werden, und Disaster Recovery (DR) -Server, die zu 2 Prozent laufen, On-Demand-Diensten zu, die nur bei Nutzung in Rechnung gestellt werden.
+ **Beschaffung mit Sparplan — Planen Sie** die Beschaffung von Produktionsservern und anderen Servern mit hoher Auslastung (mehr als 36 Prozent) mit einem geeigneten Sparplan, um die Kosten um bis zu 75 Prozent zu senken. Zu den Optionen gehören ein- und dreijährige Verpflichtungen mit unterschiedlichen Vorauszahlungen, um größere Rabatte zu sichern.
+ **Zombies entfernen** — Identifizieren Sie Server mit einer CPU-Auslastung von weniger als 2 Prozent, von denen Sie bestätigen können, dass sie nicht mehr benötigt werden, und entfernen Sie sie aus der Kostenanalyse.
+ **Richtige Berechnung — Verwenden** Sie Zeitreihendaten zur CPU- und Speicherauslastung, um für jeden Server die benötigte Rechenleistung und den benötigten Arbeitsspeicher zu ermitteln. Wählen Sie dann die passende Amazon Elastic Compute Cloud (Amazon EC2) -Instance aus.
+ **Lizenzierung für relationale Datenbankmanagementsysteme (RDBMS)** — Beurteilen Sie Ihre RDBMS-Lizenzanforderungen nach der Berechnung der richtigen Größe auf Ihren Datenbankservern, vergleichen Sie Bring Your Own License (BYOL) und Procuring-Lizenz von und erkunden Sie das Potenzial von AWS Amazon Relational Database Service (Amazon RDS) zur Steigerung der Einsparungen.
+ **Speicher — Passen** Sie die Größe des insgesamt benötigten Speichervolumens an und ermitteln Sie den IOPS-Bedarf (Operations per Second) im gesamten Portfolio. input/output Ermitteln Sie, wie viel davon mit unterschiedlichen SLAs Kosten in Objektspeicher verschoben werden kann.
## Datenbedarf
Die Tabelle unter [Grundlegendes zu den Datenanforderungen für die Erstbeurteilung](understanding-initial-assessment-data-requirements.md) zeigt, welche Daten für die Erstellung der einzelnen Teile eines zielgerichteten Geschäftsszenarios erforderlich sind und ob es sich dabei um obligatorische oder optionale Daten handelt.
Um die Fallstudie zu erstellen, benötigen Sie die Infrastruktur-Teilmenge der ursprünglichen Planungsdaten sowie die Kostendaten. Die Entscheidung, wie die einzubeziehende Infrastruktur identifiziert werden soll, hängt von Ihrem Geschäftsziel ab:
+ Wenn das Ziel des Programms darin besteht, bestimmte Anwendungen zu migrieren und zu modernisieren, sollten Sie das Infrastrukturportfolio auf der Grundlage der Anforderungen der Anwendungen aufbauen und dabei die gemeinsam genutzte Infrastruktur berücksichtigen.
+ Wenn das Ziel des Programms auf die Infrastruktur ausgerichtet ist, z. B. die Migration aus einem Rechenzentrum, dessen Mietvertrag ausläuft, ist für Vergleiche der Gesamtbetriebskosten der Infrastruktur keine Anwendungszuweisung erforderlich.
Daten, die als optional gekennzeichnet sind (z. B. CPU- und Speicherspitzenauslastung bei Servern), können in der Regel durch Standard-Benchmarkwerte ersetzt werden. Sie können dies mit einem AWS Partner oder AWS Professional Services besprechen. Oder Sie können die Werte aus Datenpunkten extrapolieren, die in einem Teil Ihres Portfolios verfügbar sind (z. B. Daten, die von einem Hypervisor erfasst wurden). Je größer das Portfolio, desto genauer ist dies.
## Vergleiche der Gesamtbetriebskosten der Gebäudeinfrastruktur
Tools sind für die Erstellung von Vergleichen der Gesamtbetriebskosten der Infrastruktur von entscheidender Bedeutung. [AWS Professional Services](https://aws.amazon.com/professional-services/) oder ein [AWS Partner](https://aws.amazon.com/migration/partner-solutions/) können Ihnen bei allen möglichen Fällen weiterhelfen, vor allem, wenn Sie planen, sie mit der Unterstützung des umfassenderen Migrationsprozesses zu beauftragen.
Es stehen Tools für die folgenden Aufgaben zur Verfügung:
+ Sammeln Sie Inventardaten.
+ Sammeln Sie Nutzungsdaten.
+ Stellen Sie genaue Benchmarking-Daten zu den Infrastrukturkosten bereit.
+ Identifizieren und entfernen Sie Zombies.
+ Machen Sie Einschätzungen mit der richtigen Größe.
+ Empfehlen Sie Kaufoptionen.
+ Vergleichen Sie die Optionen für die Softwarelizenzierung.
+ Erstellen Sie einfache grafische Cashflow-Analysen.
[Migration Evaluator](https://aws.amazon.com/migration-evaluator/) von AWS ist eine Option. Es bietet all diese Funktionen als **kostenloser verwalteter Service. Sie** können den Migration Evaluator über Ihren AWS Account Manager oder Ihren AWS Migrationskompetenzpartner anfordern oder indem Sie [eine Anfrage](https://pages.awscloud.com/Migration-Evaluator-request.html) online einreichen. Der Migration Evaluator wurde speziell als Einzellösung konzipiert, um schnell Vergleiche der Gesamtbetriebskosten der Infrastrukturtechnologie zu erstellen.
Die wichtigsten Vorteile:
+ Kostenlos
+ Erkennung von Inventardaten ohne Agenten oder manuelle Konfiguration von Inventardaten, wenn die toolgestützte Erkennung eingeschränkt ist
+ Spezieller Support zur Unterstützung bei der Bereitstellung, Konfiguration, Datenerfassung und Erstellung eines Basisszenarios oder eines zielgerichteten Geschäftsszenarios
+ Bequemer SaaS-Betrieb, die Datenerfassung kann jedoch vollständig innerhalb des Kundennetzwerks durchgeführt werden, um das Scrubbing vor dem Laden in die Analyse-Engine zu unterstützen
+ Starke Unterstützung für Microsoft License Right-Sizing
+ Vollständige Datenexportfunktionen
Wichtigste Einschränkungen:
+ Bewertet nur Server mit x86-Architektur (Windows und Linux)
+ Eingeschränkte Optionen zur Konfiguration oder Kalibrierung von Benchmark-Kostendaten
+ Keine Unterstützung für die Kostenoptimierung von Modellierungsvorgängen
+ Keine Unterstützung für die Modellierung von Migrationskosten
+ Keine direkte Unterstützung für die Erstellung von Geschäftsszenarien, die über Vergleiche der Gesamtbetriebskosten hinausgehen
Wenn Sie sich dafür entscheiden, ein kommerzielles Discovery-Tool für Portfolioerkennungs- und Analysefunktionen wie Anwendungsstapel und Erkennung von Interdependenzen zu verwenden, bietet es in der Regel auch einen Vergleich der Gesamtbetriebskosten der Infrastruktur. Hinweise zur Verwendung von Tools zur Portfolioerkennung und -bewertung finden Sie unter [Bewertung des Bedarfs an Tools zur Portfolioerkennung](understanding-initial-assessment-data-requirements.md#discovery-tooling). Eine Übersicht und ein Vergleich der wichtigsten Funktionen der marktführenden Tools finden Sie unter Tools für die Migration von [Discovery, Planning und Recommendation](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/).
## Optimierung der Betriebskosten einbauen
Die Verbesserung der Produktivität des IT-Betriebs leistet bei Migrationen häufig einen erheblichen Wertbeitrag. Laut dem Whitepaper [Fostering Business and Organizational Transformation to Generate Business Value with Amazon Web Services steigt die Produktivität der IT-Mitarbeiter nach der Migration durch die Migration um](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) durchschnittlich 62 Prozent. AWS Bei der Dimensionierung und der Berücksichtigung dieser Vorteile im direkten Vergleich gibt es jedoch zwei Herausforderungen.
Erstens erfordert die Bewertung des gesamten Spektrums der Produktivitätssteigerungen eine umfangreiche Datenerhebung und ist für den [detaillierten Geschäftsszenario](detailed-business-case.md) besser geeignet. Diese Herausforderung kann gelöst werden, indem man sich auf einige wenige Elemente konzentriert, die mit einfachen Benchmark-Daten leichter bewertet und dimensioniert werden können, die aber dennoch erhebliche Vorteile bieten.
Zweitens kann die Konzentration auf Produktivität als Quelle der Kostensenkung bei wichtigen Kundenakteuren und Programmmitgliedern zu Besorgnis und Negativität führen. Sorgen Sie dafür, dass Sie Klarheit darüber schaffen, wie der Nutzen realisiert werden soll und was das für die betroffenen Menschen bedeutet. Solche Probleme können vermieden werden, indem klargestellt wird, dass dadurch nur die Rollen des Teams gestärkt werden:
+ Das Migrationsprogramm sieht vor, interne Betriebsmitarbeiter weiterzuentwickeln und ihnen neue Rollen zuzuweisen, z. B. den Zusammenschluss von DevSecOps Teams beim Aufbau von Infrastrukturen wie Codeautomatisierungen und Testautomatisierungen, die das Wachstum des Teams vorantreiben.
+ Der Vorteil kann durch die Neugestaltung und Anpassung von Outsourcing-Verträgen für den Betrieb realisiert werden, sodass sich die internen Mitarbeiter stärker auf höherwertige Aktivitäten konzentrieren können
Gehen Sie wie folgt vor, um dieses Geschäftsszenario auf der Grundlage der zu berücksichtigenden betrieblichen Transformationen zu erstellen:
+ Wenn Sie bereits über ein internes Betriebsteam verfügen, sollten Sie die Teammitglieder weiterbilden und die erwartete Produktivitätssteigerung aufzeigen.
+ Alternativ können Sie von Ihrer aktuellen Betriebslösung zu AWS Managed Services (AMS) oder zu einem alternativen Managed-Services-Angebot eines AWS Partners migrieren.
Für die erste Transformation empfehlen wir Folgendes, um eine konservative finanzielle Einschätzung der Produktivitätssteigerung zu erhalten, die in diesem Fall berücksichtigt werden kann:
1. Konzentrieren Sie sich speziell auf die Produktivität des Serververwaltungsbetriebs. Sie macht in der Regel einen erheblichen Teil des betrieblichen Aufwands aus, lässt sich leichter beurteilen und kann später leichter verifiziert werden.
1. Berechnen Sie den Personalbedarf anhand von Benchmarks für die Anzahl der Server, die von jedem Vollzeitbeschäftigten (FTE) verwaltet werden können. Vor Ort liegt diese Zahl bei etwa 150 Servern. Auf AWS, es sind ungefähr 400 Server.
1. Wenden Sie diese Metriken auf die Anzahl der lokalen Server im Vergleich zur Anzahl der EC2-Instances an.
1. Multiplizieren Sie die Zeitersparnis mit einem kombinierten Kostensatz für das gesamte Betriebsteam.
Anschließend können Sie Ihre Ergebnisse mit beiden Ansätzen überprüfen, indem Sie sicherstellen, dass das Ergebnis die in der folgenden Tabelle angegebenen durchschnittlichen Produktivitätssteigerungen je Rolle nicht wesentlich übersteigt (Daten stammen aus dem IDC-Whitepaper [Fostering Business and Organizational Transformation to Generate Business Value with](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) Amazon Web Services).
| **Rolle** | **Steigerung der Effizienz** |
| --- |--- |
| Verwaltung der IT-Infrastruktur | 62% |
| IT-Unterstützung | 59% |
| Application Management | 43% |
| Datenbankverwaltung | 19% |
| Anwendungsentwicklung | 25 % |
Bei der zweiten Transformation können Sie die Einsparungen bei den Betriebskosten addieren, indem Sie die aktuellen Gesamtkosten für Betrieb und Support für das im Leistungsumfang enthaltene Portfolio direkt mit den Kosten für den betrachteten verwalteten Service vergleichen.
Um die Kosten für den verwalteten Service zu ermitteln, teilen Sie Ihrem AWS Kundenbetreuer oder einem beliebigen [AWS Managed Services Partner](https://aws.amazon.com/managed-services/partners/) Ihre vorgeschlagene AWS Stückliste, die von Ihnen gewählte Servicestufe (Plus oder Premium) und Ihr AMS-Paket (AMS Accelerate oder AMS Advanced) mit. Auf diese Weise erhalten Sie die Gesamtkosten der Managed Services für die folgenden AWS-Service Komponenten der transformierten Lösung. In ähnlicher Weise könnten Sie Preise von einem AWS Partner erhalten, der sein eigenes Managed-Services-Paket auf der Grundlage seiner eigenen Parameter anbietet.
## Erweiterung auf ein voll ausgerichtetes Geschäftsszenario
Im Allgemeinen sollten Sie bei der Zusammenstellung eines vollständigen Geschäftsszenarios einen Vergleich der Gesamtbetriebskosten mit oder ohne das Element IT-Produktivität erstellen und alle Migrations- und Modernisierungskosten abschätzen. Erstellen Sie dann einen Cashflow, der zwei Szenarien abdeckt migrate-and-modernize und nicht. t-migrate-and-modernize
Der einfachste Fall ist die Erstellung eines einzigen Paares von Szenarien, wobei das t-migrate-and-modernize Szenario „Nicht“ Ihre aktuelle Situation darstellt und das migrate-and-modernize Szenario die folgenden Merkmale aufweist:
+ Kein Wachstum oder Rückgang des Transaktionsvolumens, der Rechen- oder Netzwerkkapazität
+ Stetiges Wachstum der Speicheranforderungen bei geringem Volumen
+ Quality-of-service Funktionen (wie Verfügbarkeit, Haltbarkeit, Durchsatz und Leistung), die den Fähigkeiten des vorhandenen Systems entsprechen
Für alle Portfolios, mit Ausnahme sehr kleiner Portfolios, passt dies gut zu dem Ziel, ein richtungsweisendes Beispiel zu entwickeln. Es erweist sich als ausreichend nützlich, um schnell das Mandat zu erhalten, voranzukommen.
Bei kleineren Portfolios kann es sinnvoll sein, zwei t-migrate-and-modernize Szenarien hinzuzufügen migrate-and-modernize und diese zu vermeiden, die weitere Aspekte des Mehrwerts der Cloud-Migration aufzeigen, wie zum Beispiel:
+ Eine Mischung aus moderaten und hohen Kapazitätswachstumsanforderungen für alle Workloads, bei denen dieses Wachstum erwartet wird
+ Einbeziehung verbesserter Ausfallsicherheit, z. B. Hochverfügbarkeit, DR und Fehlertoleranz
+ Verbesserte globale Leistung mit Edge-Computing, Content Delivery Network (CDN) und Datenbankreplikation in mehreren Regionen.
+ Jede andere spezifische Verbesserung der Servicequalität, die Sie für das Programm zu einer Geschäftspriorität erklärt haben
Stellen Sie für diese Szenarien sicher, dass die Kosten und die Auswirkungen auf den Cashflow, die sich aus der Aktualisierung der aktuellen Nicht-Cloud-Infrastrukturarchitektur ergeben, um sie an die neue Spezifikation anzupassen, genau geschätzt werden. Der direkteste Weg, diese Schätzung zu erhalten, besteht darin, ein Angebot von einem Systemintegrator anzufordern, insbesondere, wenn dieser auch ein AWS Beratungspartner mit Migrationskompetenz ist, der Sie sowohl bei den Szenarien als auch bei den migrate-and-modernize anderen Szenarien unterstützen kann. t-migrate-and-modernize
Stellen Sie für jedes Szenariopaar einen Koffer zusammen, der Folgendes umfasst:
+ Die Kosten des t-migrate-and-modernize Don'-Szenarios. Im einfachsten Fall beinhaltet dies:
+ Die Gesamtbetriebskosten im Rahmen des Geschäftsszenarios für die aktuelle Infrastrukturkonfiguration
+ Periodischer Anstieg des Rechen-, Speicher- und Netzwerkdatenverkehrs
+ Die Kosten des migrate-and-modernize; -Szenarios, einschließlich:
+ Einrichtung des Programms, einschließlich detaillierter Erkennung, Migrationsplanung, detaillierter Entwicklung von Geschäftsszenarien, Aufbau und Weiterbildung des Kernteams, Einrichtung einer landing zone, falls noch nicht vorhanden, sowie Einrichtung von Sicherheitsmanagement und Betriebsintegration für migrierte Workloads
+ Die Kosten für die Migration und Modernisierung von Workloads
+ Die Kosten für die Migrationsinfrastruktur, einschließlich Netzwerkverbindungen, Datenmigrationsdienste wie [AWS Snowball Edge](https://aws.amazon.com/snowball/)und und [AWS DataSync](https://aws.amazon.com/datasync/), sowie die AWS Nebenkosten für die Architektur, die während des Migrationsprozesses selbst benötigt werden (z. B. für Tests)
+ Der Anstieg der AWS Betriebskosten im Laufe der Migration, wenn Waves live geht, und die Senkung der bestehenden Infrastrukturkosten, wenn diese durch Basisdienste ersetzt und außer Betrieb AWS genommen wird
+ Die Stilllegungskosten und die Abschreibungen für verloren gegangene Anlagen
## Schätzung der Einrichtung des Migrations- und Modernisierungsprogramms
Um ein erfolgreiches Programm einzurichten, müssen Sie möglicherweise eine Reihe grundlegender Aktivitäten durchführen, um die Basisfunktionen und den detaillierten Plan zu entwickeln, falls dies noch nicht geschehen ist. Zu diesen grundlegenden Aktivitäten gehören die folgenden:
1. Durchführung einer detaillierten Portfolioerkennung, Migrationsplanung und detaillierter Entwicklung von Geschäftsszenarien, wie im Abschnitt [Portfolioanalyse und Migrationsplanung](portfolio-analysis-migration-planning.md) beschrieben, sowie Dokumentation der Kosten aller verwendeten Discovery-Tools.
1. Aufbau eines Kernteams für Cloud-Geschäft und Technik und Entwicklung interner Fähigkeiten durch Schulung und Einstellung. Identifizieren Sie die Mitglieder der IT-Organisation, die geschult werden müssen, und weisen Sie jeder Person ein Schulungsbudget zu.
1. Einrichtung einer [landing zone](https://aws.amazon.com/solutions/implementations/aws-landing-zone/) und deren Konfiguration zur Unterstützung der von Ihnen benötigten Kosten-, Betriebs- und Sicherheits-Governance-Funktionen.
AWS Beratungspartner können Ihnen bei der Erstellung von Schätzungen für die Punkte 1 und 3 behilflich sein.
*Schätzung der Migrations- und Modernisierungskosten*
Um die Ziele eines zielgerichteten Geschäftsszenarios zu erreichen und aufzuzeigen, dass *gerade genug* kommerzielles Potenzial für die nächste Phase besteht, sollten Sie die Schätzung der Migrations- und Modernisierungskosten so einfach wie möglich halten.
Zu diesem Zweck empfehlen wir, dass Sie sich bei der Vorbereitung eines zielgerichteten Geschäftsszenarios auf die Anwendungen konzentrieren, die in die folgenden Migrationsstrategien fallen:
+ Ausmustern
+ Beibehalten
+ Umziehen
+ Erneut hosten
+ Plattformwechsel
+ Rückkauf
In der Regel können etwa 70 Prozent der Workloads neu gehostet, verlagert oder auf eine andere Plattform umgestellt werden, und weitere 5 Prozent können außer Betrieb genommen werden. Bei der Bewertung der Anwendungen anhand der Migrationsstrategie geht es in der Regel um den Kern der Kostensenkung.
**Die Schätzung der Kosten für das Refactoring oder die Neuarchitektur kann komplex sein.** Es ist nicht praktikabel, dies innerhalb des Zeitrahmens zu versuchen, der für die Erstellung eines richtungsweisenden Geschäftsszenarios vorgesehen ist. Wie bereits unter [Bestimmung des R-Typs für die Migration](prioritization-and-migration-strategy.md#migration-r-type) beschrieben, sollten Sie in Ihrer ersten Phase der Migration und Modernisierung Rehost-, Relocate- oder Replattform-Strategien in Betracht ziehen. Diese R-Strategien werden wahrscheinlich die anfängliche Amortisation beschleunigen, das Implementierungsrisiko verringern und das Geschäftsszenario kurzfristig verbessern. Außerdem ist es für Ihre Anwendungsteams wesentlich einfacher, Anwendungen zu modernisieren, die in der Umgebung ausgeführt werden, als Anwendungen, die nicht in der AWS Umgebung ausgeführt werden. [Schätzungen für das Refactoring (Neuarchitektur) bestimmter Anwendungen lassen sich am besten erst dann hinzufügen, wenn der detaillierte Geschäftsszenario erstellt ist.](detailed-business-case.md)
*Schätzung des Migrationsaufwands nach Strategie*
Jede Migration ist anders. Bevor Sie Budgets oder Pläne festlegen, sollten Sie von dem Team, das für das Projekt verantwortlich sein wird, Schätzungen der Arbeitslast für die Migrationsaktivitäten erstellen, unabhängig davon, ob es sich dabei um Ihre internen Anwendungsteams, AWS Professional Services oder eine AWS Partnerorganisation handelt.
Als Hilfestellung dient die folgende Tabelle als Richtschnur für die Aufwandsbereiche der verschiedenen Behandlungsmethoden. Bei diesen Bandbreiten wird davon ausgegangen, dass ein medium-to-large Portfolio migriert wird und dass das Migrationsteam geschult und erfahren ist. Bei kleinen Portfolios ist es am besten, das für die Migration verantwortliche Team die Schätzung erstellen zu lassen, auch wenn es sich um einen konkreten Fall handelt.
| Migrationsstrategie | Prozess der Schätzung | Elemente | Stunden der Person | Stunden der Person |
| --- |--- |--- |--- |--- |
| Beibehalten | Tun Sie nichts, ohne Kosten, ohne Vorteile und ohne Reduzierung der Technologieverschuldung. | – | – | – |
| Ausmustern | Kalkulieren Sie die Außerbetriebnahme der verwendeten Hardwareausrüstung, falls vorhanden. | – | – | – |
| Umziehen | Schätzen Sie das Kopieren der Arbeitslast innerhalb der VMware Verwendung von VMware Tools ab. Dazu gehören das Kopieren der Daten, Rauchtests zur Überprüfung und jegliche Außerbetriebnahme der Hardware. Der Aufwand für die Verlagerung VMs ist in der Regel geringer als bei Rehost-Mustern mit geringer Komplexität. | – | – | – |
| Rehosten | Schätzen Sie das Kopieren der Arbeitslast und der Daten mit einer Image-Kopie, Smoke-Tests, Hochverfügbarkeits- (HA) - und Disaster Recovery (DR) -Tests (soweit angemessen) für Produktionsserver sowie etwaige Außerbetriebnahme von Hardware ab. Die bewährte Methode ist die Verwendung von Tools wie [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/). Unterteilen Sie Workloads in niedrige, mittlere und hohe Komplexität, basierend auf Faktoren wie der Tatsache, ob eine Datenbank oder eine andere Infrastruktursoftware ausgeführt wird, der Datenbankkomplexität, ob sie geclustert ist, der Integrationskomplexität und den Datenmengen. | Aufwand pro Anwendung pro Server | Migration | HA/DR-Test |
| Niedrig | 10—14 | 3—5 |
| Mittel | 16—24 | 4—6 |
| Hoch | 26—38 | 8—12 |
| Plattformwechsel | Bei Migrationen auf neue Plattformen, die Upgrades auf das Betriebssystem oder die RDBMS-Version beinhalten, nehmen Sie den Kostenvoranschlag für einen Rehost und fügen Sie Zeit hinzu, um einen Rebuild- und Smoke-Test auf der neuen Plattform durchzuführen. Falls die Neuplattform eine Änderung der Technologie der Plattform beinhaltet, rechnen Sie mit der zusätzlichen Zeit für die Verwendung der Konvertierungstools wie und und und einen umfassenderen Anwendungstest. [AWS Schema Conversion Tool[AWS Database Migration Service](https://aws.amazon.com/dms/)](https://aws.amazon.com/dms/schema-conversion-tool/) Ein Beispiel für eine Änderung der Technologie ist die Migration weg von einer proprietären kommerziellen Datenbank zu einem Open-Source-Ersatz. | Aufwand pro App pro Server | Version höher | Technologischer Wandel |
| Niedrig | 1—3 hinzufügen | Fügen Sie 10—15 hinzu |
| Mittel | Fügen Sie 2—5 hinzu | Fügen Sie 20—30 hinzu |
| Hoch | Fügen Sie 4—8 hinzu | 40—60 hinzufügen |
| Rückkauf | Schätzen Sie die Datenextraktion, -transformation und das Hochladen in den neu erworbenen SaaS-Dienst als Ersatz und etwaige Außerbetriebnahme von Hardware ab. | – | – | – |
*Schätzung der Kosten für die Migrationsinfrastruktur*
Geben Sie Schätzungen für die Infrastruktur an, die Sie im Laufe der Migration nutzen werden. In der Regel umfassen diese Schätzungen:
+ Ein Budget für Konnektivitäts- und Datenaustauschdienste für die Arbeitslast und die Datenmigration von der aktuellen Umgebung nach AWS
+ Ein Budget für die AWS-Services (insbesondere Rechen- und Speicherressourcen), die für das Hosten der migrierten Workloads während der Migrations-, Test- und Umstellungsprozesse benötigt werden
+ Erhöhung der AWS Betriebskosten nach Abschluss jeder Migrationswelle
+ Die Kosten für die Außerbetriebnahme der bestehenden Infrastruktur, auf der die migrierten Workloads nicht mehr ausgeführt werden können
Untersuchen Sie beim Datenaustausch Ihr gesamtes Datenvolumen und bewerten Sie die Machbarkeit der Nutzung von Netzwerken. Wenn Sie im Voraus einen [AWS Direct Connect](https://aws.amazon.com/directconnect/)Link oder [Site-to-Site VPN](https://aws.amazon.com/vpn/)eine Verbindung AWS zu einem Punkt in Ihrem WAN für den operativen Einsatz nach der Migration bereitgestellt haben, können Sie diese Ressource bis zu ihrem Dienstkontingent nutzen.
Wenn Ihre Netzwerkkapazität nicht ausreicht, ist eine kurzfristige Erhöhung der Internetbandbreite mit einem virtuellen privaten Netzwerk (VPN) oft eine äußerst kostengünstige Lösung. Wenn nicht, bieten AWS Medienaustauschgeräte wie [AWS Snowball Edge](https://aws.amazon.com/snowball/)und [AWS Snowball Edge](https://aws.amazon.com/snowcone/)bieten in den meisten Fällen Lösungen AWS-Regionen. Bei der Migration sehr großer Datenmengen sollten Sie auch das Budget einplanen [AWS DataSync](https://aws.amazon.com/datasync/), was die Zuverlässigkeit erhöht und Übertragungen unabhängig von den verwendeten Medien beschleunigen kann.
Die Modellierung des Hochlaufs von AWS Dienstleistungen und des Abbaus der bestehenden Infrastruktur ist wichtig für die Cashflow-Analyse des Geschäftsszenarios. Zum jetzigen Zeitpunkt ist es unwahrscheinlich, dass Sie über einen Plan verfügen, mit dem Sie genau bestimmen können, wann die Kosten anfallen werden. Wir empfehlen Folgendes:
+ Erhöhung der Kosten AWS bei gleichbleibender Geschwindigkeit während der Migration.
+ Senkung der Kosten für die bestehende Infrastruktur, die Sie über den gleichen Zeitraum stilllegen möchten, in gleichbleibendem Tempo.
Beginnen Sie mit der Erhöhung der AWS Kosten 1—2 Monate vor dem Abbau der bestehenden Infrastruktur. Das bedeutet, dass das AWS Programm für jede Welle 1 Monat lang genutzt werden kann, um die Migration durchzuführen. Es beinhaltet Zeit für Tests und zusätzliche Zeit für die Durchführung der Stilllegungsarbeiten, die erforderlich sind, damit keine Kosten für die ersetzte Infrastruktur anfallen.
*Schätzung der Stilllegungskosten*
Die Außerbetriebnahme von Geräten, die nicht weiterverwendet werden können, und ihre legale und umweltfreundliche Entsorgung können geringe Kosten verursachen. Bei einem zielgerichteten Geschäftsszenario sind die Kosten für die Abschreibung des verbleibenden Buchwerts der ersetzten Anlagen jedoch in der Regel die einzige potenziell wesentliche Summe.
Für ein direktionales Geschäftsszenario empfehlen wir, dass Sie wie folgt vorgehen:
+ Überprüfen Sie Ihre Anlagenliste.
+ Identifizieren Sie diejenigen, die außer Betrieb genommen werden würden.
+ Um die Abschreibung zu verringern, sollten Sie prüfen, welche Möglichkeiten bestehen, Geräte umzustellen, sodass neuere Geräte auf der Liste als Ersatz für ältere, stärker abgeschriebene Anlagen verwendet werden können.
+ Beurteilen Sie den future Buchwert der Anlagen, die zu diesem Zeitpunkt stillgelegt würden.
+ Beziehen Sie dies in die Migrationskosten der Stilllegung ein.
*Zusammenstellung und Anpassung des vollständigen Geschäftsszenarios*
Nachdem Sie alle Kosten für jedes Szenariopaar erstellt haben, erstellen Sie für jedes Szenario eine abgezinste Kapitalflussrechnung und stellen diese grafisch dar. Wir empfehlen, zielgerichtete Geschäftsszenarien für den gleichen Zeitraum wie den Hardware-Aktualisierungszyklus zu entwickeln. Für Server, Speicher und Netzwerkgeräte beträgt dieser Zeitraum in der Regel 5 Jahre. Wenn Sie denselben Zeitraum wie der Hardware-Aktualisierungszyklus verwenden, sind die Kosten für genau eine Aktualisierung in den Ist-Kosten für jedes Szenario enthalten.
Berechnen Sie anschließend die wichtigsten Finanzkennzahlen, die Sie benötigen, um die Genehmigung für den Übergang zur nächsten Phase des Programms zu erhalten. In der Regel schließen wir Folgendes ein:
+ Der aktuelle Nettowert (NPV), um den absoluten Wert der bewerteten Kostensenkungen und Produktivitätssteigerungen abzuschätzen
+ Die Amortisationszeit in Monaten, um zu überprüfen, ob die Renditen ausreichend schnell eintreffen
+ Der abschließende Runrate-Vergleich, um zu überprüfen, ob durch den Prozess im Laufe der Laufzeit genügend Kosten eingespart werden
+ Anhand der Kapitalrendite (ROI) und der modifizierten Investitionsrendite (MIRR) lässt sich die relative finanzielle Leistung des Programms im Vergleich zu anderen Kapitalanforderungen beurteilen, denen Ihr Unternehmen möglicherweise Priorität einräumt
Ermitteln Sie anhand der ersten Fallstudie, ob aufgrund der erwarteten finanziellen Leistung Verbesserungen erforderlich sind, wie in den folgenden Beispielen dargestellt:
+ Wenn die Amortisation zu langsam ist, sollten Sie Optionen zur Beschleunigung und Senkung der Migrationskosten in Betracht ziehen, z. B. die folgenden:
+ Nutzen Sie AWS Partner oder AWS Professional Services, um die verfügbaren Ressourcen zu erweitern und die Migration von Workloads mit grundlegenderen Mustern weiter zu parallelisieren.
+ Vergleichen Sie bei laufenden Workloads die VMware Verlagerungsstrategie mit der Rehost- oder Replattform-Strategie, zumindest in der Anfangsphase. Mit der Umzugsstrategie können die Migrationskosten gesenkt und die Migrationsgeschwindigkeit erhöht werden.
+ Sofern technisch machbar, sollten Sie Workloads, die komplexere Strategien zur Neuplattformierung oder Umgestaltung (Re-Architect) erfordern, in eine future Phase verschieben, die über den Rahmen des ursprünglichen Geschäftsszenarios hinausgeht.
+ Wenn ROI und MIRR zu niedrig sind, sollten Sie Folgendes berücksichtigen:
+ Sind die Szenarien, die Sie in Betracht ziehen, zu konservativ? Haben Sie ein Szenario, das die wahrscheinlichsten Anforderungen an Kapazitätswachstum und Elastizität widerspiegelt? Haben Sie Szenarien, in denen die Kosten einschließlich der Steigerung der Servicequalität im Rahmen Ihrer Ziele verglichen werden?
+ Können Sie den Umfang des Anwendungsportfolios, das in der ersten Phase migriert werden soll, so verfeinern, dass Sie sich auf Workloads konzentrieren, die höhere Renditen erzielen, z. B. solche mit geringerer aktueller Auslastung oder teuren Disaster Recovery-Anforderungen (DR)?
+ Ist es möglich, den Umfang des Anwendungsportfolios so zu verfeinern, dass zunächst bestimmte Workloads ausgeschlossen werden, mit denen kommerziell weniger erreicht wird? Können Sie beispielsweise Workloads verschieben, für die Softwarelizenzen von Drittanbietern aufgrund unterschiedlicher Bedingungen für die Bereitstellung in der Public-Cloud-Infrastruktur teurer werden?
+ Wenn der endgültige Vergleich der Laufraten nicht dem erwarteten Ziel entspricht, sollten Sie Folgendes untersuchen:
+ Stellen Sie zunächst sicher, dass die anderen Kennzahlen den Erwartungen entsprechen. Mit den zukunftsweisenden Geschäftsszenarien soll in erster Linie nachgewiesen werden, dass genügend finanzielle Möglichkeiten bestehen, um den Beginn der nächsten Phase der Migrationsvorbereitung zu rechtfertigen.
+ Identifizieren Sie eine Liste der Möglichkeiten, die Kosteneffizienz auch AWS nach der ersten Phase der Migration weiter zu verbessern.
Fügen Sie bei der Erstellung des detaillierten Geschäftsszenarios eine Bewertung der Liste der Möglichkeiten bei. Fügen Sie darüber hinaus eine Bewertung der Geschäftschancen in die laufende Wartung des Falls und den Prozess der month-to-month Kostenoptimierung nach Abschluss der Migration ein.