--- title: Design description: Design defines an application-specific target architecture and migration run book using R-strategy decisions, STACKIT platform options, and handover criteria. hero: tagline: Design translates Discovery findings into actionable target designs and migration runbooks per application, ready for factory execution. illustration: name: product position: left sidebar: label: Overview order: 0 source_url: "https://framework.stackit.cloud/migration/design-and-mobilize/design/overview/" source_file: "docs/migration/design-and-mobilize/design/overview.mdx" --- ## 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. Defines workload architecture, service choices, integration approach, and constraints in the STACKIT context. Documents the selected migration strategy and why alternatives were rejected. Provides a step-by-step procedure for run teams, including rollback and validation checkpoints. Delivers all required inputs to Migration Factory Setup, Landing Zone, and Migration Plan. ## Module boundaries and dependencies These modules are connected, but they have different responsibilities: Decides target design and migration strategy per application and creates executable runbooks. Enables delivery by selecting and preparing the right factory model, partner setup, and tooling stack. Provides the platform foundation and governance controls that target designs must comply with. Converts completed designs into realistic waves, sequencing, dependencies, and delivery milestones. ## 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 - **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 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 Consolidate inventory, dependency map, risk profile, and non-functional constraints before strategy branching starts. - Discovery Overview ### 2. Evaluate and prioritize Prioritize workload candidates by criticality, effort, and wave feasibility to focus design capacity where delivery risk is highest. - Migration Plan ### 3. Determine migration path Select the right R-strategy per workload and route into the dedicated strategy page with explicit rationale and alternatives considered. - Relocate - Rehost - Replatform - Repurchase - Refactor - Retain/Retire ### 4. Validation Run a shared quality gate across architecture, security/compliance, runbook quality, and operating readiness before approving wave execution. - Security and Compliance - Runbook Readiness ### 5. Transition Prepare controlled handover into migration execution with release readiness, communication model, and clearly assigned ownership for wave run and escalation paths. - Migration Factory Setup Overview - Collaboration and Interfaces ### 6. Production Finalize production handover criteria and Day-1 operating baseline so migrated workloads enter run operations with clear accountability and evidence. - Migrate - Operating Model Handover ## How to build the target design per application 1. Confirm the application scope and baseline from Discovery (dependencies, usage, criticality, constraints). 2. Define business and technical design goals, including availability, security, compliance, and performance targets. 3. Evaluate the R-strategy options against objective criteria and record the selected strategy with rationale. 4. Map the target to STACKIT products and platform capabilities, including networking, identity, data, and operations patterns. 5. Specify migration approach details (cutover model, data movement, integration transition, rollback strategy). 6. Create the migration run book for the factory with explicit tasks, quality checks, and acceptance criteria. 7. Validate design assumptions with architecture, security, platform, and business owners. 8. Hand over the approved design package to Migration Factory Setup and Migration Plan. ## 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 Use a dedicated pattern page to define a concrete target architecture before selecting the migration runbook. - Cloud Design Patterns ## 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. - Workload Migration Use Cases - AWS and Azure Target Service Mappings ## 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. ## Runbook assets ## 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.