---
title: Overview
description: Business Case combines application-level cloud cost forecasting with baseline comparison and captures additional business value drivers of migration.
hero:
  tagline: Build transparent, decision-ready business cases by combining expected cloud costs with baseline economics and strategic value outcomes.
  illustration:
    name: product
    position: left
sidebar:
  label: Overview
  order: 0
source_url: "https://framework.stackit.cloud/migration/design-and-mobilize/business-case/overview/"
source_file: "docs/migration/design-and-mobilize/business-case/overview.mdx"
---

## Understanding this module

Business Case turns Discovery, target Design, and migration strategy into a transparent decision
model for each application.

The financial core is straightforward:

- Forecast expected cloud cost from target architecture and operating model.
- Compare this against baseline cost of the current state.
- Make deltas visible for Application Owners and sponsoring stakeholders.

This module then expands beyond pure cost comparison and captures additional business value that is
typically not directly available in technical discovery data.

## Core question to answer

For each application, answer one practical decision question:

**Does the migration create enough value, at the right time, to justify investment and delivery
risk?**

## Inputs for the business case

Business Case should use structured inputs from previous modules:

- **Discovery outputs**: Current workload profile, life cycle status, usage patterns, and baseline
  run cost.
- **Design outputs**: Target landing zone assumptions, target service choices, resiliency and
  security requirements.
- **Migration strategy**: Chosen migration pattern (for example Rehost, Replatform, Refactor),
  wave timing, and transition constraints.
- **Financial baseline**: Current TCO components such as infrastructure, licenses, operations,
  support, and depreciation where relevant.

## Cost transparency as the baseline outcome

The first mandatory output is a clear cost view per application and wave:

- **Target cloud run cost**: Forecast steady-state cost after migration.
- **Transition cost**: One-time migration cost (factory effort, tooling, dual-run, cutover).
- **Baseline cost**: Current-state cost on-premises or in existing hosting.
- **Delta view**: Difference over time, including break-even perspective.

This gives Application Owners the minimum information required to make migration decisions with
financial accountability.

## AI-assisted business-case assets

Use AI-assisted business-case assets to create first STACKIT run-rate estimates and business-case
drafts from captured requirements and target architecture assumptions for expert review.

<ScfAssetLoader
  showFilter={false}
  showSearch={false}
  frameworkSlug="migration"
  filterByTag="business-case"
/>

## Cost stack example

The following semantic stack compares baseline and target costs by category on one shared scale.
In this example, the STACKIT stack shows a midpoint scenario and explicit value ranges per
category. Depending on migration quality and FinOps maturity, some categories can increase.

Important: This chart uses illustrative cost-index values to explain the comparison method.
It is not an empirical benchmark and must be replaced with project-specific baseline and pricing inputs.

<BusinessCaseCostStackComparisonEn
  style={{
    width: "100%",
    maxWidth: "1400px",
    height: "auto",
    display: "block",
    overflow: "hidden",
    borderRadius: "12px",
  }}
/>

## Assumptions, data basis, and evidence references

- **Method**: Baseline is indexed to 100 and category effects are shown as range bands plus one midpoint scenario.
- **Interpretation**: Ranges are directional guidance from migration program practice and FinOps operating experience, not guaranteed outcomes.
- **Conditioning factors**: Architecture quality, migration pattern, workload fit, licensing model, resilience targets, and governance maturity strongly affect results.
- **Required project data**: Measured baseline utilization, contract/licensing position, target architecture choices, and operating model assumptions.

| Cost category           | Illustrative range vs baseline | Typical driver pattern                                                                              |
| ----------------------- | ------------------------------ | --------------------------------------------------------------------------------------------------- |
| Infrastructure          | -40% to -10%                   | Rightsizing and managed services can reduce overprovisioning.                                       |
| Licenses                | -20% to +15%                   | BYOL decisions and software model changes can reduce or increase spend.                             |
| Operations              | -25% to +10%                   | Automation can reduce effort; dual-running and transition complexity can offset gains.              |
| Security and compliance | -10% to +20%                   | Tooling consolidation may reduce cost, but higher control depth can increase spend.                 |
| Backup and DR           | -15% to +25%                   | Better storage class optimization may save cost; tighter RPO/RTO and replication can increase cost. |

Reference points for methodology and observed spend variability:

<LinkCard
  title="FinOps Foundation: State of FinOps data and benchmarking hub"
  href="https://data.finops.org/"
/>

<LinkCard
  title="FinOps Foundation framework: Usage optimization capability"
  href="https://www.finops.org/framework/capabilities/usage-optimization/"
/>

<LinkCard
  title="FinOps Foundation framework: Rate optimization capability"
  href="https://www.finops.org/framework/capabilities/rate-optimization/"
/>

## R-strategy matrix for one-time investment versus long-term value

The following matrix explicitly models what the run-cost stack does not show:
one-time migration and project cost by strategy choice.

<BusinessCaseRStrategyInvestmentValueMatrixEn
  style={{
    width: "100%",
    maxWidth: "1400px",
    height: "auto",
    display: "block",
    overflow: "hidden",
    borderRadius: "12px",
  }}
/>

How to read this matrix:

- **X-axis**: One-time migration and project investment (implementation effort, tooling, testing, change, cutover).
- **Y-axis**: Long-term value (run-cost impact plus business and operating effects).
- **Point labels**: Illustrative ranges, not fixed promises.

Use both views together for decision quality:

- **Run-cost stack**: Recurring operating cost trajectory.
- **R-strategy matrix**: Upfront investment and transformation effect.
- **Decision metric**: Evaluate break-even and value realization over a defined horizon, not by run cost alone.

## Additional business value dimensions

Cost is essential, but it is only one part of the value equation. Cloud migration can produce
material benefits that are harder to derive directly from discovery data.

<CardGrid>
  <Card title="Speed and delivery performance">
    Faster provisioning, shorter lead times, and improved release frequency can accelerate product
    and feature delivery.
  </Card>
  <Card title="Resilience and risk reduction">
    Better backup, recovery, and high-availability patterns can reduce outage probability and outage
    impact.
  </Card>
  <Card title="Security and compliance posture">
    Improved control maturity, automation, and auditability can lower operational and regulatory
    risk exposure.
  </Card>
  <Card title="Scalability and demand flexibility">
    Elasticity can reduce overprovisioning and prevent growth bottlenecks during demand spikes.
  </Card>
  <Card title="Technical debt and modernization enablement">
    Platform modernization can reduce maintenance overhead and enable future architecture evolution.
  </Card>
  <Card title="Workforce productivity and focus">
    Teams can spend less effort on undifferentiated infrastructure tasks and more on business
    outcomes.
  </Card>
</CardGrid>

## Practical quantification approach

Not every value element needs a precise currency amount on day one. Use a mixed model:

- **Directly quantifiable**: Costs, licenses, infrastructure footprint, selected operations effort.
- **Estimable with proxies**: Incident impact, release lead time, environment provisioning speed.
- **Qualitative but decision-relevant**: Strategic agility, platform standardization, innovation
  enablement.

Document assumptions explicitly and keep confidence levels transparent.

## Suggested key metric set per application

At minimum, track:

- Baseline annual run cost.
- Forecast annual cloud run cost.
- One-time migration investment.
- Expected break-even period.
- Change lead time trend (before/after).
- Availability or incident impact trend.
- Security/compliance findings trend.

## Iterative business case life cycle

Business Case is not a one-time document. It should be maintained per wave and refined as delivery
data improves.

<Steps>

1. Build initial assumptions from Discovery and target Design.
2. Estimate target cloud and migration costs for each application.
3. Add non-cost value hypotheses and measurable proxies.
4. Review and approve assumptions with Application Owner and Finance stakeholders.
5. Update business case after pilot and early waves with actuals.
6. Reprioritize migration backlog based on updated value evidence.

</Steps>

## Outputs of this module

Business Case should at minimum produce:

- **Application-level business case sheet**: Cost baseline, target forecast, migration investment,
  and break-even logic.
- **Value dimension assessment**: Structured view of additional benefits and risk reduction effects.
- **Assumption register**: Explicit assumptions, data quality notes, and confidence rating.
- **Decision recommendation**: Proceed, defer, redesign, or stop per application.