---
title: Discovery
description: Discovery schafft eine belastbare Basis aus Inventar, Abhängigkeiten, Nutzung und Stakeholder-Input, um Design und Planung der STACKIT-Migration abzusichern.
hero:
  tagline: Discovery überführt frühe Mengenbaselines in eine entscheidungsreife Sicht auf Anwendungen, Abhängigkeiten und organisatorische Bereitschaft.
  illustration:
    name: product
    position: left
sidebar:
  label: Übersicht
  order: 0
source_url: "https://framework.stackit.cloud/de/migration/design-and-mobilize/discovery/overview/"
source_file: "docs/de/migration/design-and-mobilize/discovery/overview.mdx"
---

## Überblick: Discovery

Discovery ist eines der ersten und wichtigsten Module in der Phase Design and Mobilize.
Es verfeinert die Ergebnisse aus Rapid Discovery und liefert die notwendige Tiefe,
um Entscheidungen zur Architektur und die Reihenfolge der Migration belastbar zu planen.

Das primäre Ziel ist ein realistisches, auf Fakten gestütztes Verständnis der bestehenden
IT-Landschaft, der Business-Prioritäten und der organisatorischen Bereitschaft,
bevor Zielbild und Migrationsplan im Detail festgelegt werden.

## Zentrale Ziele

<CardGrid>
  <Card title="Vollständige Basis">
    Eine belastbare Sicht auf Anwendungen und Infrastruktur schaffen, die über reine Mengen
    hinausgeht.
  </Card>
  <Card title="Transparente Abhängigkeiten">
    Technische und prozessuale Abhängigkeiten identifizieren, um versteckte Migrationsblocker zu
    vermeiden.
  </Card>
  <Card title="Business-Abgleich">
    Technische Erkenntnisse mit Kritikalität, Zeitrahmen und Risikoprofil des Business verknüpfen.
  </Card>
  <Card title="Planungsreife">
    Eine entscheidungsreife Grundlage für Zielbild und Migrationswellen erstellen.
  </Card>
</CardGrid>

## Was Discovery typischerweise erfasst

<CardGrid>
  <Card title="Inventarisierung">
    Vollständige Erfassung von Servern, virtuellen Maschinen, Datenbanken, Middleware und
    Anwendungen.
  </Card>
  <Card title="Abhängigkeitsanalyse">
    Abbildung von Kommunikationspfaden und Laufzeitabhängigkeiten zwischen Systemen und Anwendungen.
  </Card>
  <Card title="Ressourcennutzung">
    Analyse von CPU-, RAM-, Storage- und I/O-Verhalten über einen repräsentativen Zeitraum.
  </Card>
  <Card title="Betriebskontext">
    Erhebung von Anforderungen zu Backup, Patch, SLA, Compliance und betrieblichen Randbedingungen.
  </Card>
  <Card title="Input der Application Owner">
    Strukturierte Fragebögen und Interviews zur Validierung von Annahmen und zum Schließen von
    Datenlücken.
  </Card>
</CardGrid>

## Typisches Vorgehen

In der Praxis wird Discovery häufig gemeinsam mit STACKIT Partnern durchgeführt.
Partner nutzen dabei meist eigene Tool-Landschaften, um technische Daten zu sammeln,
zu normalisieren und in einer zentralen Sammlung zu konsolidieren.

Häufig werden aus diesen Tools heraus auch gezielte Rückfragen an Application Owner gestellt,
um technische Befunde um Business und Betrieb zu ergänzen.

Dieses kombinierte Modell erhöht Geschwindigkeit und Konsistenz und verankert
Stakeholder-Validierung direkt im Prozess.

## Zwei Evidence-Streams: technisch vs. human-driven

Discovery kombiniert bewusst zwei sich ergänzende Evidence-Streams:

- **Technisch ermittelte Evidenz**: Tooling-basierte Befunde aus Inventar-Exporten und Abhängigkeits-Signalen. Dieser Stream liefert Skalierbarkeit, Konsistenz und Wiederholbarkeit.
- **Application-Owner-Anreicherung (human-driven)**: Validierte Angaben zu
  Business-Kritikalität, Lifecycle-Absicht, Release-Restriktionen und betrieblicher
  Realität aus Interviews und Fragebögen.

Keiner der beiden Streams ist alleine ausreichend. Technische Evidenz ohne Owner-Kontext
kann kritische Workloads falsch einordnen. Human-Input ohne technische Grundlage kann
Kopplungen und Kapazitätsrisiken verdecken. Die Qualität von Discovery entsteht aus der
Zusammenführung beider Streams in eine belastbare Basis für Entscheidungen.

## Discovery-Prozess auf einen Blick

Die folgende Darstellung zeigt, wie Discovery technische und menschliche
Eingaben in entscheidungsreife Ergebnisse für die nachgelagerten Module überführt.

<DiscoveryAnalysisFlowSvg style={{ width: "100%", maxWidth: "1560px", height: "auto", display: "block" }} />

## Typische Analyse-Muster im Discovery-Tooling

Im Discovery werden typischerweise die folgenden Analyse-Muster angewendet:

- **Daten normalisieren**: Heterogene Exporte in ein konsistentes, auf Anwendungen ausgerichtetes Modell überführen.
- **Abhängigkeiten abbilden**: Kommunikation, Datenaustausch und Kopplungen erkennen.
- **Kritikalitäts- und Risiko-Bewertung**: Business-Impact, Ausfall-Domänen und Compliance-Exposition bewerten.
- **Analyse der Nutzung**: Daten zu CPU, RAM und Storage für Right-Sizing und die Planung der Zielumgebung belastbar ableiten.
- **Segmentierung**: Anwendungen nach Reifegrad, Restriktionen und Strategie-Fit gruppieren.
- **Wellen-Simulation**: Move Groups und Optionen für die Reihenfolge unter Abhängigkeitsrestriktionen modellieren.
- **Gap- und Annahmen-Tracking**: Offene Punkte transparent mit einer Einschätzung führen.

Diese Analysen bilden die technische Grundlage. Der human-driven Stream validiert,
priorisiert und ordnet diese Befunde für umsetzbare Migrationsentscheidungen ein.

## KI-gestützte Discovery-Assets

KI-gestützte Discovery-Assets können Workload-Eingaben, Service-Mapping, Readiness-Befunde und
R-Strategie-Signale strukturieren, bevor Architekten die Discovery-Baseline validieren.

<ScfAssetLoader
  showFilter={false}
  showSearch={false}
  frameworkSlug="migration"
  filterByTag="discovery"
/>

## Methodik in der Praxis

<Steps>

1. Quelldaten aus CMDB, Hypervisor, Cloud-Inventaren, Monitoring und Exportdateien zusammenführen.
2. Datensätze normalisieren und in ein gemeinsames, applikationsorientiertes Modell überführen.
3. Abhängigkeiten erfassen und validieren (Netzwerk, Daten, Identität, Integrationen und Batch-Flows).
4. Erkenntnisse mit Input der Owner zu Kritikalität, Lifecycle, Restriktionen und Migrationsfähigkeit anreichern.
5. Workloads für Migrationsstrategie-Optionen und Wellenplanung klassifizieren.
6. Ergebnisse mit Architektur, Security, Plattform und Business-Stakeholdern abstimmen.

</Steps>

## Warum Discovery kritisch ist

- **Risiko der Migration reduzieren**: Frühe Sichtbarkeit auf verdeckte Abhängigkeiten senkt Ausfall- und Rollback-Risiken.
- **Planung der Wellen verbessern**: Workloads lassen sich realistisch nach Kopplung, Kritikalität und Reifegrad gruppieren.
- **Falsche Dimensionierung vermeiden**: Gemessene Nutzung ersetzt Annahmen in der Zielkapazitätsplanung.
- **Governance absichern**: Security-, Compliance- und Betriebsanforderungen werden vor der Umsetzung adressiert.
- **Stakeholder-Buy-in stärken**: Gemeinsame Fakten verbessern die Entscheidungsqualität zwischen Business und IT.

## Relevanz für nachgelagerte Module

Die Ergebnisse aus Discovery werden direkt in den nachgelagerten Modulen wiederverwendet:

<CardGrid>
  <Card title="Design">
    Nutzt Abhängigkeits-, Kapazitäts- und Risikosignale zur Ausgestaltung tragfähiger
    Zielarchitekturen.
  </Card>
  <Card title="Security und Compliance">
    Nutzt Datenklassifizierung und Control-Gaps zur Priorisierung von Sicherheitsanforderungen.
  </Card>
  <Card title="Landing Zone">
    Nutzt Plattform- und Governance-Restriktionen für grundlegende Setup-Entscheidungen.
  </Card>
  <Card title="Migrationsplan">
    Nutzt Move Groups, Kritikalität und Sequenzrestriktionen für realistische Wellenplanung.
  </Card>
  <Card title="Operating Model und Business Case">
    Nutzt Ownership-, Prozess- und Value/Risk-Signale für Rollenbild und Investitionspriorisierung.
  </Card>
</CardGrid>

## Ergebnisse aus Discovery

Mindestens folgende Ergebnisse sollten aus Discovery vorliegen:

- **Konsolidierte Applikations-Basis**: Inventar nach Domäne, Umgebung und Kritikalität.
- **Abhängigkeitskarte**: Verifizierte Upstream-/Downstream-Beziehungen und wichtige Integrationen.
- **Profil der Nutzung**: Belastbare Daten zur Auslastung und Sizing-Annahmen.
- **Constraint-Register**: Security-, Compliance-, Lizenz- und Einschränkungen im Betrieb.
- **Migrationsreife-Sicht**: Priorisierte Kandidaten, Risiken und Empfehlungen für die Reihenfolge.

Diese Ergebnisse sind unverzichtbare Voraussetzungen für das nachfolgende detaillierte Design
und einen realistischen Migrationsplan.