Target design per application
Defines workload architecture, service choices, integration approach, and constraints in the STACKIT context.
Rehost Spring Boot Service to VM
STACKIT
Design
Design translates Discovery findings into actionable target designs and migration runbooks per application, ready for factory execution.
What this module delivers
Section titled “What this module delivers”The Design module creates the executable migration design for each application identified in Discovery. It is not a generic architecture exercise. The target is a concrete design package that a migration factory can run with predictable quality.
R-strategy-backed decision record
Documents the selected migration strategy and why alternatives were rejected.
Factory-ready migration runbook
Provides a step-by-step procedure for run teams, including rollback and validation checkpoints.
Handover package
Delivers all required inputs to Migration Factory Setup, Landing Zone, and Migration Plan.
Module boundaries and dependencies
Section titled “Module boundaries and dependencies”These modules are connected, but they have different responsibilities:
Design (this module)
Decides target design and migration strategy per application and creates executable runbooks.
Migration Factory Setup
Enables delivery by selecting and preparing the right factory model, partner setup, and tooling stack.
Landing Zone
Provides the platform foundation and governance controls that target designs must comply with.
Migration Plan
Converts completed designs into realistic waves, sequencing, dependencies, and delivery milestones.
R-strategy as core design method
Section titled “R-strategy as core design method”The R-strategy model is the core decision framework in this module. For each application, the selected R-strategy must be justified with architecture, business, risk, and operability evidence.
Decision Criteria by R-Strategy
Section titled “Decision Criteria by R-Strategy”- Relocate: Choose when moving virtualization stacks is faster than redesign and governance constraints still allow conversion to cloud-native operations.
- Rehost: Choose for low change tolerance and strict timelines, where speed is prioritized over immediate modernization.
- Replatform: Choose when moderate changes unlock major benefits through STACKIT managed platform capabilities.
- Repurchase: Choose only for services available in the STACKIT ecosystem, including SaaS options such as ServiceNow, SAP, and partner offerings when they better fit business needs.
- Refactor: Choose for strategic applications where cloud-native redesign creates clear value in resilience, agility, or cost profile.
- Retain: Choose retain when timing or dependencies block migration now.
- Retire: Choose retire when business value no longer justifies operational effort.
Cross-path steps in the diagram
Section titled “Cross-path steps in the diagram”The diagram is not only an orientation aid. It is the shared decision and handover spine across Design, Landing Zones, Migration Factory Setup, and Migration Plan.
1. Discovery input
Section titled “1. Discovery input”Consolidate inventory, dependency map, risk profile, and non-functional constraints before strategy branching starts.
2. Evaluate and prioritize
Section titled “2. Evaluate and prioritize”Prioritize workload candidates by criticality, effort, and wave feasibility to focus design capacity where delivery risk is highest.
3. Determine migration path
Section titled “3. Determine migration path”Select the right R-strategy per workload and route into the dedicated strategy page with explicit rationale and alternatives considered.
4. Validation
Section titled “4. Validation”Run a shared quality gate across architecture, security/compliance, runbook quality, and operating readiness before approving wave execution.
5. Transition
Section titled “5. Transition”Prepare controlled handover into migration execution with release readiness, communication model, and clearly assigned ownership for wave run and escalation paths.
6. Production
Section titled “6. Production”Finalize production handover criteria and Day-1 operating baseline so migrated workloads enter run operations with clear accountability and evidence.
How to build the target design per application
Section titled “How to build the target design per application”- Confirm the application scope and baseline from Discovery (dependencies, usage, criticality, constraints).
- Define business and technical design goals, including availability, security, compliance, and performance targets.
- Evaluate the R-strategy options against objective criteria and record the selected strategy with rationale.
- Map the target to STACKIT products and platform capabilities, including networking, identity, data, and operations patterns.
- Specify migration approach details (cutover model, data movement, integration transition, rollback strategy).
- Create the migration run book for the factory with explicit tasks, quality checks, and acceptance criteria.
- Validate design assumptions with architecture, security, platform, and business owners.
- Hand over the approved design package to Migration Factory Setup and Migration Plan.
Design package required for factory run
Section titled “Design package required for factory run”At minimum, each application package should include:
- Target architecture definition: Workload placement, service mapping, integration model, and non-functional requirements.
- R-strategy decision record: Selected strategy, decision criteria, alternatives considered, and key risks.
- Migration run book: Sequenced run steps, checks before run, rollback path, validation steps, and go-live criteria.
- Dependency and interface impact: Required coordination with upstream/downstream systems and transition windows.
- Compliance and security controls: Mandatory controls and evidence requirements for release readiness.
Cloud design patterns for typical STACKIT applications
Section titled “Cloud design patterns for typical STACKIT applications”Use a dedicated pattern page to define a concrete target architecture before selecting the migration runbook.
Workload use-case lens for migration variants
Section titled “Workload use-case lens for migration variants”In addition to R-strategy, use the workload lens to classify what is migrated and to select feasible implementation variants with explicit boundary conditions.
AI-assisted design assets
Section titled “AI-assisted design assets”AI-assisted design assets support architects in turning application requirements, source-service context, and R-strategy options into reviewable target-design proposals. Use their outputs as input for architecture, security, platform, and business validation before approving a migration path.
Asset title
Framework
Asset type
Migration
Runbook
Migration
Blueprint
Migration
Blueprint
Migration
Guide
Migration
Software
Migration
Software
Migration
Software
Migration
Runbook
Migration
Blueprint
Migration
Blueprint
Migration
Blueprint
Adoption
Service
Advisory
Service
Migration
Software
Migration
Service
Migration
Guide
Runbook assets
Section titled “Runbook assets”Asset title
Framework
Asset type
Migration
Runbook
Migration
Runbook
Migration
Runbook
How design drives the migration plan
Section titled “How design drives the migration plan”Migration planning quality depends on design quality. Wave sequencing, factory throughput, and delivery risk are directly influenced by how precise the target designs and run books are. In practice, incomplete designs lead to unstable waves and avoidable delivery delays.