Financial transparency
A first cost corridor and TCO perspective are available for investment decisions.
VM Application Migration with Controlled Cutover
STACKIT
Migration at a Glance
Last updated on
STACKIT
Migration at a Glance
Fast, image-first tour of the STACKIT Migration Framework for trade-fair booths and quick briefings: one visual per phase and module, looping automatically.
The Cloud Journey
Start at the tourist information office, prepare at basecamp, and follow the path to migration, operations, and innovation. Ask where your organization stands today. These six illustrated stations are a simplified story, not the formal framework phases.
Migration Phases
Assess
Frame Assess as the fast, low-commitment phase that builds an initial fact base and qualifies migration intent before deeper design work starts.
Understanding This Phase
Section titled “Understanding This Phase”Assess is the first phase of the STACKIT Migration Framework. It creates a fact-based baseline for migration decisions before architecture design and wave delivery begin.
The phase combines technical discovery with commercial and organizational alignment so that later migration work starts with clear priorities and transparent assumptions.
When Assess starts and ends
Section titled “When Assess starts and ends”Assess typically starts when a migration initiative has strategic sponsorship but no decision-ready baseline yet.
- Start when migration scope, business drivers, and decision stakeholders are defined at a high level.
- Build the baseline through Rapid Discovery, readiness evaluation, cost modeling, and stakeholder workshops.
- End when scope assumptions, migration readiness, and financial direction are clear enough to start detailed design.
Assess is completed when stakeholders can approve moving into Design and Mobilize with a shared understanding of cost, risk, and delivery feasibility.
Why this phase matters
Section titled “Why this phase matters”Assess reduces uncertainty early and aligns business and IT before large implementation effort is committed.
Readiness clarity
Gaps in technology, governance, capabilities, and operating model are visible early.
Stakeholder alignment
Leadership, delivery teams, and technical owners align on goals, scope, and expectations.
Risk reduction
Key assumptions and migration constraints are documented before target design starts.
Core modules in this phase
Section titled “Core modules in this phase”- Rapid Discovery: Establishes quantity baselines for early cost indication.
- TCO Report: Estimates total migration economics and long-term cost trajectory.
- Readiness Assessment: Evaluates migration readiness across technology and organization.
- Deep Dive Workshop: Builds technical understanding of STACKIT services and platform options.
- Briefings and Workshop: Aligns stakeholders and supports decision preparation.
Typical outcomes
Section titled “Typical outcomes”At the end of Assess, the program should have:
- Decision-ready baseline: A documented view of current landscape, scale, and migration scope.
- Initial economic model: Cost indication and TCO direction with transparent assumptions.
- Readiness and risk view: Prioritized gaps and mitigation needs for mobilization.
- Phase transition criteria: Clear entry conditions for Design and Mobilize.
Transition to Design and Mobilize
Section titled “Transition to Design and Mobilize”Assess does not finalize the full target architecture. Instead, it creates the validated input needed to start detailed design, migration-wave planning, and factory setup in the next phase.
Rapid Discovery
Readiness Assessment
Assess technical, process, personnel, financial, and governance readiness, then assign every gap to an owner and migration-wave gate.
Design and Mobilize
Position Design and Mobilize as the phase carrying most of the framework's substance: it turns Assess signals into an executable, factory-ready delivery plan.
Understanding This Phase
Section titled “Understanding This Phase”Design and Mobilize is the planning and enablement phase between Assess and Migrate. It translates baseline findings into executable target designs, governance, and migration factory readiness.
The phase ensures that migration delivery starts with clear architectural decisions, security controls, team setup, and wave planning.
When Design and Mobilize starts and ends
Section titled “When Design and Mobilize starts and ends”This phase starts after Assess confirms migration scope, readiness, and commercial direction.
- Start with detailed discovery of applications, dependencies, and migration constraints.
- Build target designs, business cases, and migration waves while setting up delivery structures.
- End when the first migration waves are approved, runbooks are ready, and governance is operational.
Design and Mobilize is complete when migration teams can begin wave run with stable inputs, controls, and responsibilities.
Why this phase matters
Section titled “Why this phase matters”This phase turns strategy into delivery readiness and prevents uncontrolled migrations.
Architecture readiness
Target patterns and migration paths per workload are defined and validated.
Factory enablement
Roles, processes, tooling, and runbook governance are established before scale-up.
Security by design
Security and compliance requirements are integrated into design and planning from the start.
Execution confidence
Waves are sequenced with dependency awareness and operational feasibility.
Core modules in this phase
Section titled “Core modules in this phase”- Discovery: Creates the application-level baseline and dependency transparency.
- Migration Plan: Translates strategy into wave-based delivery planning.
- Design: Defines migration approach and target patterns per application.
- Business Case: Consolidates value, effort, and investment logic per scope.
- Migration Factory Setup: Establishes the delivery factory model and operating mechanics.
- Enablement: Builds governance, learning, and reference capabilities for consistent delivery.
- Landing Zones: Implements the secure and scalable platform foundation.
- Target Operating Model: Defines the governance, accountabilities, and capabilities for stable cloud operations.
- Security and Compliance: Embeds control requirements into architecture and migration run.
Typical outcomes
Section titled “Typical outcomes”At the end of Design and Mobilize, the program should have:
- Approved target designs: Migration strategy and target architecture decisions per workload class.
- Wave-ready migration plan: Sequenced and dependency-aware wave plan with prioritized backlog.
- Factory operating setup: Governance cadence, runbook standards, and delivery ownership in place.
- Platform and control baseline: Landing zone and security/compliance controls ready for migration.
Transition to Migrate
Section titled “Transition to Migrate”Design and Mobilize can overlap with early migration waves. As soon as the first waves and runbooks are validated, Migrate begins and delivery continues iteratively while planning is refined for upcoming waves.
Discovery
Design
Use this interactive map to explore the STACKIT service portfolio. Select a product or access tool to open its current documentation or related Cloud Framework asset.
Interactive Service Portfolio
Section titled “Interactive Service Portfolio”Usage Notes
Section titled “Usage Notes”The map is a navigation aid rather than a lifecycle commitment. Check each linked product page for current regions, availability, service levels, and release status.
Browse all STACKIT product documentation Open the documentationWhy this page exists
Section titled “Why this page exists”R-strategy explains how migration is run. This page adds the workload lens and clarifies what is migrated. It is intentionally solution-neutral and focuses on transparent categorization, feasibility boundaries, and decision context.
Use-case categories in scope
Section titled “Use-case categories in scope”Application runtime migration
Migration of complete application runtimes across VM and platform targets, including dependencies, cutover behavior, and operating handover.
Container platform migration
Migration between Kubernetes platforms with separate treatment of stateless and stateful workload profiles.
Data migration
Migration of large file volumes, databases, and data platform workloads with explicit consistency, performance, and integrity boundaries.
Identity and access migration
Migration of IAM foundations such as SSO, federation, roles, service accounts, and permission models.
Network and connectivity migration
Migration of routing, DNS, firewall rules, segmentation, private connectivity, and cross-environment communication paths.
Integration and API migration
Migration of API contracts, messaging, eventing, and integration endpoints across source and target estates.
Security and compliance controls migration
Migration of controls, evidence chains, key material, and audit requirements required for regulated production readiness.
Operations and observability migration
Migration of monitoring, alerting, logging, incident workflows, and service-level operations baselines.
Delivery and resilience migration
Migration of CI/CD pipelines, automation controls, backup chains, and disaster recovery capabilities.
How current categories fit in this model
Section titled “How current categories fit in this model”- Application stack migration is part of Application runtime migration.
- Large file data migration is part of Data migration.
- Kubernetes to Kubernetes migration is part of Container platform migration.
Migration use cases from AWS and Azure to STACKIT
Section titled “Migration use cases from AWS and Azure to STACKIT”STACKIT supports migration paths from AWS and Azure across application runtimes, data, network, identity, operations, and delivery. Select the target path for each workload according to its architecture, data profile, availability requirements, and operating model.
| Use case | Migration capability to STACKIT |
|---|---|
| Landing zone migration | AWS account and Azure subscription structures, network segmentation, identity and access controls, security policies, logging, monitoring, and governance guardrails are mapped to a STACKIT landing zone before application migration waves begin. The STACKIT Landing Zone Accelerator provides a reusable, automated foundation for implementing these controls consistently at scale. |
| VM-based applications | AWS EC2 and Azure VM workloads can be migrated to STACKIT Compute Engine, including operating systems, middleware, applications, configurations, and connected data. |
| VM estates with high availability requirements | Tool-assisted Relocate migration supports continuous replication, controlled validation, and planned cutover for large VM landscapes and repeatable migration waves. |
| Container and Kubernetes workloads | AWS EKS, Azure AKS, and self-managed Kubernetes clusters can move to STACKIT Kubernetes Engine. Stateless applications can be redeployed declaratively; stateful applications can use backup and restore or data replication with staged traffic migration. |
| PaaS and web applications | Applications using common runtimes such as Java, Node.js, Python, or Ruby can run on STACKIT Cloud Foundry when they fit the platform model. |
| Databases and data platforms | Self-managed and cloud-based databases can move to STACKIT Managed Database Services or initially to Compute Engine instances, using export/import, replication, and controlled cutover procedures. |
| Object and file storage | AWS S3 and Azure Blob Storage can move to STACKIT Object Storage. AWS EFS, Azure Files, and NFS-based file systems can move to STACKIT File Storage through initial copy, delta synchronization, and final consistency cutover. |
| Identity and access management | AWS IAM, Azure RBAC, and Microsoft Entra-based access models can be mapped to STACKIT roles, permissions, service accounts, and federation. |
| Network, DNS, and connectivity | AWS VPCs and Azure VNets can be mapped to STACKIT Network Areas, routing, security groups, load balancing, DNS, and site-to-site VPN connectivity. |
| Integration, messaging, and APIs | APIs, integration endpoints, and messaging workloads can be migrated with their contracts, security mechanisms, and cutover sequence. STACKIT RabbitMQ supports AMQP- and RabbitMQ-based patterns. |
| Security, compliance, and operations | Secrets, keys, audit requirements, logging, monitoring, alerting, backup, and operational processes are established as part of the target environment before go-live. |
| CI/CD and delivery | Deployment pipelines, infrastructure automation, and source control can move to STACKIT Git, Terraform or OpenTofu, CLI, APIs, and suitable image-management processes. |
For the service-by-service target mapping, see AWS and Azure Target Service Mappings.
Classification dimensions
Section titled “Classification dimensions”Use these dimensions to categorize requests before selecting implementation variants:
- Migration object: Application stack, data set, or container platform.
- State profile: Stateless, stateful, or mixed.
- Criticality profile: Business criticality and accepted migration risk.
- Connectivity profile: Network reachability and protocol compatibility between source and target.
- Downtime profile: Allowed service interruption and cutover window constraints.
- Compliance profile: Security, audit, and regulatory boundaries.
How to classify a migration request
Section titled “How to classify a migration request”- Identify the primary migration object.
- Determine workload state profile and criticality.
- Capture connectivity and transfer constraints.
- Define boundary conditions for downtime, consistency, and compliance.
- Assign the request to a use-case category and record assumptions.
Use-case catalog and boundaries
Section titled “Use-case catalog and boundaries”1. Application runtime migration
Section titled “1. Application runtime migration”- Includes: Application stack migration (including VM-centered migrations).
- Primary objective: Transition application runtimes with predictable cutover and operating handover.
Mandatory boundaries:
- Dependency clarity: Integration dependencies and transition windows must be known.
- Cutover model: Interruption model and decision gates must be approved.
- Rollback readiness: Triggers and ownership must be defined.
2. Container platform migration
Section titled “2. Container platform migration”- Includes: Kubernetes to Kubernetes migration.
- Primary objective: Transition containerized workloads to target cluster models.
Mandatory boundaries:
- State classification: Stateless/stateful boundaries must be explicit per component.
- State portability: Storage and database compatibility must be validated.
- Traffic control: Progressive switch capability must be confirmed.
3. Data migration
Section titled “3. Data migration”- Includes: Large file data migration and database/data platform transitions.
- Primary objective: Transition data sets with controlled consistency and integrity.
Mandatory boundaries:
- Connectivity feasibility: Required endpoint reachability must be validated.
- Consistency model: Freeze windows, delta strategy, and validation methods must be defined.
- Performance feasibility: Throughput profile and run limits must be validated.
4. Identity and access migration
Section titled “4. Identity and access migration”- Primary objective: Transition identity trust and access models without security regression.
Mandatory boundaries:
- Trust model mapping: Federation, SSO, and token flows must be mapped.
- Authorization mapping: Role and entitlement mapping must be validated.
- Credential transition: Secret rotation and emergency access paths must be approved.
5. Network and connectivity migration
Section titled “5. Network and connectivity migration”- Primary objective: Transition communication paths and security boundaries between environments.
Mandatory boundaries:
- Addressing and routing: IP planning and route ownership must be defined.
- Control policy parity: Firewall and segmentation policies must be aligned.
- Name resolution continuity: DNS transition behavior must be planned.
6. Integration and API migration
Section titled “6. Integration and API migration”- Primary objective: Transition service interfaces and integration patterns without breaking consumers.
Mandatory boundaries:
- Contract compatibility: Versioning and compatibility strategy must be explicit.
- Dependency sequencing: Producer/consumer switch order must be managed.
- Message semantics: Ordering, retries, and repeat-safe behavior assumptions must be validated.
7. Security and compliance controls migration
Section titled “7. Security and compliance controls migration”- Primary objective: Preserve or improve control effectiveness and audit readiness during transition.
Mandatory boundaries:
- Control mapping: Required controls and evidence points must be mapped.
- Key and certificate handling: Cryptographic material transition must be governed.
- Audit continuity: Logging and evidence retention obligations must remain intact.
8. Operations and observability migration
Section titled “8. Operations and observability migration”- Primary objective: Ensure operational control and incident response readiness after migration.
Mandatory boundaries:
- Observability baseline: Metrics, logs, traces, and alerts must be active before cutover.
- Operating ownership: On-call and escalation paths must be assigned.
- Service objectives: SLO/SLA targets and thresholds must be defined.
9. Delivery and resilience migration
Section titled “9. Delivery and resilience migration”- Primary objective: Transition software delivery and resilience capabilities to target operations.
Mandatory boundaries:
- Pipeline continuity: CI/CD and release controls must remain auditable.
- Recovery readiness: Backup/restore and DR assumptions must be validated.
- Automation safety: Guardrails for deployment automation must be in place.
Cross-case decision criteria
Section titled “Cross-case decision criteria”- Downtime target: Planned downtime window versus continuous availability expectation.
- Consistency requirement: Eventual consistency, near-real-time, or strict transactional consistency.
- Change tolerance: How much architecture and application change is acceptable in the current wave.
- Automation level: Manual, semi-automated, or fully automated run path.
- Risk and reversibility: Ability to detect failure fast and revert without business-critical impact.
Concrete asset templates
Section titled “Concrete asset templates”The implementation details are maintained in dedicated asset pages. This keeps the overview page category-focused and allows concrete templates to evolve independently.
Application with VM runtime
Section titled “Application with VM runtime”Asset title
Framework
Asset type
Migration
Runbook
Large data migration to STACKIT file service
Section titled “Large data migration to STACKIT file service”Asset title
Framework
Asset type
Migration
Runbook
Migration
Runbook
Kubernetes to Kubernetes migration
Section titled “Kubernetes to Kubernetes migration”Asset title
Framework
Asset type
Architecture
Guide
Migration
Runbook
Migration
Blueprint
Architecture
Guide
Advisory
Workshop
Data and AI
Guide
Migration
Runbook
Data and AI
Blueprint
Data and AI
Blueprint
Data and AI
Blueprint
Migration
Runbook
Migration
Runbook
Migration
Runbook
Architecture
Service
Migration
Service
Adoption
Service
Architecture
Service
Architecture
Service
Advisory
Service
Select the Target Pattern and Runtime
Why this page exists
Section titled “Why this page exists”The Design module decides how an application should run on STACKIT before migration runs start. This page focuses on application-level target architecture decisions, not on landing-zone foundation topics.
What a good application design must answer
Section titled “What a good application design must answer”For each application, the target design should answer these core questions:
- Workload model: Should the application run on VM, Kubernetes, Cloud Foundry, static delivery, or a SaaS target?
- Service model fit: Which service model (IaaS, PaaS, SaaS) best balances control, speed, and operational load?
- State and data path: How are data consistency, cutover sequence, and rollback handled?
- Operations model: Which team owns Day-1/Day-2 operations, alerting, backup, and incident response?
- Risk controls: Which architecture decisions are mandatory, optional by exception, or explicitly out of scope?
Service model decision guide (IaaS, PaaS, SaaS)
Section titled “Service model decision guide (IaaS, PaaS, SaaS)”Use this as a practical orientation for application design:
- Choose IaaS when: You need deep OS/runtime control, legacy dependencies, or custom networking constraints that managed platforms cannot satisfy.
- Choose PaaS when: You want faster delivery and lower operations burden while keeping application ownership and portability goals.
- Choose SaaS when: The business process can adopt a standard product model and differentiation does not require custom platform operation.
Do not choose based on team habit only. Choose based on measurable requirements, operating capacity, and life cycle goals.
Runtime selection guide for typical STACKIT targets
Section titled “Runtime selection guide for typical STACKIT targets”VM runtime (IaaS)
Best for low-change migrations and components needing OS-level control, custom agents, or strict legacy compatibility.
Kubernetes runtime (PaaS-like ops model)
Best for containerized workloads needing controlled scalability, release automation, and standardized platform operations.
Cloud Foundry runtime (PaaS)
Best when teams prioritize developer productivity and fast app delivery over low-level platform control.
Static delivery with Object Storage/CDN
Best for frontend/static workloads with high distribution needs and minimal backend runtime complexity.
SaaS replacement path
Best when process fit and standard capabilities provide higher value than migrating and operating the existing application stack.
Design guardrails for application architecture
Section titled “Design guardrails for application architecture”- Always do: Define target runtime, data ownership, rollback triggers, and Day-1 operations before approving migration.
- Use by exception: Temporary dual-run, manual handovers, or partial automation only with explicit risk and end-date.
- Avoid: Mixing runtime switch, data migration, and major integration changes in one uncontrolled cutover step.
- Never do: Approve a target design without observability baseline, backup/recovery model, and named operational ownership.
Practical design workflow per application
Section titled “Practical design workflow per application”- Confirm application scope, dependencies, and non-functional requirements.
- Decide service model fit (IaaS, PaaS, SaaS) and shortlist valid runtime targets.
- Select one target pattern and document why alternatives were rejected.
- Define data path, cutover sequence, validation checks, and rollback logic.
- Capture operations ownership, monitoring baseline, and handover criteria.
- Translate architecture decisions into the migration runbook blueprint.
Typical STACKIT design options
Section titled “Typical STACKIT design options”VM pattern with operational baseline
Spring Boot on VM with Application Load Balancer, observability integration, and backup strategy.
Kubernetes platform pattern
Spring Boot on SKE with managed data services, object storage, secrets handling, and messaging.
Static delivery with CDN option
Static content delivery from Object Storage with optional CDN acceleration for internet-facing use cases.
Hybrid connectivity pattern
Workload access through VPN and central firewall controls for enterprise network integration.
Cloud Foundry pattern
Spring Boot on Cloud Foundry with backing services such as Redis and RabbitMQ.
Use the pattern cards as candidate architectures and select one explicit target per application. Do not combine multiple patterns unless coexistence is a deliberate transitional state.
Best practices for target design on STACKIT
Section titled “Best practices for target design on STACKIT”- Separate architecture and runbook concerns: define the target architecture first, then derive migration sequencing and rollback steps.
- Design for operations from day one: include observability signals, alerting boundaries, and backup or recovery expectations in the target state.
- Use managed platform capabilities intentionally: prefer managed services where they reduce operational load without forcing unnecessary code change.
- Define network trust boundaries explicitly: document ingress, egress, east-west controls, and hybrid connectivity needs before implementation.
- Treat secrets and access controls as design inputs: include IAM roles, service accounts, and Secret Manager usage in the initial architecture package.
- Keep state migration independent from runtime switch: for stateful workloads, validate data migration gates apart from runtime cutover gates.
- Add measurable acceptance criteria: availability, latency, scaling behavior, and recovery objectives should be testable before handover.
Related design pages
Section titled “Related design pages”Architecture assets
Section titled “Architecture assets”Use these architecture assets as concrete design references.
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
Runnable migration examples (existing)
Section titled “Runnable migration examples (existing)”Asset title
Framework
Asset type
Migration
Runbook
Migration
Runbook
Migration
Runbook
Use the architecture assets to select and justify a target pattern, then use the runbook assets to run the migration path.
Why this page exists
Section titled “Why this page exists”The Design module decides how an application should run on STACKIT before migration runs start. This page focuses on application-level target architecture decisions, not on landing-zone foundation topics.
What a good application design must answer
Section titled “What a good application design must answer”For each application, the target design should answer these core questions:
- Workload model: Should the application run on VM, Kubernetes, Cloud Foundry, static delivery, or a SaaS target?
- Service model fit: Which service model (IaaS, PaaS, SaaS) best balances control, speed, and operational load?
- State and data path: How are data consistency, cutover sequence, and rollback handled?
- Operations model: Which team owns Day-1/Day-2 operations, alerting, backup, and incident response?
- Risk controls: Which architecture decisions are mandatory, optional by exception, or explicitly out of scope?
Service model decision guide (IaaS, PaaS, SaaS)
Section titled “Service model decision guide (IaaS, PaaS, SaaS)”Use this as a practical orientation for application design:
- Choose IaaS when: You need deep OS/runtime control, legacy dependencies, or custom networking constraints that managed platforms cannot satisfy.
- Choose PaaS when: You want faster delivery and lower operations burden while keeping application ownership and portability goals.
- Choose SaaS when: The business process can adopt a standard product model and differentiation does not require custom platform operation.
Do not choose based on team habit only. Choose based on measurable requirements, operating capacity, and life cycle goals.
Runtime selection guide for typical STACKIT targets
Section titled “Runtime selection guide for typical STACKIT targets”VM runtime (IaaS)
Best for low-change migrations and components needing OS-level control, custom agents, or strict legacy compatibility.
Kubernetes runtime (PaaS-like ops model)
Best for containerized workloads needing controlled scalability, release automation, and standardized platform operations.
Cloud Foundry runtime (PaaS)
Best when teams prioritize developer productivity and fast app delivery over low-level platform control.
Static delivery with Object Storage/CDN
Best for frontend/static workloads with high distribution needs and minimal backend runtime complexity.
SaaS replacement path
Best when process fit and standard capabilities provide higher value than migrating and operating the existing application stack.
Design guardrails for application architecture
Section titled “Design guardrails for application architecture”- Always do: Define target runtime, data ownership, rollback triggers, and Day-1 operations before approving migration.
- Use by exception: Temporary dual-run, manual handovers, or partial automation only with explicit risk and end-date.
- Avoid: Mixing runtime switch, data migration, and major integration changes in one uncontrolled cutover step.
- Never do: Approve a target design without observability baseline, backup/recovery model, and named operational ownership.
Practical design workflow per application
Section titled “Practical design workflow per application”- Confirm application scope, dependencies, and non-functional requirements.
- Decide service model fit (IaaS, PaaS, SaaS) and shortlist valid runtime targets.
- Select one target pattern and document why alternatives were rejected.
- Define data path, cutover sequence, validation checks, and rollback logic.
- Capture operations ownership, monitoring baseline, and handover criteria.
- Translate architecture decisions into the migration runbook blueprint.
Typical STACKIT design options
Section titled “Typical STACKIT design options”VM pattern with operational baseline
Spring Boot on VM with Application Load Balancer, observability integration, and backup strategy.
Kubernetes platform pattern
Spring Boot on SKE with managed data services, object storage, secrets handling, and messaging.
Static delivery with CDN option
Static content delivery from Object Storage with optional CDN acceleration for internet-facing use cases.
Hybrid connectivity pattern
Workload access through VPN and central firewall controls for enterprise network integration.
Cloud Foundry pattern
Spring Boot on Cloud Foundry with backing services such as Redis and RabbitMQ.
Use the pattern cards as candidate architectures and select one explicit target per application. Do not combine multiple patterns unless coexistence is a deliberate transitional state.
Best practices for target design on STACKIT
Section titled “Best practices for target design on STACKIT”- Separate architecture and runbook concerns: define the target architecture first, then derive migration sequencing and rollback steps.
- Design for operations from day one: include observability signals, alerting boundaries, and backup or recovery expectations in the target state.
- Use managed platform capabilities intentionally: prefer managed services where they reduce operational load without forcing unnecessary code change.
- Define network trust boundaries explicitly: document ingress, egress, east-west controls, and hybrid connectivity needs before implementation.
- Treat secrets and access controls as design inputs: include IAM roles, service accounts, and Secret Manager usage in the initial architecture package.
- Keep state migration independent from runtime switch: for stateful workloads, validate data migration gates apart from runtime cutover gates.
- Add measurable acceptance criteria: availability, latency, scaling behavior, and recovery objectives should be testable before handover.
Related design pages
Section titled “Related design pages”Architecture assets
Section titled “Architecture assets”Use these architecture assets as concrete design references.
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
Runnable migration examples (existing)
Section titled “Runnable migration examples (existing)”Asset title
Framework
Asset type
Migration
Runbook
Migration
Runbook
Migration
Runbook
Use the architecture assets to select and justify a target pattern, then use the runbook assets to run the migration path.
Prepare the Runbook and Cutover
Why a Runbook Is a Design Output
Section titled “Why a Runbook Is a Design Output”In this framework, the runbook is produced in the Design phase. It captures the intended run path, controls, rollback logic, and handover criteria per migration strategy.
Migration Factory Setup does not create the first runbook version. It operationally hardens, standardizes, and validates Design runbook drafts for wave-scale delivery.
Mandatory Runbook Chapters
Section titled “Mandatory Runbook Chapters”Every migration runbook should include these chapters:
- Scope and context: Application scope, source and target context, assumptions, exclusions.
- Owners and decision rights: Technical owner, release owner, rollback authority, escalation path.
- Dependencies and prerequisites: Platform readiness, access, data state, external system windows.
- Cutover plan: Ordered run steps, expected duration, freeze points, communication points.
- Validation checks: Functional, non-functional, security, and observability checks with evidence.
- Rollback and contingency: Trigger conditions, rollback steps, fallback communication flow.
- Handover and Day-1 operations: Operations transfer, incident ownership, post-cutover watch period.
Quality Criteria for a Good Runbook
Section titled “Quality Criteria for a Good Runbook”Executable
Steps are concrete, ordered, and assignable to named roles.
Verifiable
Validation points define clear pass/fail criteria and required evidence.
Recoverable
Rollback path is complete, timed, and linked to explicit trigger conditions.
Handover-ready
Day-1 operations and ownership transfer are fully specified.
Suggested Design-to-Factory Flow
Section titled “Suggested Design-to-Factory Flow”- Create strategy-specific runbook draft during Design.
- Validate technical assumptions with platform, security, and operations stakeholders.
- Add evidence checkpoints and rollback triggers.
- Hand over to Migration Factory Setup for standardization and readiness checks.
- Approve for wave execution after rehearsal or pilot validation.
Concrete Example Asset
Section titled “Concrete Example Asset”Use this concrete sample runbook asset for a classic Rehost case (Spring Boot to VM):
Asset title
Framework
Asset type
Migration
Runbook
- Pattern: Lift-and-shift to target VM (no Kubernetes)
- App type: Typical enterprise Spring Boot service with PostgreSQL backend
Why a Runbook Is a Design Output
Section titled “Why a Runbook Is a Design Output”In this framework, the runbook is produced in the Design phase. It captures the intended run path, controls, rollback logic, and handover criteria per migration strategy.
Migration Factory Setup does not create the first runbook version. It operationally hardens, standardizes, and validates Design runbook drafts for wave-scale delivery.
Mandatory Runbook Chapters
Section titled “Mandatory Runbook Chapters”Every migration runbook should include these chapters:
- Scope and context: Application scope, source and target context, assumptions, exclusions.
- Owners and decision rights: Technical owner, release owner, rollback authority, escalation path.
- Dependencies and prerequisites: Platform readiness, access, data state, external system windows.
- Cutover plan: Ordered run steps, expected duration, freeze points, communication points.
- Validation checks: Functional, non-functional, security, and observability checks with evidence.
- Rollback and contingency: Trigger conditions, rollback steps, fallback communication flow.
- Handover and Day-1 operations: Operations transfer, incident ownership, post-cutover watch period.
Quality Criteria for a Good Runbook
Section titled “Quality Criteria for a Good Runbook”Executable
Steps are concrete, ordered, and assignable to named roles.
Verifiable
Validation points define clear pass/fail criteria and required evidence.
Recoverable
Rollback path is complete, timed, and linked to explicit trigger conditions.
Handover-ready
Day-1 operations and ownership transfer are fully specified.
Suggested Design-to-Factory Flow
Section titled “Suggested Design-to-Factory Flow”- Create strategy-specific runbook draft during Design.
- Validate technical assumptions with platform, security, and operations stakeholders.
- Add evidence checkpoints and rollback triggers.
- Hand over to Migration Factory Setup for standardization and readiness checks.
- Approve for wave execution after rehearsal or pilot validation.
Concrete Example Asset
Section titled “Concrete Example Asset”Use this concrete sample runbook asset for a classic Rehost case (Spring Boot to VM):
Asset title
Framework
Asset type
Migration
Runbook
- Pattern: Lift-and-shift to target VM (no Kubernetes)
- App type: Typical enterprise Spring Boot service with PostgreSQL backend
Business Case
Migration Plan
Landing Zone
Purpose
Section titled “Purpose”Account governance defines how you separate environments, teams, and responsibilities in a way that remains auditable and scalable.
It creates the organizational control plane for migration waves: where workloads are hosted, who owns which scope, and how new projects are added without bypassing guardrails.
Governance hierarchy
Section titled “Governance hierarchy”
Governance design and delivery
Section titled “Governance design and delivery”Core governance building blocks
Section titled “Core governance building blocks”- Regions: Region strategy determines data locality, latency profile, and resilience boundaries for workloads and shared services. Define region usage principles early and align them with compliance and continuity requirements. Documentation
- Customer Account: The customer account is the top governance boundary for ownership, billing, and administration. It is the anchor for organization-wide standards and control responsibilities. Documentation
- STACKIT Folder: Folders structure organizational domains (for example platform, shared services, business units, environments) and allow policy inheritance and clean delegation models. Resource Manager
- STACKIT Projects: Projects are the delivery scopes where resources are deployed and operated. They should be attached to folders through a defined onboarding model, not created ad hoc. Resource Manager
How these elements work together
Section titled “How these elements work together”- Region principles first: Define which regions are allowed for which workload classes.
- Customer account as governance root: Set global ownership, policy intent, and financial accountability.
- Folders for structure and delegation: Translate the operating model into scalable organizational boundaries.
- Projects for delivery: Provision project scopes through a standard lifecycle with mandatory controls inherited from the folder model.
Key design decisions
Section titled “Key design decisions”- Region governance model: Decide single-region, dual-region, or workload-based region strategy and required exceptions.
- Customer-account responsibilities: Define which central teams own governance, billing oversight, and control operations.
- Folder topology: Decide how folders map to domains such as platform, environments, and business units.
- Project onboarding model: Standardize project creation, naming, tagging, and lifecycle controls.
- Policy and exceptions: Define mandatory guardrails and transparent exception workflows.
Typical outputs
Section titled “Typical outputs”- Governance blueprint: Customer-account, folder, and project topology with ownership matrix.
- Region usage policy: Approved region patterns per workload type and risk profile.
- Project onboarding standard: Repeatable process for creating and connecting governed projects.
- Control baseline: Enforced naming, tagging, and policy controls with documented exception flow.
Related Target Operating Model guidance
Section titled “Related Target Operating Model guidance”Governance and Decision Making assigns decision rights and escalation paths for these account, folder, and project boundaries.
Anti-patterns to avoid
Section titled “Anti-patterns to avoid”- No region policy: Region selection per team or project without enterprise rules.
- Unstructured project sprawl: Projects created without folder strategy, ownership clarity, or lifecycle standards.
- Governance only on paper: Controls documented but not embedded in project onboarding and operations.
Purpose
Section titled “Purpose”Network architecture defines how workloads communicate securely, how traffic is segmented, and how central connectivity services are governed across shared and project-specific landing zones.
In most enterprise migrations, this topic is less about individual subnets and more about operating a controlled connectivity model over time: who connects which project, via which paths, and under which guardrails.
Reference topology
Section titled “Reference topology”
Connectivity design and delivery
Section titled “Connectivity design and delivery”Core connectivity building blocks
Section titled “Core connectivity building blocks”- STACKIT Network Area: Use a shared enterprise network scope as the central backbone for project connectivity planning and governance. Documentation
- Routing Tables: Define and enforce how projects inside a Network Area are connected and whether the architecture should follow a hub-and-spoke model with central firewall controls or a flatter topology. Documentation
- DNS: Standardize naming and service discovery early so connectivity design, certificate handling, and workload cutovers are consistent. Documentation
- VPN (Connectivity): Treat VPN as a central connectivity capability for hybrid and multi-cloud integration patterns, not as an isolated point solution. Documentation
Confirm the product connectivity boundaries before choosing a topology. Network Area scope, route precedence, and VPN gateway behavior constrain the design; they do not replace the workload connectivity matrix or security approval.
From the STACKIT docsConcepts
The source shows pictures here that this page leaves out (1). See them in Concepts
The STACKIT Network Area (SNA) allows projects within an organization to be connected to each other on a network level. This makes it possible to connect various resources of the projects within an SNA and also simplifies the connection with on-prem environments (hybrid cloud).
An SNA project differs from a public project in the fact that it is connected to an internal transfer network. When creating a network in a SNA project, the address range is defined using the specified prefix length from the network ranges of the SNA. To make the connectivity within the SNA projects available, the project router gets connected to the SNA transfer network. When editing the networks of SNA projects, the routing table of all project routers is automatically adjusted, no manual adjustment is necessary. Access control at network level is carried out exclusively by security groups, all incoming traffic is denied by default.
SNA is a global resource which you need to enable for the regions you want to use it in. Currently traffic between regions is only possible via the public internet. Private connectivity between regions inside of an SNA is planned for the future.
Example topology of an SNA with 2 projects:
What is this?
This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.
From the STACKIT docsRouting tables › Route types and priorities
Routing tables consist of different types of routes serving different purposes and having a different priority in the overall routing context. Route types with a higher priority value are preferred over lower priority ones if they have the same prefix length. If routes of the same route type have the same prefix length, equal-cost-multi-path (ECMP) is performed.
| priority | route type | description |
|---|---|---|
| 4 | system routes | System routes are automatically generated routes for connectivity between projects inside an SNA. System routes are enabled by default for routing tables but can be disabled to manage traffic and isolation within a network environment. |
| 3 | service routes | Service routes are routes which are added by a STACKIT service to reach it. Service routes are always enabled and can’t be disabled/removed by the user directly. |
| 2 | static routes | Static routes are routes which are added by a user. They can have different next-hops such as an IP-address, black hole or the internet. |
| 1 | dynamic routes | Dynamic routes are routes which are learned through a dynamic routing protocol like BGP. Dynamic routes are enabled by default for routing tables but can be disabled. |
What is this?
This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.
From the STACKIT docsProduct overview
A Virtual Private Network (VPN) with STACKIT creates a secure, encrypted connection over the internet between your remote network and your STACKIT Network Area (SNA). This secure tunnel allows data to be transmitted safely, protecting it from eavesdropping, interception, or unauthorized access.
With STACKIT VPN, you can securely connect to your STACKIT Network Area, enabling access to its resources as if you were directly connected to the remote network. This capability is particularly useful for accessing services, applications, and data within the SNA from remote locations, ensuring both privacy and security in all communications.
A STACKIT VPN typically consists of two key components; the VPN gateway and the VPN connection:
- VPN gateway:
The VPN gateway in STACKIT serves as the access point to the SNA from the internet. It is the gateway through which encrypted traffic flows between your SNA and your remote data center or private network. In an high available active-active setup the VPN gateway internally consists of two instances. The VPN gateway hosts the VPN connections. - VPN connection:
The VPN connection is the encrypted tunnels being established between the STACKIT VPN gateway and your remote gateway. It utilizes advanced encryption protocols and techniques to ensure that all data transmitted between your local data center and the STACKIT SNA remains confidential and intact, effectively preventing unauthorized access or data breaches. In an high available active-active setup each of the two VPN gateway instances establish a tunnel to the same remote site.
STACKIT VPN is an essential tool for securely connecting distributed resources, enabling remote access to cloud-based services while maintaining the integrity and privacy of your data within the STACKIT cloud environment.
What is this?
This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.
Key design decisions
Section titled “Key design decisions”- Network Area ownership model: Decide who centrally governs shared connectivity and onboarding criteria for projects attaching to the Network Area.
- Routing strategy per domain: Decide where hub-and-spoke with central inspection is mandatory and where simpler flat routing is acceptable.
- Hybrid connectivity baseline: Define how VPN-based connectivity is integrated into platform standards and lifecycle operations.
- Name-resolution design: Standardize DNS boundaries and patterns for platform services, shared services, and application landing zones.
Typical outputs
Section titled “Typical outputs”- Target topology and trust boundaries: A documented target state for segmentation and cross-project communication.
- Network Area onboarding principles: Clear criteria for which projects are attached, how they are reviewed, and how changes are approved.
- Routing governance model: Defined use of Routing Tables including hub-and-spoke versus flat routing decision criteria.
- Connectivity baseline: Reusable standards for VPN, DNS, and shared network services.
Asset container references
Section titled “Asset container references”Asset title
Framework
Asset type
Migration
Software
Architecture
Service
Anti-patterns to avoid
Section titled “Anti-patterns to avoid”- Unplanned Network Area growth: Connecting projects without central architecture review and ownership.
- Routing Tables used ad hoc: Inconsistent route logic per project with no reference architecture.
- DNS treated as afterthought: Late-stage DNS decisions that break migration timelines or service discovery.
- VPN as exception path: Managing VPN as one-off workaround instead of governed connectivity foundation.
STACKIT Landing Zone Accelerator
Enablement
Prepare migration teams through CCoE ownership, role-based STACKIT University learning, trusted documentation, and validated AI guidance.
Migrate
Keep this as concise as Assess and focus on the end-to-end factory flow that runs every wave to completion.
Understanding the Migrate module
Section titled “Understanding the Migrate module”This module executes the actual migration delivery in the Migration Factory. By this point, design decisions are approved, landing zones are ready, and wave plans are defined.
Migrate focuses on repeatable technical run patterns for:
- Relocate: Move workloads with minimal change in platform assumptions.
- Rehost: Lift and shift workloads to STACKIT with controlled cutover and rollback readiness.
- Replatform: Apply targeted platform changes during migration without a full application redesign.
Upstream dependencies
Section titled “Upstream dependencies”Migrate starts after Design and Mobilize has produced implementable inputs:
- Application design per workload: Target-state scope, interface decisions, data handling, and non-functional requirements are defined.
- Wave assignment: Every workload is assigned to an approved migration wave with timing and dependency logic.
- Runbook availability: A validated runbook exists per migration path and workload archetype, including go/no-go, cutover, and rollback criteria.
- Application Landing Zone mapping: Workloads are mapped to the correct target landing zone and ownership model.
- Decision and communication model: Decision paths, escalation process, and communication with the Application Owner are defined, including whether cutover must be performed jointly.
Reference modules:
End-to-end factory flow
Section titled “End-to-end factory flow”- Confirm wave scope, cutover window, rollback criteria, and runbook ownership.
- Freeze wave baseline (application version, dependencies, data scope, and interface contracts).
- Run pre-migration technical readiness checks in source and target environments.
- Run migration runbook steps per workload archetype and R-strategy path.
- Perform cutover and route traffic to the STACKIT target according to the wave plan.
- Validate technical, functional, and operational acceptance criteria.
- Stabilize incidents and known defects in short feedback loops.
- Hand over stabilized workloads to Optimize and Operate.
Run path by migration path
Section titled “Run path by migration path”Relocate flow
Section titled “Relocate flow”- Recreate workload placement in STACKIT with equivalent topology assumptions.
- Migrate data and state with consistency checks.
- Cut over traffic with rollback guardrails.
- Validate business continuity and operational telemetry.
Rehost flow
Section titled “Rehost flow”- Move application and data components largely unchanged.
- Reconfigure infrastructure bindings and connectivity on STACKIT.
- Run controlled cutover and smoke tests.
- Complete stabilization and baseline performance validation.
Replatform flow
Section titled “Replatform flow”- Introduce selected managed services or platform capabilities during migration.
- Adapt configuration, deployment packaging, and operational controls.
- Cut over with compatibility and data integrity checks.
- Validate SLO behavior and operating model readiness.
Core outputs per wave
Section titled “Core outputs per wave”Runbook evidence
Completed runbook records, decision logs, and rollback checkpoints for each migrated workload.
Cutover report
Time-stamped cutover outcome with acceptance results, defects, and mitigation actions.
Operational baseline
Initial monitoring, alerting, ownership, and incident procedures in the target setup.
Optimize backlog
Structured list of rightsizing, performance, and cost measures for post-cutover tuning.
Boundary to optimize, repurchase, and refactor
Section titled “Boundary to optimize, repurchase, and refactor”- Optimize starts directly after stable cutover and uses production telemetry to tune performance and cost: Optimize.
- Repurchase follows a different SaaS transition logic and is treated as a dedicated module outside wave-based factory mechanics: Repurchase.
- Refactor is typically run as a separate transformation stream: Refactor.
Post-cutover care can overlap with Optimize after cutover, but it is handled in the Run phase.
Optimize
Keep this concise: Optimize turns freshly migrated workloads into cost- and performance-tuned steady-state services.
Understanding the Optimize module
Section titled “Understanding the Optimize module”Optimize starts when workloads run on STACKIT and real operating data is available. The module converts post-cutover observations into measurable improvements for performance, stability, and cost efficiency.
Optimize is not a one-time task. It is an iterative cycle that can overlap with early stabilization and post-cutover care.
Why optimization happens after migration
Section titled “Why optimization happens after migration”Many right-sizing and tuning decisions are only reliable under real load patterns. After cutover, teams can use production telemetry to separate assumptions from actual behavior.
Optimization loop
Section titled “Optimization loop”- Collect runtime evidence: utilization, latency, error rates, throughput, and cost drivers.
- Identify bottlenecks and waste patterns at workload, platform, and data layers.
- Prioritize actions by business impact, risk reduction, and FinOps effect.
- Implement tuning changes in controlled increments.
- Validate outcomes against SLO, reliability, and cost targets.
- Feed lessons learned into future migration waves and operating standards.
Typical optimization focus areas
Section titled “Typical optimization focus areas”- Rightsizing: Align compute, storage, and network capacity with actual demand profiles.
- Performance tuning: Improve latency and throughput through configuration, scaling, and architecture adjustments.
- Reliability hardening: Reduce incident frequency through better resilience, observability, and failure handling.
- FinOps controls: Improve cost transparency, remove waste, and optimize run-rate efficiency.
From theory to implementation
Section titled “From theory to implementation”Optimization decisions should be based on runtime evidence, not assumptions. For practical implementation, combine workload telemetry, alerting, and controlled infrastructure changes.
- Managed observability baseline: Use STACKIT Observability to collect metrics, logs, and traces with Grafana, Prometheus, Thanos, Loki, and Tempo.
- Detection logic: Define explicit thresholds and observation windows for low utilization and overload conditions.
- Run path: Apply rightsizing through IaC changes (for example VM flavor changes) with rollback checkpoints.
- Validation loop: Re-measure SLO, error rates, and run-cost after each tuning increment.
Concrete example asset
Section titled “Concrete example asset”Asset title
Framework
Asset type
Migration
Runbook
Migration
Runbook
Migration
Runbook
Migration
Runbook
Replatform optimization dimensions
Section titled “Replatform optimization dimensions”For Replatform workloads on Kubernetes, optimization spans multiple layers and should be coordinated as one control loop.
- Pod scaling: Use HPA to adapt replica count to workload pressure with explicit min/max limits.
- Node pool scaling: Keep sufficient cluster headroom and tune machine type (flavor) for CPU/memory density requirements.
- Ingress scaling: Re-evaluate load balancer service plan when ingress throughput or connection behavior becomes a bottleneck.
- Storage rightsizing: Select storage classes based on performance requirements for persistent workloads.
- Validation discipline: Re-check latency, error rate, and cost after every incremental tuning change.
Inputs and outputs
Section titled “Inputs and outputs”Primary inputs
Cutover reports, incident trends, SLO measurements, telemetry baselines, and cost reports.
Optimization outputs
Prioritized improvement backlog, validated tuning changes, and updated runbook standards.
Governance outcome
Clear trade-off decisions between performance, resilience, and cost with documented ownership.
Boundary to other modules
Section titled “Boundary to other modules”Run
Close the journey briefly with the Run phase module map so the audience sees where migration outcomes ultimately land.
Understanding this phase
Section titled “Understanding this phase”Run is the target state of the migration journey: workloads run on STACKIT with defined ownership, stable operations, and measurable service quality.
The phase starts with post-cutover stabilization and extends into long-term cloud operations. It is where migration outcomes are translated into durable operational performance.
Position in the framework
Section titled “Position in the framework”Run is not just a follow-up activity. It is the strategic destination behind migration run. For many programs, the practical objective is clear: maximize the share of workloads that run reliably in a “Runs on STACKIT” operating state.
Run connects to Migrate through Hypercare and extends the Target Operating Model into real day-to-day service operations.
When Run starts and ends
Section titled “When Run starts and ends”- Start with Hypercare directly after cutover, while migration and project teams are still reachable.
- Close operational gaps, including missing monitoring, alerting, and runbook refinements.
- Formalize handover to DevOps ownership or a dedicated operations team.
- Establish support and service request responsibilities between customer and provider.
- Continue in steady-state run with continuous optimization and regular operating model validation.
Operating Model Handover is anchored in Migrate and can overlap with migration waves before Run starts.
Run phase module map
Section titled “Run phase module map”Run combines short-term stabilization and long-term service operations. The following model visualizes the intended flow from migration handoff to stable day-2 operations.
Semantic map
Section titled “Semantic map”The Run model uses four semantic streams to clarify ownership and purpose:
- Stabilization stream: Hypercare resolves post-cutover risks while delivery teams are still available.
- Operations stream: Operate secures reliability, security, observability, and controlled change in steady-state service run.
- Service stream: Support defines who handles incidents and which requests are provider-managed versus customer-managed.
- Value stream: Customer Success keeps adoption and outcomes aligned over time.
Why this phase matters
Section titled “Why this phase matters”Bridge from project to operations
Hypercare ensures unresolved migration topics are stabilized before they become recurring incidents.
Clear ownership and support model
Defined responsibilities for incidents and service requests reduce friction and escalation loops.
Operational resilience
Monitoring, observability, and runbook maturity improve reliability and recovery behavior.
Sustained value realization
Continuous service improvement keeps performance, cost, and user outcomes aligned with business goals.
Core modules in this phase
Section titled “Core modules in this phase”- Hypercare: Stabilization bridge from Migrate to Run with fast feedback and controlled remediation.
- Operate: Steady-state cloud operations for reliability, security, and efficiency on STACKIT.
- Support: Incident and service request model across customer and provider responsibilities.
- Customer Success: Value stream with a central contact model for adoption and outcome tracking.
Typical outcomes
Section titled “Typical outcomes”At the end of the initial Run establishment, teams should have:
- Stabilized post-cutover service: Critical migration defects are resolved or controlled with agreed actions.
- Closed operational gaps: Missing monitoring, alerting, and operational evidence paths are implemented.
- Validated handover model: DevOps or classical operations ownership is tested in real service scenarios.
- Support model in production use: Incident and request handling paths are active, documented, and measured.
- Durable run governance: Service performance, cost behavior, and improvement backlog are reviewed in regular cadences.
ISV Onboarding Overview
One form on the Marketplace assigns you a dedicated Partner Manager, and a 30-to-45-minute discovery call establishes mutual fit before either side invests engineering or legal time. Bring a business owner and a technical lead — the call covers both.
Understanding the ISV Factory Framework
Section titled “Understanding the ISV Factory Framework”The ISV Factory Framework provides a structured, end-to-end journey designed to seamlessly guide software vendors from initial engagement to full marketplace readiness. Divided into clear phases — ranging from initial onboarding and technical validation to quality assessment and marketplace placement — this framework ensures your solution achieves maximum performance, security, and integration with STACKIT. Explore each step below to understand the key milestones and requirements along your path.
Framework overview
Section titled “Framework overview”The overview below summarizes the ISV journey from first contact to a live Marketplace listing. It helps vendor and STACKIT teams build a shared understanding of deliverables, dependencies, and expected outcomes across all ten phases.
The KickOff phase transitions the partnership from initial qualification into concrete strategy execution. In this step, both teams align on the business model, compute resources, go-to-market approach, and support programs to ensure a viable, scalable product release on the STACKIT Marketplace.
Objectives & Key Stakeholders
Section titled “Objectives & Key Stakeholders”The primary goal of the KickOff meeting is to validate mutual financial and technical feasibility before signing formal contracts.
- STACKIT roles: Partner Manager, Partner Solution Architect
- ISV roles: Business Lead / Product Manager, Lead Architect / CTO
Business Case Inputs Required from the ISV
Section titled “Business Case Inputs Required from the ISV”To construct a realistic business case and define the resource baseline, the ISV provides key parameters regarding product architecture and commercial goals:
| Category | Required information | Purpose |
|---|---|---|
| Pricing & Licensing Model | SaaS subscription, usage-based, BYOL (Bring Your Own License), or tiered pricing. | Defines transaction handling on the STACKIT Marketplace. |
| Resource Footprint | Estimated average and peak compute (vCPU, RAM), storage (NVMe/S3), network bandwidth, and managed services (e.g., STACKIT Postgres/Kubernetes). | Calculates estimated STACKIT infrastructure costs and margin models. |
| Target Audience & Verticals | Specific industries (e.g., public sector, healthcare, finance) or enterprise segments. | Aligns GTM campaigns and compliance/certification requirements. |
| Sales & Revenue Expectations | Projected onboarding pipeline and expected customer sign-ups over 12–24 months. | Validates business viability and eligibility for STACKIT funding programs. |
Partnering & Go-to-Market Models
Section titled “Partnering & Go-to-Market Models”During the KickOff, both parties agree on the structure of the joint go-to-market approach:
1. Co-Selling & Referral
- Joint sales activity where STACKIT field sales recommend the ISV solution to existing enterprise accounts.
- Lead sharing and commission/referral structures agreed upon per transaction type.
2. Marketplace Resell
- STACKIT acts as the merchant of record (or facilitator) on the Marketplace.
- Billing and metering are fully integrated and automated via STACKIT.
Available Funding & Support Incentives
Section titled “Available Funding & Support Incentives”STACKIT supports qualifying ISVs during the onboarding journey to reduce initial development risks:
- PoC Infrastructure Credits: Cloud credits provided to cover STACKIT infrastructure costs during development, testing, and Technical Quality Gates.
- Architectural Support: Direct access to STACKIT Solution Architects for review of cloud-native design, Kubernetes deployment, and security compliance.
- Co-Marketing Support: Joint PR, blog posts, and featured placement opportunities on the STACKIT Marketplace upon launch.
Phase Completion Criteria
Section titled “Phase Completion Criteria”At the end of the KickOff, clear ownership is assigned for the immediate next phase:
- ISV task: Business case inputs finalized and the completed onboarding questionnaire returned.
- STACKIT task: Tailored Partnership Agreement drafted and the Signing phase prepared.
- Joint task: Technical PoC alignment call scheduled following contract execution.
- Milestone achieved: Business case validated — ready to proceed to Signing & Legal Alignment.
Support & Contact
Section titled “Support & Contact”For questions on the business case, funding programs, or go-to-market models, contact your
dedicated STACKIT Partner Manager or the ISV Factory team at
isv-sales@digits.schwarz.
The Technical Proof of Concept (PoC) phase is where your architectural planning becomes reality. The goal of this phase is to deploy a working version of your application on STACKIT to validate technical feasibility, performance, and cost-efficiency before moving toward a production-ready state.
Deployment Strategy & Landing Zone
Section titled “Deployment Strategy & Landing Zone”A critical decision before rolling out your infrastructure is defining your tenant strategy. This decision heavily impacts your STACKIT Organization, Folder, and Project structure:
-
Multitenant Strategy: Multiple customers share the same infrastructure and application instance, separated logically.
-
Customer Dedicated (Single Tenant): Each customer receives an isolated STACKIT Project and infrastructure environment.
Accelerate your setup. To support a fast, automated, and standardized rollout of your cloud environment, STACKIT provides Infrastructure-as-Code (IaC) assets:
- Landing Zone Accelerator — best-practice templates for setting up your STACKIT environment. Dedicated Landing Zone repositories tailored specifically for Multitenant and Customer Dedicated models are planned: github.com/stackitcloud/stackit-landing-zone
- STACKIT GitHub Repositories — open-source projects, Terraform providers, and SDKs: github.com/stackitcloud
Resilience, Scaling, and Compliance
Section titled “Resilience, Scaling, and Compliance”When building your PoC, you must design for growth, stability, and security:
- Scaling: How does your application architecture scale to handle sudden user growth or increased workloads without performance degradation?
- Redundancy & High Availability (HA): Define your availability requirements. Does your application require a Single-Region setup, or do you need a Multi-Region architecture to prevent downtime?
- Compliance (TOMs): By signing the Partner Base Agreement (PBA), your organization technically committed to the Technical and Organizational Measures (TOMs) outlined in Annex 2. Your PoC architecture must reflect and implement these security and data protection standards.
Architectural Blueprinting & Target Design
Section titled “Architectural Blueprinting & Target Design”Once you have defined your deployment model, isolation strategy, and resilience requirements, translate these specifications into a formal Architectural Blueprint.
Mapping your software components (microservices, stateful data, caching layers, external interfaces) directly to STACKIT services — such as SKE, PostgreSQL Flex, Object Storage and STACKIT Network Area — creates a clear target architecture. This blueprint serves as the essential foundation for precise infrastructure cost modeling and subsequent automation via IaC.
Infrastructure Calculation & Cost Tracking
Section titled “Infrastructure Calculation & Cost Tracking”With your Architectural Blueprint defined, model and track your resource consumption against your initial business case estimations:
- Computing Calculator — model your estimated monthly compute, network, and storage footprint for the target PoC architecture: calculator.stackit.cloud/computing
- STACKIT Price List — reference for a complete overview of all SKUs, as some newer platform services may not yet be reflected in the calculator.
Infrastructure as Code (IaC) & CI/CD Pipelines
Section titled “Infrastructure as Code (IaC) & CI/CD Pipelines”To achieve high reliability and low operational overhead, manual infrastructure provisioning via the portal should be avoided for production-grade software. Infrastructure as Code (IaC) is the state-of-the-art industry standard for cloud-native deployment.
Infrastructure as Code
Section titled “Infrastructure as Code”Using declarative tools ensures your infrastructure is repeatable, version-controlled, and audit-ready:
- Primary Tooling: Use the official STACKIT Terraform Provider to declare compute, storage, network, SKE (Kubernetes), and database resources: registry.terraform.io
- Automation-First: Maintain all IaC scripts within version control (e.g., GitHub, GitLab, STACKIT GIT).
- STACKIT Git Pipelines: If you host your repositories on STACKIT Git, the built-in pipelines run your IaC and build workflows next to the code — the first-steps guide walks through the initial runner and workflow setup: docs.stackit.cloud — Pipelines first steps
Recommended CI/CD Pipeline Architecture
Section titled “Recommended CI/CD Pipeline Architecture”A standardized Continuous Integration / Continuous Deployment (CI/CD) pipeline automates the lifecycle of both your infrastructure and application workloads.
- Code Commit & Trigger: Changes to application code or IaC templates trigger the automated pipeline.
- Linting & Static Security Analysis: Validate Terraform configurations (
terraform validate,tflint) and scan container images for vulnerabilities — either by running Trivy directly as a pipeline step, or by relying on the vulnerability scans the STACKIT Container Registry performs on pushed images. Running both gives you a gate in the pipeline and continuous rescanning of images already stored. - Infrastructure Provisioning (IaC Step): Run
terraform planfor automated verification, followed byterraform applyto provision or update STACKIT resources in the target PoC environment. - Workload Deployment: Deploy application containers to STACKIT Kubernetes Engine (SKE) with Helm as the packaging format — either driven by the pipeline through the Terraform Helm provider (keeping infrastructure and workload in one declarative run), or pull-based via a GitOps engine such as Argo CD or Flux that reconciles the chart from your Git repository. Avoid imperative
kubectl applysteps, as they leave no reconcilable desired state. PaaS applications are deployed via Cloud Foundry (cf push). - Automated Integration Testing: Execute smoke tests against the freshly deployed endpoints to verify service availability.
- Secrets Management: Ensure pipeline runners access STACKIT service accounts via short-lived API tokens or integration with STACKIT Secrets Manager — never hardcode API keys or credentials in repositories.
- STACKIT Container Registry: Central registry for your build artifacts, including vulnerability scanning of pushed images: docs.stackit.cloud — Container Registry
Phase Completion Criteria
Section titled “Phase Completion Criteria”The PoC phase is complete when the following milestones are verified:
- Target Architectural Blueprint established and mapped to STACKIT services.
- Application is successfully deployed and running in the STACKIT PoC project.
- Infrastructure provisioning is automated using IaC (e.g., Terraform / Landing Zone Accelerator).
- Tenant isolation strategy (Multitenant or Customer Dedicated) is implemented in the folder/project hierarchy.
- PoC environment costs calculated and discussed with the Partner Manager.
- Automated CI/CD deployment pipeline is established.
- Security and compliance controls (PBA Annex 2 TOMs) are technically validated.
- Milestone achieved: PoC validated — ready to proceed to the ES³ Self Assessment.
Support & Contact
Section titled “Support & Contact”Throughout the PoC phase, use the following resources to support your development:
- STACKIT Knowledge Base — technical documentation, API references, and practical tutorials: docs.stackit.cloud
- STACKIT Status Page — real-time information on platform availability and system maintenance: status.stackit.cloud
Need assistance? If you encounter technical blockers during your PoC, contact your Partner
Manager or the ISV Factory team at isv-sales@digits.schwarz.
The European Sovereign Stack Standard (ES³) is STACKIT’s digital sovereignty program. It makes the otherwise vague concept of digital sovereignty objectively measurable, in a market where “sovereignty washing” and vague marketing promises are common. Its operational engine is the Sovereignty Maturity Level (SML) Framework, an auditable assessment framework whose criteria have been verified by the independent auditing firm BDO.
The framework follows three guiding principles:
- Auditability: assessments must be evidence-based, comprehensible, and reproducible.
- SML classification: maturity levels are assigned based on defined mandatory controls per level.
- Comparability: results are comparable between services and providers, and over time.
The Nine Sovereignty Dimensions
Section titled “The Nine Sovereignty Dimensions”The SML framework builds on the eight sovereignty objectives of the official EU Cloud Sovereignty Framework (CSF) and adds a ninth, future-critical dimension: Artificial Intelligence.
| ID | Dimension | What it assesses |
|---|---|---|
| SML 1 | Strategic | Corporate governance architecture, ownership dependencies, transparency of ownership structures, and executive oversight of service substitution and exit readiness. |
| SML 2 | Legal & Jurisdictional | Applicable legal frameworks, geographic processing boundaries, and legal protection against extraterritorial third-party claims or conflicting access requests. |
| SML 3 | Data | Customer-controlled access management, cross-environment data portability, purpose-bound usage constraints, and long-term cryptographic resilience. |
| SML 4 | Operational | Allocation of day-to-day operational responsibility, restriction and auditing of privileged access, autonomous incident response, and disaster recovery. |
| SML 5 | Supply Chain | Transparency of subprocessors and software components (SBOM), vendor risk governance, critical dependency mitigation, and vendor substitution workflows. |
| SML 6 | Technology | Deployment within approved geographic boundaries, adoption of open standards against vendor lock-in, architectural transparency, and component portability. |
| SML 7 | Security & Compliance | Least-privilege identity and access control, lifecycle data encryption, customer visibility into security logs, and isolation of high-risk operational tasks. |
| SML 8 | Environmental Sustainability | Infrastructure energy dependency profiles, hardware and cooling supply-chain exposure, environmental risk planning, and sustainability metric disclosure. |
| SML 9 | AI | Corporate accountability models, system explainability, reliance on external software providers, and protection of training data and model components. |
Each dimension is assessed on three mandatory implementation levels, so a requirement is never satisfied on paper alone:
- Level 1 — Contractual (Regulatory): contractual regulations and assurances, such as service agreements, SLAs, and legal arrangements.
- Level 2 — Governance & Operations (Organization): organizational responsibilities, policies, procedures, and operational processes.
- Level 3 — Technical (Technology): technical implementation and system configuration, such as security measures, configurations, and automation.
The Four Sovereignty Maturity Levels
Section titled “The Four Sovereignty Maturity Levels”| Level | Short form | Description |
|---|---|---|
| 1 Initial | Ad hoc, not standardized | Heavy reliance on external providers. Processes are reactive, digital dependencies are not managed and not embedded in risk management. |
| 2 Managed | Documented, rule-based | Digital dependencies are identified and documented in risk management. Initial contingency and restoration plans exist, but are not yet fully tested. |
| 3 Advanced | Structured, consistent | Sovereignty is anchored as a strategic objective. At least one alternative sourcing option or a documented migration path exists for every business-critical service. Data is predominantly processed within the EU/EEA. |
| 4 Future-Proof | Optimized, robust | Near-complete digital autonomy on self-operated or sovereign-controlled infrastructure, open standards, and European supply chains. Remaining dependencies are deliberate and substitutable at any time. |
What Is Assessed — and Who Is Responsible
Section titled “What Is Assessed — and Who Is Responsible”The object of assessment is always the combination of a client-facing service and its service provider, including the underlying services it is built on. Before the assessment starts, the service is classified by Service Name, Service Provider, and Service Type (IaaS, PaaS, SaaS, Managed Service, AI Service). The Service Type determines only which controls are applicable — it has no influence on the resulting maturity level.
Every control is assigned to exactly one Control Scope, which defines who is responsible for it:
| Scope | Abbr. | Meaning for an ISV |
|---|---|---|
| Underlying Service | US | The platform you build on — for a Marketplace ISV, typically STACKIT. |
| Service Provider | SP | Your organization, which develops, operates, and is accountable for the service. |
| Client-facing Service | CFS | The specific product you deliver to your customer. |
This split exists to prevent duplicate audits and to make inherited capabilities auditable:
- Controls at SP level are assessed once and inherited across all of your services.
- Controls at US level are not implemented by you. They are covered by suitable evidence from the platform provider (certificates, audit reports) and are considered inherited — which means the sovereignty maturity of the platform you build on directly shapes the level your own service can reach.
- Controls at CFS level apply to the specific product you deliver to your customer and must be assessed individually for each service — they are neither inherited from your SP-level controls nor from the underlying platform.
Evidence Requirements
Section titled “Evidence Requirements”The framework is hierarchical: Dimension → Control Objective → Control → Question → Evidence. You answer at the Control level, not the question level — the questions listed underneath each control in the catalogue are illustrative example questions that help you interpret its intent, not a separate checklist to work through. Each control is answered binary — “Yes”, “No”, or “N/A” — and backed by evidence; a control counts as fulfilled only when it is answered “Yes” and the evidence substantiates it. An “N/A” is accepted only where it is objectively not applicable and justified.
Evidence must be specific, verifiable, and directly assignable to a control. Blanket statements such as “documentation available” or “process exists” are not sufficient; an independent third party must be able to fully comprehend the assessment. Permissible evidence types:
- Contracts or legal agreements
- Policies and procedural documentation
- Technical configurations or system extracts
- Audit reports or certifications
- Architecture diagrams
How to Approach the Assessment
Section titled “How to Approach the Assessment”The entire assessment process chain — service classification, working through the control catalogue, uploading evidence, and tracking your target level — is mapped in the ES³ Tool:
- ES³ Tool: es3.runs.onstackit.cloud
- Determine your starting point: Use the ES³ Lens, the interactive presales assessment tool, to get an instant maturity scorecard for your infrastructure before committing to a target level.
- Study the framework and catalogue: Read the SML Framework specification and the downloadable framework catalogue, in which every assessment question is listed with its dimension, control, service type, expected evidence type, and evidence example.
- Classify your service: Fix Service Name, Service Provider, and Service Type. This classification is binding for the entire assessment and determines which controls apply.
- Collect evidence per control: Work through the applicable controls along all three implementation levels, answer each one directly, and assign exactly one piece of specific, verifiable evidence to substantiate your answer.
- Agree your target level: Discuss the maturity level your solution should carry with your STACKIT Partner Manager — it determines which controls are mandatory for you via the separate SML mapping table.
- Validation: Your results are reviewed as part of the Technical Quality Gate, which is also where the sovereignty seal shown on your Marketplace listing is established.
- ES³ program overview: stackit.com — ES³
- SML Framework specification (PDF): Framework and Criteria Specification
- ES³ Tool: es3.runs.onstackit.cloud
- STACKIT Partner Portal: partner-portal.stackit.cloud
Phase Completion Criteria
Section titled “Phase Completion Criteria”- Framework Reviewed: SML framework specification and criteria catalogue reviewed by your security or technical lead.
- Service Classified: Service Name, Service Provider, and Service Type fixed for the assessment.
- Assessment Completed: All applicable controls answered across the contractual, organizational, and technical levels, each backed by specific evidence.
- Target Level Agreed: The intended Sovereignty Maturity Level is aligned with your STACKIT Partner Manager.
- Results Submitted: Assessment results handed over for validation in the Technical Quality Gate.
Support & Contact
Section titled “Support & Contact”For questions on specific controls, sovereignty criteria, or the assessment tooling, contact the ES³
Program team at ES3@digits.schwarz. For questions about how the assessment fits into your ISV
onboarding, reach out to the ISV Factory team at isv-sales@digits.schwarz.
The Placement phase transitions your validated software solution into a commercially available product on the STACKIT Marketplace. In this phase, commercial structures are established, product SKUs are generated, and your storefront presence is created.
Discovering the STACKIT Marketplace
Section titled “Discovering the STACKIT Marketplace”To get a clear overview of how software solutions are featured and delivered to enterprise customers, watch the official STACKIT Marketplace introduction:
- STACKIT Marketplace Overview: youtu.be/9FK_SIQAgwM
Marketplace Vendor Documentation & Onboarding
Section titled “Marketplace Vendor Documentation & Onboarding”All technical, operational, and commercial guidelines for listing and integrating your product are maintained in our central vendor documentation.
- STACKIT Documentation for Marketplace Vendors: docs.stackit.cloud — for marketplace vendors
Please review this documentation to guide you through the following steps:
- Commercial & Operational Onboarding: Requirements for setting up your vendor profile and commercial structures.
- Product Submission: Completing the required product details, pricing models, and marketing assets.
- Listing & Integration Options: Guidance on standard storefront listings as well as automated provisioning and metering via Marketplace APIs.
Commercial Onboarding & SKU Creation
Section titled “Commercial Onboarding & SKU Creation”Before a listing can go live, the commercial parameters agreed upon during KickOff and Signing must be operationalized:
- Product Delivery Sheet: The ISV provides final product details, marketing assets, pricing tiers, and descriptions via the standardized Product Delivery Sheet.
- SKU Generation: STACKIT creates the official Stock Keeping Units (SKUs) in the billing engine to enable transaction processing, invoicing, or referral tracking.
Marketplace Listing vs. Integration
Section titled “Marketplace Listing vs. Integration”Commercial placement is divided into two distinct levels depending on your chosen integration depth:
| Level | Scope & execution |
|---|---|
| Stage 1: Marketplace Listing (standard) | Listing Creation: STACKIT Partner Managers (PDMs, ISV Sales, and ISV GTM teams) use the Marketplace Listing Wizard to build your storefront entry using your Product Delivery Sheet. Lead / Inquiry Handling: Customers can discover your product, request quotes, or trigger manual fulfillment. |
| Stage 2: Marketplace Integration (optional) | Automated Provisioning & Metering: Deep API integration between your software and STACKIT Marketplace APIs. Usage-Based Billing: Automated meter tracking and single-click customer provisioning. |
Phase Completion Criteria
Section titled “Phase Completion Criteria”- Vendor documentation reviewed by your commercial and technical teams.
- Product details and commercial structures submitted according to vendor guidelines.
- Product Delivery Sheet completed and submitted by the ISV.
- Billing SKUs created in the STACKIT system.
- Storefront draft generated via the Marketplace Listing Wizard and approved by both teams.
- Milestone achieved: Commercial listing approved — ready to proceed to Ready for Production.
Support & Contact
Section titled “Support & Contact”For questions on vendor documentation, SKU creation, or the Marketplace Listing Wizard, contact
your STACKIT Partner Manager or the ISV Factory team at isv-sales@digits.schwarz.
Trail historyActive 3 of the last 12 weeksLWUpdatedNo updates · 1 bar = 1 week i
Maintainers
- LWLukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerLukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updateswww.linkedin.com/in/lukas-weberruß-a360b081
- CFCarsten Fraszczak
- GDGeorg Deil
LWLukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081??Name not publicThe Cloud Framework team knows who this is. The name is not shown on the site.TMTobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172Contributed in STACKIT
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081??Name not publicThe Cloud Framework team knows who this is. The name is not shown on the site.TMTobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172Contributed in STACKITLukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Sep 29, 2026Lukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Sep 15, 2026
Show full history (3 more)
Lukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Sep 11, 2026Lukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Aug 27, 2026Tobias M.
Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172
· Aug 26, 2026