---
title: Rapid Discovery
description: Rapid Discovery captures infrastructure quantities and platform baselines to estimate STACKIT target costs and prepare sizing assumptions for migration planning.
hero:
  tagline: "Rapid Discovery provides a fact-based quantity baseline to support early cost indication and migration decisions in the Assess phase."
  illustration:
    name: product
    position: left
sidebar:
  label: Overview
  order: 0
  attrs:
    data-icon: dashboard
source_url: "https://framework.stackit.cloud/migration/assess/rapid-discovery/overview/"
source_file: "docs/migration/assess/rapid-discovery/overview.mdx"
---

## Overview

Rapid Discovery provides a fast, automated baseline of the current environment
across on-premises and cloud landscapes. The focus is on quantifying the existing
IT portfolio in a short time window, so teams can make early migration and
commercial decisions with confidence.

At this stage, quantity and distribution matter more than deep application
relationships.

## What Rapid Discovery Captures

Rapid Discovery builds an initial inventory of infrastructure and platform assets,
including:

<CardGrid>
  <Card title="Compute footprint">Virtual machines and host counts.</Card>
  <Card title="Storage baseline">Storage capacity and storage classes.</Card>
  <Card title="OS landscape">Operating system families and versions.</Card>
  <Card title="Kubernetes baseline">Kubernetes cluster counts and baseline characteristics.</Card>
  <Card title="Database inventory">Database engines, sizes, and instance counts.</Card>
</CardGrid>

These metrics create the first fact-based view of migration scope.

## Why It Matters in Assess

The output of Rapid Discovery is a core input for:

- **Early price indication**: Build the first STACKIT-aligned cost baseline.
- **Initial TCO view**: Create a first total cost of ownership corridor.
- **Target capacity assumptions**: Define initial cloud capacity and landing zone requirements.

This allows program stakeholders to align on financial direction and technical
baseline before detailed planning starts.

## Boundary to Discovery Phase

Rapid Discovery is intentionally not a full application-level analysis. It does
not include deep interviews with every application owner and does not aim to
fully map all runtime dependencies.

That depth is covered in the subsequent Discovery phase, where infrastructure
exports are enriched with targeted assessments and owner input to build a
complete application picture.

## Typical Inputs and Future Assets

Typical input sources include exports such as spreadsheets or similar inventory
files from existing environments. This phase can be accelerated with AI-assisted
tooling that extracts the required baseline metrics from uploaded datasets.

Rapid Discovery therefore acts as a prerequisite for structured cost indication
and for shaping a realistic target environment strategy.

## AI-assisted discovery assets

Use AI-assisted discovery assets when workload descriptions and inventory inputs need to be turned
into first assessment and design artifacts for expert review.

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

## Rapid Discovery Process at a Glance

The following diagram shows why Rapid Discovery is performed: raw source data is
processed by tooling into a decision-ready baseline that supports early price
indication and initial target sizing.

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

## Method in Practice

A robust Rapid Discovery typically follows a clear sequence:

<Steps>

1. Collect data from available sources (CMDB, hypervisor exports, cloud
   inventories, monitoring, storage reports, database lists).
2. Standardize and consolidate records into a unified schema.
3. Classify assets by workload type and technical characteristics.
4. Aggregate results for management-level decision making.
5. Validate initial assumptions with responsible stakeholders.

</Steps>

The objective is not a perfect target architecture. The objective is a reliable
starting point with enough accuracy for early decisions.

## Data Quality and Assumptions

Result quality depends heavily on source quality. Typical issues include
duplicates, outdated entries, inconsistent naming, and missing performance data.

Recommended practice for this phase:

- **Document assumptions**: Keep growth rates, consolidation factors, and capacity buffers explicit.
- **Flag unclear records**: Mark uncertain entries instead of removing them too early.
- **Assign confidence levels**: Label findings as high, medium, or low confidence.

This keeps cost indications traceable and allows focused refinement in the
subsequent Discovery phase.

## Link to Price Indication and TCO

Rapid Discovery provides the volume baseline for early cost modeling. Captured
assets are translated into STACKIT-relevant consumption dimensions, for example:

- **Compute sizing**: Use vCPU and RAM as the baseline dimensions.
- **Storage class selection**: Use storage capacity and I/O characteristics.
- **Managed service options**: Use database engine and size classes.
- **Platform cost estimation**: Use cluster and node counts.

Combined with operating assumptions (runtime profile, availability targets,
growth trajectory), this produces a solid first price indication and an initial
TCO corridor.

## Typical Outputs

At the end of Rapid Discovery, the following outputs should be available at a
minimum:

<CardGrid>
  <Card title="Consolidated asset baseline">
    Quantities per technology domain are consolidated in one baseline.
  </Card>
  <Card title="Meaningful segmentation">
    Assets are segmented by criticality, environment, and modernization potential.
  </Card>
  <Card title="Traceable assumptions">
    Assumptions and identified data gaps are documented transparently.
  </Card>
  <Card title="Initial cost indication">
    Cost ranges and primary drivers are available for early planning.
  </Card>
  <Card title="Prioritized candidates">
    A prioritized list for deeper Discovery activities is available.
  </Card>
</CardGrid>

These outputs establish the working baseline for architecture, planning,
and governance in the next Assess steps.

## Risks and Countermeasures

Common Rapid Discovery risks include over-simplified categorization,
incomplete source systems, or overestimating data maturity.

Proven countermeasures:

- **Combine sources**: Use multiple data sources instead of relying on one source.
- **Review outliers**: Check very large or very old systems systematically.
- **Align perspectives**: Align finance and engineering interpretation to reduce bias.

This keeps the phase fast while preserving decision quality.

## Transition to the Discovery Phase

The handover point is reached when quantities, technology classes, and primary
cost levers are sufficiently visible and open questions are clearly documented.

In Discovery, these open items are addressed through targeted owner interviews,
deeper assessments, and dependency/compliance/operations analysis to build the
full application-level picture.