---
title: "App Rationalization (6R)"
description: 'App rationalization with the 6R model: a practical framework for assessing and categorizing applications to pick the right migration path onto STACKIT.'
scfAsset:
  maintainers:
    - user: "tobias.mueller"
  managed: false
  category: "whitepaper"
  external: false
  tags: ["Advisory", "Assessment", "6R", "wip"]
source_url: "https://framework.stackit.cloud/advisory/assetcontainer/tm/app-rationalization-6r/"
source_file: "docs/advisory/assetcontainer/tm/app-rationalization-6r.mdx"
---

<Aside type="note" title="Strategic Alignment">
  **Focus:** Portfolio Strategy & Modernization Roadmap **Methodology:** 6R
  (Rehost, Replatform, Refactor, Retain, Retire, Replace) **Model:** Open Asset
  / Methodological Guide
</Aside>

## Strategy before Migration

Not every application should be treated the same. Rationalization is the deliberate step *before* migration where you decide, per application, **whether** to move it and **how much** to change it on the way. Done well, it prevents two classic failures: lifting technical debt straight into the cloud, and over-engineering apps that should simply be switched off.

The 6R model assigns every application in the portfolio exactly one disposition, turning a sprawling estate into a prioritized, fundable roadmap.

### The 6 Rs at a glance

<Steps>
1. **Rehost** — "Lift & shift" to STACKIT with minimal change.
2. **Replatform** — "Lift, tinker & shift": swap selected components for managed services.
3. **Refactor** — Re-architect for cloud-native benefits (containers, microservices, autoscaling).
4. **Retain** — Keep where it runs for now (latency, compliance, or weak business case).
5. **Retire** — Decommission redundant or obsolete applications.
6. **Replace** — "Drop & shop": move to a SaaS alternative.
</Steps>

## Choosing the right R

Each disposition trades migration effort against the cloud value it unlocks. Use this as the working reference when classifying the portfolio:

| Strategy | What you change | Effort | Choose when | Typical STACKIT target |
|---|---|---|---|---|
| **Rehost** | Infrastructure only (VM-level) | Low | You need to exit a data center fast and optimize later | Compute / IaaS VMs |
| **Replatform** | Selected components, no rewrite | Low–Medium | A managed service removes ops toil with little code change | Managed PostgreSQL, Object Storage, SKE |
| **Refactor** | Application architecture | High | Scalability/agility have a strong, funded business case | STACKIT Kubernetes Engine (SKE) + managed data services |
| **Retain** | Nothing (revisit later) | None now | Latency, data residency, or licensing block a move today | Hybrid connectivity to on-prem |
| **Retire** | Switch it off | Low | The capability is redundant or unused | — |
| **Replace** | Vendor / consumption model | Medium | A commodity capability has a strong SaaS fit | SaaS / Marketplace offering |

<Aside type="tip" title="Start with Retire and Retain">
  The cheapest migration is the one you don't do. Screening for **Retire** and **Retain** first typically removes a meaningful slice of the estate before anyone scopes a single migration — cutting cost, risk and timeline immediately.
</Aside>

## A simple decision flow

Run each application through the same questions to land on a defensible disposition:

<Steps>
1. **Is it still needed?** No → **Retire**.
2. **Must it stay on-premise** (latency, compliance, hardware dependency)? Yes → **Retain**.
3. **Does a SaaS product cover this commodity capability** well enough? Yes → **Replace**.
4. **Does cloud-native architecture have a funded business case** (scale, agility, cost)? Yes → **Refactor**.
5. **Can a managed service replace a component** with little code change? Yes → **Replatform**.
6. **Otherwise** → **Rehost** now and revisit modernization later.
</Steps>

## Value vs. Complexity

Map every application on two axes — **Business Value** and **Technical Complexity** — to sequence the roadmap and protect your modernization budget:

<CardGrid>
  <Card title="Quick Wins — high value, low complexity">
    Prioritize first. Usually **Rehost** or **Replatform**; fast proof points that build momentum and free up data-center capacity.
  </Card>
  <Card title="Strategic Bets — high value, high complexity">
    Fund deliberately as **Refactor** programs with clear milestones; this is where cloud-native ROI is realized.
  </Card>
  <Card title="Cleanup — low value, low complexity">
    Resolve cheaply via **Retire** or **Replace** to reduce sprawl and licensing cost.
  </Card>
  <Card title="Question Marks — low value, high complexity">
    Default to **Retain** and reassess; avoid spending scarce modernization effort here.
  </Card>
</CardGrid>

<Aside type="note" title="Verify STACKIT specifics before publishing">
  Service names and target mappings above are illustrative guidance. Confirm the exact STACKIT products, regions and managed-service options against current STACKIT documentation before this asset goes live.
</Aside>