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 benötigt werden und wann sie 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. Dies sind in der Regel Mitglieder der Teams für Servicemanagement, Betrieb, Kapazitätsplanung, Überwachung und Support sowie 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	Treuegrad	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.	Mittelschwer	Manuell verwaltete, inkonsistente Detaillierungsgrade
CMDB	Mittel: ~ 50% der korrekten Daten, ~ 50% angenommene Werte oder Daten sind 90-120 Tage alt.	Mittelschwer	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, ~ 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 auf vorhandenen CMDBs oder anderen internen Inventaren und Kontrollsystemen verfügbar. Erwägen Sie die Erstellung eindeutiger IDs, wenn 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)	Mittelschwer
Beschreibung	Primäre Anwendungsfunktion und Kontext	R	O	Mittelschwer
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	Mittelschwer
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 und/oder virtuellen Ressourcen, aus denen die Anwendung besteht	O	O	Mittelschwer
License	Lizenztyp für Standardsoftware (z. B. Microsoft SQL Server Enterprise)	O	R	Mittel-Hoch
Kosten	Kosten für Softwarelizenzen, Softwarebetrieb und Wartung	N/A	O	Mittelschwer

Infrastruktur

Name des Attributs	Beschreibung	Inventar und Priorisierung	Geschäftsszenario	Empfohlene Treuestufe (mindestens)
Eindeutige Kennung	Zum Beispiel Server-ID. In der Regel auf vorhandenen CMDBs oder anderen internen Inventar- und Kontrollsystemen verfügbar. Erwägen Sie die Erstellung eindeutiger IDs, wenn 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	Mittelschwer
IP-Adresse und Netzmaske	Interne und/oder öffentliche IP-Adressen	R	O	Mittel-Hoch
Asset type (Objekttyp)	Physischer oder virtueller Server, Hypervisor, Container, Gerät, Datenbankinstanz usw.	R	R	Mittel-Hoch
Produktname	Kommerzieller Anbieter und Produktname (z. B. VMware ESXi, IBM Power Systems, Exadata)	R	R	Mittelschwer
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
Auslastung	Spitzenwert und Durchschnitt der CPU, des Arbeitsspeichers und des Speichers. Durchsatz der Datenbankinstanz.	R	O	Mittel-Hoch
License	Art der Warenlizenz (z. B. RHEL Standard)	R	R	Mittelschwer
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)	Mittelschwer
Zuordnung von Anwendungen	Anwendungen oder Anwendungskomponenten, die in dieser Infrastruktur ausgeführt werden	O	O	Mittelschwer
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	N/A	O	Mittel-Hoch

Netzwerke

Name des Attributs	Beschreibung	Inventar und Priorisierung	Geschäftsszenario	Empfohlene Treuestufe (mindestens)
Größe der Leitung (MB/s), Redundanz (J/N)	Aktuelle WAN-Link-Spezifikationen (z. B. 1000 MB/s redundant)	O	R	Mittelschwer
Link-Nutzung	Spitzen- und Durchschnittsauslastung, ausgehende Datenübertragung (GB/Monat)	O	R	Mittelschwer
Latenz (ms)	Aktuelle Latenz zwischen verbundenen Standorten.	O	O	Mittelschwer
Kosten	Aktuelle Kosten pro Monat	N/A	O	Mittelschwer

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	N/A	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	N/A	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	N/A	O	Mittel-Hoch
Ausmustern	Anzahl der Server, durchschnittliche Stilllegungskosten	N/A	O	Mittel-Hoch
Landezone	Wiederverwendung vorhandener (J/N), Liste der benötigten AWS Regionen, Kosten	N/A	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	N/A	R (F)	Mittel-Hoch
Dauer	Dauer der Workload-Migration im Rahmen des Geltungsbereichs (Monate)	O	R (F)	Mittel-Hoch
Parallele Kosten	Zeitrahmen und Geschwindigkeit, in der Ist-Kosten während der Migration wegfallen können	N/A	O	Mittel-Hoch
	Zeitrahmen und Geschwindigkeit, in der AWS Produkte und Dienstleistungen sowie andere Infrastrukturkosten während der Migration eingeführt werden	N/A	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 in CMDBs normalerweise nicht verfügbar sind

• 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 für das Tool auf jedem Zielsystem ein Agent installiert werden?

• 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-Ausführungsrate 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 auf Abruf 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 von Discovery-Ergebnissen an?

• Können sie die Elemente dieses Leitfadens behandeln?

• Gibt es Rabatte oder Pakete für Tooling+-Services?

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 Einhaltung der 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 Support Service Level Agreements (SLAs) in Bezug auf den Betrieb von Rechenzentren (Installation von Discovery-Tools, Firewall-Anfragen)?