Datenquellen und Datenanforderungen Bewertung des Bedarfs an Discovery-Tools

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 dem, was zu wenig ist, und dem, was zu viel ist, 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 die aktuelle Dokumentation, z. B. die CMDB oder ein gleichwertiges Dokument, die Zuordnung von Anwendung zu Infrastruktur? Ist jedes Infrastruktur-Asset einer Anwendung zugeordnet? Ist jede Anwendung der Infrastruktur zugeordnet?
Enthält die Dokumentation einen Katalog mit Lizenzen und Lizenzvereinbarungen für jedes Produkt?
Enthält die Dokumentation 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 das Vorhandensein von Leistungs-, Überwachungs-, Repositorys, Wissensdatenbanken und Verwaltungstools, 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	Bewertung des Genauigkeitsniveaus	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	Medium-low - 35-40% der korrekten Daten, 65-60% der angenommenen Werte oder Daten sind 120-150 Tage alt.	Mittel	Manuell verwaltete, inkonsistente Detaillierungsgrade
CMDB	Mittel: ~ 50% der korrekten Daten, ~ 50% angenommene Werte oder Daten sind 90-120 Tage alt.	Mittel	Enthält Daten aus gemischten Quellen, mehrere Datenlücken
VMware vCenter-Exporte	Medium-high - 75-80% der korrekten Daten, 25-20% angenommene Werte oder Daten sind 60-90 Tage alt.	Hoch	Deckt 90% der virtualisierten Infrastruktur 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	Bestandsaufnahme 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 Namen des handelsüblichen Herstellers (COTS) und des Produkts an.	R	R (D)	Medium-high
Ist COTS?	Ja oder Nein. Ob es sich um eine kommerzielle Anwendung oder eine interne Entwicklung handelt	R	R (D)	Medium-high
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	Medium-high
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)	Medium-high
Einhaltung gesetzlicher Vorschriften und Vorschriften	Für den Workload geltende Frameworks (z. B. HIPAA, SOX, ISO, SOC PCI-DSS, FedRAMP) und regulatorische Anforderungen	R	R (D)	Medium-high
Abhängigkeiten	Upstream- und Downstream-Abhängigkeiten zu internen und externen Anwendungen oder Diensten. Non-technical Abhängigkeiten wie betriebliche Elemente (z. B. Wartungszyklen)	O	O	Medium-low
Kartierung der Infrastruktur	Zuordnung zu physischen and/or virtuellen Ressourcen, aus denen die Anwendung besteht	R	O	Mittel
License	Lizenztyp für Standardsoftware (z. B. Microsoft SQL Server Enterprise)	O	R	Medium-high
Cost (Kosten)	Kosten für Softwarelizenzen, Softwarebetrieb und Wartung	O	O	Mittel

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	Medium-high
DNS-Name (vollqualifizierter Domänenname oder FQDN)	DNS-Name	O	O	Mittel
IP-Adresse und Netzmaske	Interne and/or öffentliche IP-Adressen	O	O	Medium-high
Asset type (Objekttyp)	Physischer oder virtueller Server, Hypervisor, Container, Gerät, Datenbankinstanz usw.	R	R	Medium-high
Product Name (Produktname)	Kommerzieller Anbieter und Produktname (z. B. VMware ESXi, IBM Power Systems, Exadata)	R	R	Mittel
Betriebssystem	Zum Beispiel REHL 8, Windows Server 2019, AIX 6.1	R	R	Medium-high
Konfiguration	Zugewiesene CPU, Anzahl der Kerne, Threads pro Kern, Gesamtspeicher, Netzwerkkarten	R	R	Medium-high
Nutzung	Spitzenwert und Durchschnitt von CPU, Arbeitsspeicher und Speicher. Durchsatz der Datenbankinstanz.	O	O	Medium-high
License	Art der Warenlizenz (z. B. RHEL Standard)	O	R	Mittel
Zuordnung von Anwendungen	Anwendungen oder Anwendungskomponenten, die in dieser Infrastruktur ausgeführt werden	R	O	Mittel
Cost (Kosten)	Vollständige Kosten für Bare-Metal-Server, einschließlich Hardware, Wartung, Betrieb, Speicher (SAN, NAS, Objekt), Betriebssystemlizenzen, gemeinsame Nutzung von Rackspace und Gemeinkosten im Rechenzentrum	O	O	Medium-high

Netzwerke

Attributname	Beschreibung	Bestandsaufnahme und Priorisierung	Geschäftsszenario	Empfohlene Treuestufe (mindestens)
Größe der Leitung (Mb/s), Redundanz () Y/N	Aktuelle WAN-Link-Spezifikationen (z. B. 1000 Mb/s redundant)	O	R	Mittel
Verbundene Standorte	Benannte Standorte, die über diesen Link miteinander verbunden sind	O	O	Mittel
Nutzung des Links	Spitzen- und Durchschnittsauslastung, ausgehende Datenübertragung () GB/month	O	R	Mittel
Latenz (ms)	Aktuelle Latenz zwischen verbundenen Standorten	O	O	Mittel
Cost (Kosten)	Aktuelle Kosten pro Monat	N/A	O	Mittel

Migration

Name des Attributs	Beschreibung	Inventar und Priorisierung	Geschäftsszenario	Empfohlene Treuestufe (mindestens)
Kosten für das Rehosting	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)	Medium-high
Kosten für die Umstellung der Plattform	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)	Medium-high
Kosten für die Refaktorierung	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)	Medium-high
Kosten für den Ruhestand	Anzahl der Server, durchschnittliche Stilllegungskosten	N/A	O	Medium-high
Landezone	Re-use existing (Y/N), Liste der benötigten AWS-Regionen, Kosten	N/A	R (F)	Medium-high
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)	Medium-high
Dauer	Dauer der Workload-Migration innerhalb des Geltungsbereichs (Monate)	O	R (F)	Medium-high
Parallele Kosten	Zeitrahmen und Geschwindigkeit, in der Ist-Kosten während der Migration wegfallen können	N/A	O	Medium-high
Parallele Kosten	Zeitrahmen und Geschwindigkeit, in der AWS-Produkte und -Services sowie andere Infrastrukturkosten während der Migration eingeführt werden	N/A	O	Medium-high

Bewertung des Bedarfs an Discovery-Tools

Benötigt Ihr Unternehmen Discovery-Tools? Für die Portfoliobewertung sind zuverlässige, aktuelle Daten zu 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, helfen Ihnen präzise Daten dabei, erfolgreiche Migrationspläne zu erstellen und die Zielinfrastruktur richtig einzuschätzen, 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 Datenbeschaffungsrate, 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
High-confidence 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 in AWS erforderlich sein werden (z. B. Sicherheitsgruppen, Instance-Typen, 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).

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 aktueller 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

Welche Daten werden von dem Tool gesammelt?
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 für die Bereitstellung des Tools erforderlich, und was sind die verschiedenen Komponenten?
Ist mehr als ein Architektur- oder Bereitstellungsmodell 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 die Datenerfassung ohne Agenten?
Bieten Agenten und Mitarbeiter ohne Agenten dieselben Funktionen?
Was ist der Inkassoprozess?

Features

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.

Cost (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 von Discovery-Ergebnissen an?
Können sie die Elemente dieses Leitfadens behandeln?
Gibt es Rabatte oder Pakete für Tooling+-Services?

Tipp

Verwenden Sie die Website Discovery, Planning and Recommendation, um Discovery-Tools zu finden und 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 Laufzeiten, Pakete und Frameworks 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.
Datenbankerkennung — Es sollte in der Lage sein, Datenbanken, Instanzen und Schemas, einschließlich Engine-Typen und -Versionen, zu erkennen.
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)
Right-sizing Empfehlung (kann sie beispielsweise eine empfohlene AWS Zielinfrastruktur abbilden?)
Visualisierung von Abhängigkeiten (kann beispielsweise die Zuordnung von Abhängigkeiten 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?)
Planung von Migrationswellen (z. B. empfohlene Anwendungsgruppen und Unterstützung bei der Erstellung von Migrationsplänen)
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)?

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Beschleunigung der Entdeckung und anfängliche Planung

Geschäftliche Faktoren und technische Leitprinzipien