Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieser Abschnitt gilt für Organisationen mit vorhandenen IT-Workloads außerhalb von Azure (lokal oder anderen Clouds), die eine Migration zu Azure benötigen. Ein umfassender Workloadbestand ist die Grundlage eines soliden Cloud-Einführungsplans für solche Organisationen. Sie können keine Entscheidungen darüber treffen, wie oder ob ein System migriert werden soll, wenn Sie es nicht kennen oder dessen Merkmale verstehen. Ihr Plan für die Cloudakzeptanz muss Schritte enthalten, um alle Workloads zu ermitteln, wichtige Daten zu jedem zu sammeln und sie für die Migration zu priorisieren.
| Workloadtyp | Ermittlungstool | Bewertungstool | Examples |
|---|---|---|---|
| On-premises | Azure Migrate | • Azure Migrate • Dr Migrate |
• Physische Server • VMware-VMs • Hyper-V VMs • SQL-Datenbanken • Webanwendungen |
| AWS-Infrastruktur (IaaS) | Azure Migrate | • Azure Migrate • AWS zu Azure Leitfaden |
• AWS EC2-Instanzen • AWS RDS-Datenbanken • AWS EBS-Volumes |
| Google Cloud Infrastructure (IaaS) | Azure Migrate | • Azure Migrate • Leitfaden zur Migration von Google Cloud zu Azure |
• VMs des Google Cloud Compute Engine • Google Cloud SQL • Google Cloud Persistent Disk |
| AWS-Plattformdienste (PaaS) | AWS-Ressourcen-Explorer | • AWS zu Azure-Migrationsleitfaden • AWS- und Azure-Dienstvergleich • Cloudockit |
• AWS Lambda • AWS Elastic Beanstalk • AWS DynamoDB |
| Google Cloud Platform Services (PaaS) | Google Cloud Asset Inventory (Inventarisierung von Google-Cloud-Ressourcen) | • Google Cloud to Azure Guidance • Vergleich von Google Cloud- und Azure-Diensten • Cloudockit |
• Google Cloud BigQuery • Google Cloud App Engine • Google Cloud Run-Funktionen |
| Anwendungscode |
CAST-Hervorhebung • Dr Migrate |
• Dr Migrate • CloudPilot • CAST-Hervorhebung • CloudAtlas • GitHub Copilot |
• GitHub • Azure Repos • GitLab |
Entdecken des Workload-Inventars
Ein vollständiges Inventar Ihrer technischen Ressourcen bildet die Grundlage Ihres Cloud-Einführungsplans. Ihr Bestand identifiziert alle Systeme, Anwendungen und Infrastrukturkomponenten in Ihrer gesamten Umgebung. Sie benötigen diesen Bestand, um zu entscheiden, welche Cloudmigrationsstrategie am besten geeignet ist.
Definieren Sie jede Workload und ihre Grenzen. Eine Workload ist eine Sammlung von IT-Komponenten wie Servern, virtuellen Computern (VMs), Clouddiensten, Anwendungen, Code, Daten oder Appliances, die einen oder mehrere Geschäftsprozesse unterstützen. Sie müssen jede Workload definieren, um den geschäftlichen Wert und den technischen Fußabdruck zu verstehen. Diese Klarheit hilft bei der Priorisierung von Migrations- und Modernisierungsbemühungen. Verwenden Sie Tools zur Überwachung und Abhängigkeitszuordnung von Netzwerkdatenverkehr, um Arbeitsauslastungsgrenzen zu identifizieren und Beziehungen zwischen Komponenten zu visualisieren.
Verwenden Sie automatisierte Ermittlungstools.Azure Migrate bietet kostenlose Ermittlungsfunktionen für lokale und Cloudumgebungen. Dieses Tool identifiziert automatisch Server, Anwendungen und deren Abhängigkeiten. Sie müssen die automatisierte Ermittlung verwenden, um die Bestandserstellung zu beschleunigen und manuelle Fehler zu reduzieren. Wenn Azure Migrate Ihre Umgebung nicht vollständig unterstützt, verwenden Sie Tools wie Dr Migrate oder CloudPilot , die Azure Migrate-Funktionen erweitern.
Schließen Sie alle Komponenten in allen Umgebungen ein. Ihr Bestand muss Infrastruktur- und Anwendungskomponenten auf allen Plattformen erfassen. Sie müssen Server, VMs, Anwendungen, Datenbanken, Kommunikationsmuster, Integrationen, Identitäten und Clouddienste von Azure, AWS, Google Cloud und anderen Anbietern einschließen. Diese umfassende Ansicht stellt sicher, dass während der Planung oder Migration keine kritische Ressource übersehen wird.
Verwenden Sie die manuelle Ermittlung, wenn die Automatisierung nicht möglich ist. Einige Umgebungen beschränken automatisierte Ermittlungstools aufgrund von Sicherheitsrichtlinien oder technischen Einschränkungen. Verwenden Sie die Azure Migrate-Importvorlage , um Ressourcen in eingeschränkten Umgebungen manuell zu dokumentieren. Die manuelle Dokumentation stellt sicher, dass Sie Ressourcen erfassen, auf die automatisierte Tools nicht zugreifen können.
Priorisieren von Workloads nach Geschäftswert und Machbarkeit
Eine lange Bestandsliste kann überwältigend sein. Der Plan sollte eine Methode enthalten, um zu priorisieren, welche Workloads zuerst bei der Cloud-Einführung angegangen werden sollen. Nicht alle Workloads sind gleich wichtig oder gleichermaßen geeignet für die sofortige Migration, verwenden Sie daher ein Priorisierungsframework.
Verwenden Sie geschäftskritische Daten. Ranken Sie Workloads nach ihrer Wichtigkeit für den Geschäftsbetrieb, den Umsatz oder die Kundenerfahrung. Häufig sind einige Workloads unternehmenskritisch (wenn sie ausfallen, große Geschäftsverluste), während andere weniger kritisch sind. High Business Value Systems kann hohe Priorität haben, um sicherzustellen, dass sie von der Cloudskalierbarkeit oder Resilienz profitieren, oder manchmal eine niedrigere Priorität, wenn das Risiko einer Migration zu hoch ist.
Schätzen sie die Cloudbereitschaft. Erstellen Sie schnelle, allgemeine Schätzungen darüber, wie bereit die einzelnen Arbeitsauslastungen für die Cloudmigration sind, je nachdem, was Sie bereits wissen. Eine detaillierte technische Bewertung kommt später, berücksichtigen aber vorerst Faktoren wie technische Komplexität, Legacykomponenten und bekannte Risiken. Einige Workloads lassen sich einfach umsetzen, während andere erhebliche Überarbeitungen erforderlich machen. Sie können einfachere Workloads priorisieren, um Dynamik zu schaffen, oder wählen Sie ein moderat komplexes, aber hochwertiges System aus, um den frühen Erfolg zu maximieren.
Beachten Sie Abhängigkeiten. Bewerten Sie in dieser Phase Abhängigkeiten auf hoher Ebene mit vorhandenen Kenntnissen. Eine vollständige Abhängigkeitszuordnung wird später durchgeführt, aber jetzt identifizieren Sie Workloads, die eng mit anderen verbunden sind. Systeme mit vielen Verbindungen müssen möglicherweise zusammen migriert werden, um Unterbrechungen zu vermeiden. In einigen Fällen muss eine Workload mit niedrigerer Priorität möglicherweise früher verschoben werden, da ein System mit höherer Priorität davon abhängt. Verwenden Sie diesen Einblick, um verwandte Workloads in logische Migrationswellen zu gruppieren.
Ziehen Sie strategische Ausrichtung in Betracht. Wenn bestimmte Workloads von entscheidender Bedeutung für strategische Initiativen sind, können Sie sie priorisieren, um schneller zu wechseln. Andererseits sollten Workloads, die eingestellt oder bald ersetzt werden sollen, für die Migration entprioritisiert werden.
Erstellen Sie einen priorisierten Backlog. Dieser Backlog kann eine Liste oder Tabelle mit Kategorien wie "Wave 1: Workloads A, B, C. Wave 2: Workloads D, E" sein. Stellen Sie sicher, dass Sie diese Reihenfolge mit Projektbeteiligten überprüfen. Geschäfts- und IT-Besitzer sollten überprüfen und zustimmen, dass die Sequenz sinnvoll ist. Sie möchten ihre Zustimmung erhalten und späteren Widerstand vermeiden. Wenn Sie zum Beispiel ohne Rücksprache für die kritische App einer Abteilung planen, werden möglicherweise Einwände erhoben. Passen Sie den Plan basierend auf Dem Feedback an, um technische Logik mit den geschäftlichen Anforderungen in Einklang zu bringen.
Sammeln von Geschäftsdetails pro Workload
Für jede identifizierte Workload sollte der Plan wichtige Geschäftskontexte und -anforderungen erfassen. Diese Informationen leiten die Migrationsstrategie (nächster Abschnitt) und stellen sicher, dass Entscheidungen den geschäftlichen Anforderungen entsprechen. Wichtige Details zum Dokument
Besitzer und Projektbeteiligte: Das Dokument 'verantwortet' die Arbeitslast aus geschäftlicher Perspektive (Vertriebsleiter für ein CRM) und aus IT-Perspektive (Anwendungsmanager, Infrastrukturmanager). Listet alle Projektbeteiligten auf, die an der Planung ihrer Verschiebung beteiligt sein müssen.
Geschäftsfunktion und Kritikalität: Dokumentieren Sie, was die Arbeitslast umfasst, und wie wichtig sie ist. Zeichnen Sie eine kurze Beschreibung ihres Zwecks auf und klassifizieren Sie ihr Kritisches Niveau (hoch/mittel/niedrig). Kritischität bezieht sich oft auf die Verträglichkeit von Ausfallzeiten.
Vertraulichkeit und Compliance von Daten: Beachten Sie die Klassifizierung von Daten, die das System verarbeitet (öffentlich, intern, vertraulich, streng vertraulich). Dokumentieren Sie compliance-Anforderungen (PCI, HIPAA, DSGVO), die für diese Workload gelten. Wenn beispielsweise in einer bestimmten Region Datenresidenz erforderlich ist, wirkt sich das auf die Cloudarchitektur aus.
Betriebseinschränkungen: Dokumentieren Sie bestimmte Wartungsfenster, Blackout-Zeiträume (Zeiträume mit hohem Datenverkehr) und Anforderungen an die Betriebszeit. Dokumentieren Sie solche Einschränkungen, da sie sich auf die Planung und Zielarchitektur der Migration auswirken (Anforderungen für hohe Verfügbarkeit).
Projizierter Zeitplan oder Fristen: Wenn es einen gewünschten Zeitplan für die Migration dieser Workload gibt, vermerken Sie dies ebenfalls. Vielleicht haben Sie beispielsweise Vertragsverlängerungen oder das Ende des Rechenzentrums-Leases. Diese Faktoren fließen in die Gesamtplanung der Roadmap ein.
Ein Beispiel finden Sie unter Migrationsakzeptanzplan.
Azure Discovery- und Bewertungstools und Ressourcen
| Category | Tool | Description |
|---|---|---|
| Discovery | Azure Migrate | Ermittelt Server, Anwendungen und Abhängigkeiten in Ihrer Infrastruktur |
| Discovery | Azure Migrate-Infrastruktur | Ermittelt lokale Infrastrukturkomponenten |
| Discovery | Azure Migrate-Anwendungsermittlung | Identifiziert Anwendungen, die in Ihrer Umgebung ausgeführt werden |
| Discovery | Dr.Migrate | Analysiert Ihre vorhandenen Workloads, um Migrationsbereitschaft und Modernisierungsmöglichkeiten zu identifizieren. Bietet detaillierte Einblicke in Abhängigkeiten, Konfiguration und potenzielle Blocker, um Ihre Migrationsplanung zu optimieren. |
| Discovery | Azure Migrate-Importvorlage | Aktiviert die manuelle Dokumentation von Ressourcen in eingeschränkten Umgebungen |
| Assessment | Azure Migrate-Bewertung | Wertet lokale Workloads für die Azure-Migration aus. |
| Assessment | Azure Migrate-Bewertung für physische Server | Bewertet physische und virtualisierte Server für die Cloudmigration |
| Assessment | Dr Migrate | Bewerten der Infrastruktur und des Codes für die Cloudmigration |
| Code-Entdeckungsbewertung | CAST-Hervorhebung | Analysiert Den Anwendungscode für die Cloudbereitschaft |
| Assessment | CloudPilot | Analysiert Anwendungen für die Cloudbereitschaft |
| Codebewertung | AppCAT | Bewertet .NET- und Java-Anwendungen für die Azure-Kompatibilität |
| Assessment | CloudAtlas | Bietet Modernisierungs- und Migrationsbewertung |
| PaaS-Bewertung | Cloudockit | Generiert Architekturdiagramme und Dokumentationen für Cloudumgebungen |
| AWS zu Azure-Migration | Aws-zu-Azure-Anleitung | Enthält Anleitungen für die Migration von AWS zu Azure |
| Google Cloud zu Azure-Migration | Leitfaden für Google Cloud zu Azure | Enthält Anleitungen für die Migration von Google Cloud zu Azure |
| AWS zu Azure-Migration | AWS-zu-Azure-Dienstzuordnung | Zuordnen von AWS-Diensten zu gleichwertigen Azure-Diensten |
| Google Cloud zu Azure-Migration | Google Cloud zu Azure-Dienstzuordnung | Abgleich von Google Cloud-Diensten mit gleichwertigen Azure-Diensten |