App Rationalization (6R)

Strategic Alignment

Focus: Portfolio Strategy & Modernization Roadmap Methodology: 6R (Rehost, Replatform, Refactor, Retain, Retire, Replace) Model: Open Asset / Methodological Guide

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

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.

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:

Swipe sideways to see the whole table

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

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.

A simple decision flow

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

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.

Value vs. Complexity

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

Quick Wins — high value, low complexity

Prioritize first. Usually Rehost or Replatform; fast proof points that build momentum and free up data-center capacity.

Strategic Bets — high value, high complexity

Fund deliberately as Refactor programs with clear milestones; this is where cloud-native ROI is realized.

Cleanup — low value, low complexity

Resolve cheaply via Retire or Replace to reduce sprawl and licensing cost.

Question Marks — low value, high complexity

Default to Retain and reassess; avoid spending scarce modernization effort here.

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.