Skip to content
Beta

Overview

Build transparent, decision-ready business cases by combining expected cloud costs with baseline economics and strategic value outcomes.

In 1 trail

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.

For each application, answer one practical decision question:

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

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.

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.

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.

Asset title
Framework
Asset type

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.

Swipe sideways to see the whole diagram
Business Case cost transparency by stack Example annual run-cost index by category, using one shared scale for baseline and target. Business Case cost transparency by stackExample annual run-cost index by category, using one shared scale for baseline and target.Infrastructure - 42Licenses - 18Operations - 22Security and compliance - 8Backup and DR - 10Infrastructure - midpoint 32Licenses - midpoint 18Operations - midpoint 20Security and compliance - midpoint 8Backup and DR - midpoint 10On-Premises baselineTotal index: 100STACKIT targetMidpoint index: 88 (range: 72 to 105)Range-based outcome viewTotal effect range: −28% to +5% vs baselineCategory range modelInfrastructure: −40% to −10%Licenses: −20% to +15%Operations: −25% to +10%Security/compliance: −10% to +20%Backup/DR: −15% to +25%Recurring vs one-time costsThis stack covers recurring run costs only.Model one-time migration costs separately.

Assumptions, data basis, and evidence references

Section titled “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.

Reference points for methodology and observed spend variability:

External source data.finops.org FinOps Foundation: State of FinOps data and benchmarking hub Open external site Leads off the trail External source finops.org FinOps Foundation framework: Usage optimization capability Open external site Leads off the trail External source finops.org FinOps Foundation framework: Rate optimization capability Open external site Leads off the trail

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

Section titled “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.

Swipe sideways to see the whole diagram
R-strategy matrix: migration investment versus long-term value Each strategy is shown as a range area: X = one-time migration/project investment, Y = long-term value (run-cost impact plus business effects). R-strategy matrix: migration investment versus long-term valueEach strategy is shown as a range area: X = one-time migration/project investment, Y = long-term value (run-cost impact plus business effects).Preferred zone: low investment, high valueLeast attractive zone: high investment, low valueOne-time migration and project cost index (low to high)Long-term value index (low to high)RelocateRehostReplatformRepurchaseRefactorRetainRetireArea width and height represent value ranges. Midpoint dots are orientation anchors, not commitments. Dashed = not a migration path (keep or decommission).VALUE RANGES BY STRATEGYInvestValueRelocate10–2510–25Rehost15–3520–40Replatform30–5540–65Repurchase45–7555–80Refactor55–9060–90Retain5–2010–30Retire20–4550–85

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.

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.

Speed and delivery performance

Faster provisioning, shorter lead times, and improved release frequency can accelerate product and feature delivery.

Resilience and risk reduction

Better backup, recovery, and high-availability patterns can reduce outage probability and outage impact.

Security and compliance posture

Improved control maturity, automation, and auditability can lower operational and regulatory risk exposure.

Scalability and demand flexibility

Elasticity can reduce overprovisioning and prevent growth bottlenecks during demand spikes.

Technical debt and modernization enablement

Platform modernization can reduce maintenance overhead and enable future architecture evolution.

Workforce productivity and focus

Teams can spend less effort on undifferentiated infrastructure tasks and more on business outcomes.

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.

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.

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

  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.

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.