---
title: Discovery
description: Discovery builds a reliable application-level baseline from infrastructure, dependencies, usage, and stakeholder input to reduce risk in design decisions and migration planning.
hero:
  tagline: Discovery turns early quantity baselines into a decision-ready view of applications, dependencies, and organizational readiness for realistic migration planning.
  illustration:
    name: product
    position: left
sidebar:
  label: Overview
  order: 0
source_url: "https://framework.stackit.cloud/migration/design-and-mobilize/discovery/overview/"
source_file: "docs/migration/design-and-mobilize/discovery/overview.mdx"
---

## Understanding Discovery

Discovery is one of the first and most critical modules in the Design and Mobilize phase.
It refines Rapid Discovery results and adds the depth needed to make architecture and
migration-wave decisions with confidence.

The primary objective is to establish a realistic, evidence-based understanding of the current
IT landscape, business priorities, and organizational readiness before detailed target design and
migration planning are finalized.

## Core Objectives

<CardGrid>
  <Card title="Complete baseline">
    Create a reliable application and infrastructure baseline that goes beyond pure quantities.
  </Card>
  <Card title="Dependency transparency">
    Identify technical and process dependencies to avoid hidden migration blockers.
  </Card>
  <Card title="Business alignment">
    Link technical findings with business criticality, timelines, and risk tolerance.
  </Card>
  <Card title="Planning readiness">
    Produce decision-ready input for target design and migration-wave planning.
  </Card>
</CardGrid>

## What Discovery Typically Captures

<CardGrid>
  <Card title="Inventory">
    Comprehensive capture of servers, virtual machines, databases, middleware, and applications.
  </Card>
  <Card title="Dependency analysis">
    Mapping of communication paths and runtime dependencies between systems and applications.
  </Card>
  <Card title="Resource utilization">
    Analysis of actual CPU, memory, storage, and I/O behavior over a representative period.
  </Card>
  <Card title="Operational context">
    Collection of backup, patching, SLA, compliance, and operational constraints.
  </Card>
  <Card title="Application owner input">
    Structured questionnaires and interviews to validate assumptions and close data gaps.
  </Card>
</CardGrid>

## Typical Delivery Setup

In practice, Discovery is often run together with STACKIT partners. Partners typically use
their own tooling landscape to collect and normalize technical data into a central repository.
Many programs also trigger targeted questionnaires for application owners directly from these tools
to enrich technical findings with business and operational context.

This combined model improves speed and consistency while keeping stakeholder validation built into
the process.

## Two Evidence Streams: Technical vs. Human-Driven

Discovery intentionally combines two evidence streams that complement each other:

- **Technically derived evidence**: Tooling-generated findings from inventory exports, runtime metrics,
  and dependency signals. This stream provides scale, consistency, and repeatability.
- **Application-owner enrichment (human-driven)**: Validated business criticality, lifecycle intent,
  release constraints, and operational realities from owner interviews and questionnaires.

Neither stream is sufficient on its own. Technical evidence without owner context can misclassify
critical workloads, while human input without technical grounding can hide coupling and capacity risks.
Discovery quality depends on reconciling both streams into one decision-ready view.

## Discovery Process at a Glance

The following diagram shows how Discovery transforms technical and stakeholder input
into decision-ready outputs for the downstream modules.

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

## Typical Analysis Patterns in Discovery Tooling

During Discovery, tooling commonly applies the following analysis patterns:

- **Record normalization**: Merge heterogeneous exports into one coherent application model.
- **Dependency mapping**: Detect communication paths, data exchange, and coupling patterns.
- **Criticality and risk scoring**: Evaluate business impact, failure domain, and compliance exposure.
- **Utilization profiling**: Build workload demand baselines for right-sizing and target planning.
- **Segmentation analysis**: Cluster applications by readiness, constraints, and migration strategy fit.
- **Wave simulation**: Model move groups and sequence options under dependency constraints.
- **Gap and assumption tracking**: Keep unresolved findings transparent with confidence levels.

These analyses establish the technical fact base. The human-driven stream then validates,
prioritizes, and contextualizes these findings for executable migration decisions.

## AI-assisted discovery assets

Use AI-assisted discovery assets to structure workload inputs, service mapping, readiness findings,
and R-strategy signals before architects validate the resulting discovery baseline.

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

## Method in Practice

<Steps>

1. Aggregate source data from CMDBs, hypervisors, cloud inventories, monitoring, and export files.
2. Normalize and consolidate records into a common application-centric model.
3. Discover and validate dependencies (network, data, identity, integration, and batch flows).
4. Enrich with owner input on criticality, lifecycle, constraints, and migration feasibility.
5. Classify workloads for migration strategy options and wave sequencing.
6. Validate findings with architecture, security, platform, and business stakeholders.

</Steps>

## Why Discovery Is Critical

- **Reduces migration risk**: Early visibility of hidden dependencies lowers outage and rollback risk.
- **Improves wave planning**: Workloads can be grouped realistically by coupling, criticality, and readiness.
- **Prevents over/under-sizing**: Measured utilization replaces assumptions in target capacity planning.
- **Supports governance**: Security, compliance, and operational constraints are addressed before rollout.
- **Strengthens stakeholder buy-in**: Shared facts improve decision quality across business and IT.

## Relevance for Follow-On Modules

Discovery outputs are directly reused by the next modules in Design and Mobilize:

<CardGrid>
  <Card title="Design">
    Uses dependency, capacity, and risk insights to shape target architecture options.
  </Card>
  <Card title="Security and Compliance">
    Uses data classification and control gaps to define prioritized security requirements.
  </Card>
  <Card title="Landing Zone">
    Uses platform and governance constraints to define foundational setup decisions.
  </Card>
  <Card title="Migration Plan">
    Uses move groups, criticality, and sequencing constraints for realistic wave planning.
  </Card>
  <Card title="Operating Model and Business Case">
    Uses ownership, process impact, and value/risk signals for staffing and investment priorities.
  </Card>
</CardGrid>

## Discovery Outputs

At minimum, Discovery should produce the following outputs:

- **Consolidated application baseline**: Mapped inventory by domain, environment, and criticality.
- **Dependency map**: Verified upstream/downstream relationships and integration touchpoints.
- **Utilization profile**: Evidence-based resource behavior and sizing assumptions.
- **Constraint register**: Security, compliance, licensing, and operational constraints.
- **Migration readiness view**: Prioritized candidates, risks, and sequencing recommendations.

These outputs are essential prerequisites for continuing with detailed design work and a
credible migration plan.