Card one
Body text of the first card, long enough to wrap onto a second line.
Component Showcase
TM Solutions Corp. Inc.
Component Showcase
Last updated on
STACKIT
Component Showcase
Sample trail that walks through every common Starlight and framework component, used to verify correct rendering in the presentation deck and the trail timeline view.
All Components
WIP
General
Data and AI
STACKIT Partner
TM Solutions Corp. Inc.
Core contributor and technical product owner of the framework, focused on sovereign cloud architecture, automation, and production-ready DevOps pipelines.
Asides
Section titled “Asides”Card Grid
Section titled “Card Grid”Card two
Body text of the second card.
- First step of the sequence.
- Second step with
code. - Third and final step.
Content of the first tab.
Content of the second tab.
Link card and button
Section titled “Link card and button”The card reads its kind from the link target, so the same component covers a page on this site, a STACKIT product, the documentation, a repository and a third-party source. Only the last one carries the “leads off the trail” note.
A link card With a description line. Open page CAF Landing Zone Foundation A managed landing zone, bookable through the STACKIT Marketplace. Open in the Marketplace STACKIT Kubernetes Engine Product documentation for the managed Kubernetes offering. Open the documentation A third-party source An external site that STACKIT does not vet. Open external site Leads off the trail A link buttonInline links
Section titled “Inline links”A reference that sits inside a sentence uses the chip instead of the card, so the line keeps reading. It marks the same five kinds with the same colours, and the label says where you land rather than repeating the URL.
- Regions: Region strategy determines data locality, latency profile and resilience boundaries for workloads and shared services. Documentation
- Terraform Provider: Use the official provider for declarative infrastructure provisioning and lifecycle control. Provider registry
- Landing zone service: A managed landing zone can be booked instead of built. Marketplace
- Related guidance: The migration framework covers the same ground for existing workloads. Migration Framework
- Outside sources keep the amber, dashed treatment of the card, so leaving the framework is visible mid-sentence too. Research library
Several chips in one sentence stay legible because each one is labelled by its destination: the SDKs exist for Go , Python and Java .
Inline badge: New
Code block
Section titled “Code block”# a shell snippet with syntax highlightingexport FOO=barecho "hello $FOO"| Layer | Component | Sovereign option |
|---|---|---|
| Data | S3-compatible storage | STACKIT Object Storage |
| Compute | Managed Kubernetes | STACKIT SKE |
| Metadata | Managed PostgreSQL | STACKIT PostgreSQL |
Lists and quote
Section titled “Lists and quote”- Unordered item one
- Unordered item two
- Ordered item one
- Ordered item two
A blockquote to check quote styling in the deck.
Explanation Beside a Live Asset Card
Assets are the equipment in the backpack: blueprints, guides, runbooks and more. Each is shown as a card with its contributor, category, tags, license model, and whether STACKIT recommends it. The card on the right is the real component.
Explanation Beside a Live Trail Card
Trails chain assets and pages into a guided journey up the mountain. A trail card previews where a route leads before you open it. This is the real trail card component, so it themes with the deck.
Multiple Sections Stacked in One Column (cards shown)
Relocate moves existing virtualization stacks to STACKIT with minimal redesign when speed and low-change delivery are the primary goals.
Understanding Relocate
Section titled “Understanding Relocate”Relocate moves workloads with minimal architectural change, typically by transferring virtualization estates to a STACKIT-compatible target setup. The goal is fast transition with controlled risk, not immediate cloud-native modernization.
In practical terms, Relocate keeps the existing VM operating pattern largely intact. The main change is the runtime location and surrounding platform controls, not the workload runtime model itself.
Relocate vs. Rehost in STACKIT
Section titled “Relocate vs. Rehost in STACKIT”Relocate and Rehost are both low-change paths, but they differ in migration depth and adaptation scope.
- Relocate in STACKIT: Focuses on moving existing VM-centric estates into a compatible STACKIT target with as little workload reshaping as possible.
- Rehost in STACKIT: Focuses on workload-level lift-and-shift into STACKIT target runtimes, including explicit runtime mapping, cutover design, and runbook standardization for factory scale.
- Operational consequence: Relocate is usually the fastest path for estate movement, while Rehost is usually the clearer path for repeatable application-wave delivery.
- Planning consequence: Choose Relocate when preserving current operating patterns is the priority; choose Rehost when migration repeatability across many applications is the priority.
Delivery variants in Relocate
Section titled “Delivery variants in Relocate”Relocate can be delivered in two operational variants, depending on estate size, heterogeneity, and cutover risk profile.
- Tool-assisted relocate: Preferred for large-scale migration programs where throughput, consistency, and repeatable wave handling are required.
- Controlled manual relocate: Suitable for smaller or exceptional workloads that require more manual sequencing.
- Shared quality baseline: Both variants still require the same cutover controls, rollback design, and Day-1 operations readiness.
When Relocate is a good fit
Section titled “When Relocate is a good fit”- Time-critical transitions: Exit timelines or data residency deadlines require rapid movement.
- Low change tolerance: Business cannot absorb major application refactoring in the current phase.
- Known workload behavior: Existing VM-based patterns are stable and operationally understood.
- Deferred modernization strategy: Cloud-native optimization is planned as a later wave.
Design considerations in STACKIT context
Section titled “Design considerations in STACKIT context”Landing zone compatibility
Validate network segmentation, IAM model, and security controls before migration starts.
Performance and sizing
Re-baseline VM sizing and storage profiles to avoid overprovisioning after move.
Operational controls
Preserve monitoring, backup, and recovery controls from day one in the target environment.
Large data volume handling
For very large VM data sets, define pre-seeding, delta-sync windows, and transfer throttle rules before cutover to avoid extended outage windows.
Future modernization path
Record explicit trigger points for follow-up replatform/refactor decisions.
Data path guidance in Relocate
Section titled “Data path guidance in Relocate”In Relocate, the data path is often implicit because the full VM (including attached storage) is moved. Even so, large data footprints still require explicit design decisions:
- Network connectivity capacity: Validate end-to-end throughput, latency, and transfer path stability for the planned migration window.
- Storage class fit: Align source and target storage classes with required IOPS/throughput characteristics before cutover.
- Pre-seed strategy: Transfer baseline volumes before cutover where possible.
- Delta synchronization: Minimize final downtime window by only syncing latest changes during cutover.
- Integrity checks: Define checksum and sample-read validation for migrated disks.
- Rollback checkpoints: Keep source snapshot retention until target acceptance is confirmed.
Recommended design flow
Section titled “Recommended design flow”- Confirm baseline workload dependencies and operational constraints.
- Define target stack mapping in STACKIT and required network/security controls.
- Design migration sequence, downtime assumptions, and rollback model.
- Validate operational readiness (monitoring, backup, incident handling).
- Document post-move optimization backlog and ownership.
Required outputs
Section titled “Required outputs”Shared outputs across all migration paths
Section titled “Shared outputs across all migration paths”- Approved design decision record with scope, assumptions, and governance sign-off.
- Validation evidence package for security, compliance, and operational readiness.
- Strategy-specific migration runbook draft from the Design phase.
- Handover package for Migration Factory Setup and wave planning.
Relocate-specific outputs
Section titled “Relocate-specific outputs”- Relocate decision record with trade-offs and exit criteria.
- Target stack mapping per workload.
- Cutover and rollback design.
- Day-1 operations checklist.
- Post-relocation optimization backlog.
Diagram step reference
Section titled “Diagram step reference”Define landing zone
Section titled “Define landing zone”Define the target landing zone controls for the Relocate wave before run start. Confirm account boundaries, network segmentation, and baseline controls so existing VM operating patterns can be transferred without violating platform governance.
Use migration tools
Section titled “Use migration tools”Define the tool-assisted run path for scalable and repeatable Relocate waves. Set execution roles, migration batches, and rollback checkpoints up front so large VM estates can be moved with consistent controls across waves.
Asset title
Framework
Asset type
Migration
Guide
Migration
Guide
Migration
Runbook
Migration
Guide
Migration
Blueprint
Migration
Runbook
Migration
Runbook
Migration
Software
Migration
Software
Migration
Software
Install
Section titled “Install”Describe manual installation steps for workloads that are not migrated with tools. Include OS baseline, package dependencies, and host preparation criteria to keep exception paths compatible with standard operations.
-
Prepare target VM and storage: Create target VM, attach required disks, and align CPU/memory sizing with measured source behavior.
-
Install required base components: Install hypervisor guest tools, OS packages, and runtime prerequisites needed to boot and operate the workload.
-
Transfer workload artifacts: Copy disk images, boot files, and service units/scripts using a controlled transfer path.
-
Validate boot and host baseline: Verify successful boot, filesystem mount integrity, and core network reachability before configuration.
- Runbook Blueprint
- Cloud Design Patterns
Config
Section titled “Config”Document manual target-side configuration and parameter alignment. Record security policies, IAM assignments, backup defaults, and monitoring baselines so moved workloads are operationally equivalent from day one.
-
Align system and application parameters: Apply hostname, DNS, time sync, and environment settings required by the workload.
-
Configure security and access model: Apply access policies, service credentials, and administrative boundaries for the target environment.
-
Enable operations baseline: Configure monitoring agents, log forwarding, backup jobs, and restore-test hooks.
-
Run configuration parity checks: Compare key runtime parameters with source baseline and document accepted differences.
- Runbook Blueprint
- Migration Plan
Deploy
Section titled “Deploy”Define manual deployment sequencing and handover checks. Define freeze windows, acceptance checks, and ownership transfer steps to prevent ambiguous handover during cutover.
-
Execute cutover sequence: Stop source writes, run final delta sync, and activate the target workload in the approved order.
-
Validate service behavior: Run smoke and critical-path tests, including connectivity to dependent systems.
-
Stabilize and monitor: Observe key metrics, error rates, and operational alerts during the agreed Hypercare window.
-
Finalize ownership transfer: Confirm support responsibilities, escalation paths, and rollback closure criteria.
- Migration Plan
- Runbook Blueprint
Validation handover
Section titled “Validation handover”Specify how Relocate outputs enter the common validation gate. Bundle technical evidence, risk log updates, and operational acceptance status so downstream wave governance can decide release without rework.
Rehost migrates applications with minimal code change and prioritizes delivery speed, operational continuity, and predictable wave throughput.
Understanding Rehost
Section titled “Understanding Rehost”Rehost (lift-and-shift) migrates workloads with minimal application change. It is primarily a run strategy to reduce transition risk and accelerate migration throughput.
In practical terms, Rehost is application-wave oriented: each workload gets a defined target runtime mapping, cutover path, and runbook package for repeatable factory delivery.
Rehost compared to Relocate in STACKIT
Section titled “Rehost compared to Relocate in STACKIT”Relocate and Rehost are often used interchangeably, but in this framework they are separated on purpose.
- Rehost in STACKIT: Application-level lift-and-shift with explicit target runtime mapping, cutover, rollback, and runbook standardization.
- Relocate in STACKIT: Estate-level move of existing virtualization patterns with minimal reshaping of workload runtime behavior.
- When to prefer Rehost: When migration waves require repeatable runbooks and stable run operations at scale across many applications.
- When to prefer Relocate: When urgent movement of VM estates is the primary goal and modernization is deferred by design.
When Rehost is a good fit
Section titled “When Rehost is a good fit”- Strict migration timeline with limited engineering capacity for redesign.
- Legacy workloads that are difficult to refactor in the current program phase.
- Business stability priority where functional behavior must remain largely unchanged.
- Factory scale objective where repeatable migration procedures are required across many systems.
Design considerations in STACKIT context
Section titled “Design considerations in STACKIT context”Infrastructure mapping
Define target compute, storage, and network profiles with explicit compatibility checks.
Data and cutover path
Design transfer windows, consistency checks, and rollback triggers.
Stateful workload handling
Separate application artifact rollout from database migration sequencing to reduce cutover risk.
Security and compliance
Map identity controls, encryption requirements, and evidence checkpoints.
Operational handover
Ensure runbooks cover Day-1 operations and incident workflows after migration.
Recommended design flow
Section titled “Recommended design flow”- Baseline current runtime dependencies and non-functional requirements.
- Define target runtime mapping and migration sequence.
- Design data movement and cutover orchestration.
- Validate runbook quality with dry-run checkpoints.
- Approve production migration with release and business sign-off.
Data migration path in Rehost
Section titled “Data migration path in Rehost”In Rehost scenarios, the data migration path depends on whether the workload is stateless or stateful:
- Stateless workloads: Focus on application deployment and configuration.
- Stateful workloads: Require a coordinated data movement strategy alongside the application migration.
For stateful migration waves, split the path into two streams:
- Infrastructure and application stream: Provision the target environment, deploy the application, and prepare the target data store.
- Data stream: Export source data, transfer to the target, restore, and validate.
Suggested data sequence
Section titled “Suggested data sequence”- Export data from the source system using platform-native or tool-specific methods.
- Transfer data to the target environment or intermediate staging area.
- Configure the target environment to ingest the migrated data.
- Run the restoration process and verify data integrity.
- Validate application connectivity and functional behavior before final cutover.
Required outputs
Section titled “Required outputs”Shared outputs across all migration paths
Section titled “Shared outputs across all migration paths”- Approved design decision record with scope, assumptions, and governance sign-off.
- Validation evidence package for security, compliance, and operational readiness.
- Strategy-specific migration runbook draft from the Design phase.
- Handover package for Migration Factory Setup and wave planning.
Rehost-specific outputs
Section titled “Rehost-specific outputs”- Rehost decision rationale and constraints.
- Target runtime mapping.
- Data movement and cutover plan.
- Runbook with validation and rollback checkpoints.
- Post-wave stabilization checklist.
Diagram step reference
Section titled “Diagram step reference”Define landing zone
Section titled “Define landing zone”Define landing zone requirements and controls as the start point for Rehost run. Clarify network, identity, backup, and monitoring prerequisites before migration sequencing is approved so Rehost waves can run with predictable operations quality.
Use migration tools
Section titled “Use migration tools”Define the automated Rehost path used for repeatable wave throughput. In the automated Rehost path, infrastructure and application setup are provisioned as code so wave delivery stays repeatable and auditable.
-
Provision VM target with IaC: Create networks, security groups, compute instances, and base storage through Terraform or OpenTofu.
-
Install and configure application with automation: Use Ansible playbooks for package install, service setup, and baseline configuration.
-
Apply environment-specific parameters: Inject target variables, secrets references, and endpoint mappings in a controlled automation run.
-
Run automated validation and cutover gates: Execute health checks, migration pre-checks, rollback checkpoints, and release approvals before live switch.
- Runbook Blueprint
- Migration Plan
Asset title
Framework
Asset type
Migration
Runbook
Migration
Runbook
Migration
Blueprint
Migration
Runbook
Migration
Blueprint
Migration
Runbook
Migration
Guide
The runbook asset documents the PostgreSQL flags and the optional dump-based data restore path.
Install
Section titled “Install”Describe manual installation steps for exception workloads.
-
Create and prepare target VM manually: Provision the VM through Portal or CLI, attach required storage, and apply OS hardening and patch baseline.
-
Install runtime and dependencies manually: Install required runtime packages, system libraries, and service users/groups according to product installation guidance.
-
Install application in the classic way: Perform guided installation steps (for example installer or setup wizard flow) to reproduce the source deployment model on the target VM.
-
Validate base install readiness: Confirm service startup, file permissions, required ports, DNS reachability, and outbound connectivity.
- Cloud Design Patterns
- Runbook Blueprint
Config
Section titled “Config”Define manual runtime configuration and controls.
-
Mirror source configuration for target context: Recreate application settings from the source environment and adapt them to target endpoints, DNS, certificates, and service integrations.
-
Apply security and access settings: Configure service credentials, secret handling, and least-privilege access for target operation.
-
Align operational defaults: Configure logging targets, metrics exporters, backup schedules, and retention baselines.
-
Validate configuration parity: Run smoke checks to confirm the target instance behaves as a functional equivalent of the source baseline.
- Runbook Blueprint
Deploy
Section titled “Deploy”Define manual deployment sequencing and release checks.
-
Plan final migration window: Align freeze windows, communication checkpoints, and rollback authority for production switch.
-
Run final data migration: Execute last data sync or restore steps and confirm consistency checks before go-live.
-
Activate production traffic: Perform controlled live switch to the target environment and verify critical user and integration paths.
-
Confirm handover readiness: Record evidence, close open risks, and transfer ownership for Day-1 operations.
- Migration Plan
- Runbook Blueprint
Replatform introduces targeted platform changes during migration to improve operations, scalability, and cost without full application redesign.
Understanding Replatform
Section titled “Understanding Replatform”Replatform keeps core application behavior but changes selected platform components to gain operational or economic benefits. It sits between Rehost and Refactor in change intensity.
Comparing Replatform, Rehost, and Refactor
Section titled “Comparing Replatform, Rehost, and Refactor”- Rehost: Move workload location with minimal platform or code change. Example: Spring Boot stays on VM, only cloud target changes.
- Replatform: Keep application behavior, but change selected platform layers. Example: Spring Boot runtime moves from VM to Kubernetes while core business logic remains unchanged.
- Refactor: Change code structure or architecture significantly to unlock additional capabilities. Example: split monolith into services, redesign persistence model, and rework integration contracts.
What counts as a platform change
Section titled “What counts as a platform change”- Runtime platform swap: VM-based application hosting to Kubernetes.
- Data platform swap: Self-managed database on VM to managed PaaS database service.
- Ops capability swap: Host-centric monitoring and deployment model to managed platform-native operations.
- Connectivity/control swap: Ingress, DNS, and service exposure model adapted to managed platform patterns.
These are Replatform changes as long as the core product behavior and major code paths remain mostly stable.
When Replatform is a good fit
Section titled “When Replatform is a good fit”- Operational bottlenecks can be reduced through managed platform capabilities.
- Moderate change tolerance exists, but full redesign is out of scope.
- Scalability and reliability goals require infrastructure-level improvements.
- Cost optimization target can be reached with selective platform substitution.
Design considerations in STACKIT context
Section titled “Design considerations in STACKIT context”Platform component selection
Identify which layers should change (for example runtime, database operations, integration controls).
Compatibility boundaries
Validate technical constraints and fallback options before introducing platform changes.
Risk-managed sequencing
Stage changes to avoid coupling too many unknowns in one cutover window.
Evidence and acceptance
Define measurable improvements for performance, resilience, and operational load.
Recommended design flow
Section titled “Recommended design flow”- Define Landing Zone for the workload and its control boundaries.
- Map Target Platform components for runtime, data, and integration.
- Adapt Platform Stack prerequisites with sequencing and rollback checkpoints.
- Use migration tools to execute the transition through the shared migration path.
- Validate non-functional requirements and approve handover.
Data platform guidance in Replatform
Section titled “Data platform guidance in Replatform”For stateful workloads, define source and target data platform responsibilities before runtime cutover.
- Source data ownership: Clarify who owns dump/export run and consistency checks.
- Target data ownership: Clarify who owns managed database provisioning, access controls, and backup baseline.
- Migration sequencing: Separate schema/data move from runtime switch and validate each gate independently.
- Temporary access controls: Plan temporary data migration access and explicit rollback/removal checkpoints.
Required outputs
Section titled “Required outputs”Shared outputs across all migration paths
Section titled “Shared outputs across all migration paths”- Approved design decision record with scope, assumptions, and governance sign-off.
- Validation evidence package for security, compliance, and operational readiness.
- Strategy-specific migration runbook draft from the Design phase.
- Handover package for Migration Factory Setup and wave planning.
Replatform-specific outputs
Section titled “Replatform-specific outputs”- Replatform decision matrix with selected substitutions.
- Compatibility and constraint assessment.
- Sequenced migration and rollback design.
- Target-state operations model.
- Benefit metrics and acceptance criteria.
Concrete example asset
Section titled “Concrete example asset”For a runnable example of a platform swap from VM to Kubernetes with Spring Boot, use:
Asset title
Framework
Asset type
Migration
Runbook
Migration
Runbook
Migration
Blueprint
Migration
Runbook
Migration
Runbook
Migration
Runbook
Migration
Runbook
Migration
Runbook
Migration
Runbook
Migration
Runbook
Migration
Runbook
Migration
Blueprint
Migration
Blueprint
Migration
Service
Migration
Guide
Use the asset for the runnable VM-to-Kubernetes and VM-to-managed-database implementation details.
Diagram step reference
Section titled “Diagram step reference”Define Landing Zone
Define landing zone controls and guardrails as the start condition for the Replatform path. Confirm platform prerequisites for runtime, data, and integration layers so substitutions can be introduced without breaking governance or operability.
Map Target Platform
Define the target platform mapping for the Replatform path across runtime, data, and integration services. Make dependencies explicit, including identity, networking, and data responsibilities, so each change can be validated before cutover.
Adapt Platform Stack
Specify required platform prerequisite changes and sequencing for controlled transition. Define rollback guardrails, readiness checks, and run ownership so wave delivery stays predictable when multiple platform layers change together.
Refactor redesigns application architecture and delivery model to unlock strategic cloud-native value in resilience, agility, and long-term efficiency.
Understanding Refactor
Section titled “Understanding Refactor”Refactor redesigns parts of the application and delivery model for cloud-native operation. It is the most change-intensive path and should be applied selectively to strategic workloads.
When Refactor Is a Good Fit
Section titled “When Refactor Is a Good Fit”- Strategic differentiation depends on faster product and feature delivery.
- Current architecture limits resilience or scalability beyond acceptable risk.
- Legacy debt blocks innovation and causes recurring operational instability.
- Long-term value outweighs near-term migration effort and governance complexity.
Design Considerations in STACKIT Context
Section titled “Design Considerations in STACKIT Context”Architecture target state
Define decomposition boundaries, service interactions, and reliability patterns.
Engineering and delivery model
Align CI/CD, testing strategy, and release governance with the new architecture.
Data and integration refactoring
Plan schema transitions, interface versioning, and coexistence strategy.
Operational model
Define observability, SRE responsibilities, and incident response for the new runtime.
Recommended Design Flow
Section titled “Recommended Design Flow”- Baseline technical debt and business constraints.
- Define target architecture slices and migration increments.
- Design transition states and compatibility contracts.
- Validate reliability, security, and performance requirements.
- Approve phased delivery roadmap with business checkpoints.
Required Outputs
Section titled “Required Outputs”Shared outputs across all migration paths
Section titled “Shared outputs across all migration paths”- Approved design decision record with scope, assumptions, and governance sign-off.
- Validation evidence package for security, compliance, and operational readiness.
- Strategy-specific migration runbook draft from the Design phase.
- Handover package for Migration Factory Setup and wave planning.
Refactor-specific outputs
Section titled “Refactor-specific outputs”- Refactor decision record and value hypothesis.
- Target architecture with transition states.
- Delivery roadmap and engineering controls.
- Data/integration transition design.
- Runbook and operations readiness package.
Diagram Step Reference
Section titled “Diagram Step Reference”Redesign application/infrastructure architecture
Section titled “Redesign application/infrastructure architecture”Define the redesigned architecture baseline and transition boundaries. Describe domain decomposition, target runtime decisions, and interim coexistence states so refactor increments can be delivered without destabilizing dependent systems.
App code development
Section titled “App code development”Define implementation scope and change packaging for the redesigned architecture. Define increment boundaries, test strategy, and release criteria per slice so code changes remain deployable within migration wave constraints.
Full ALM/SDLC
Section titled “Full ALM/SDLC”Define delivery pipeline, quality gates, and release governance model. Align branch strategy, automated checks, and approval gates with security and compliance evidence requirements before production cutover.
Integration
Section titled “Integration”Define integration transition, compatibility handling, and final handover controls. Specify API contract versioning, rollback behavior, and cross-team cutover communication to reduce integration regression risk.
Repurchase replaces existing solutions with fit-for-purpose offerings from the STACKIT ecosystem when business value is higher than technical migration effort.
Understanding Repurchase
Section titled “Understanding Repurchase”Repurchase replaces existing systems with alternative solutions instead of migrating the old stack as-is. In migration programs, this is often the best path when the current solution has high modernization cost and low strategic value.
Repurchase is not a pure software procurement decision. In most cases, it requires redesigning and adopting a new target operating process, including roles, controls, integrations, and governance.
Scope for This Design Baseline
Section titled “Scope for This Design Baseline”For this phase, evaluate repurchase options explicitly for these STACKIT-related solutions:
- Workspace by STACKIT
- ServiceNow on STACKIT
- RISE with SAP on STACKIT
- STACKIT Domain Solutions
Other repurchase targets can be added in later iterations.
When Repurchase Is a Good Fit
Section titled “When Repurchase Is a Good Fit”- Legacy replacement is cheaper than migration across lifecycle and operations cost.
- Process standardization goals are better served by a new solution model.
- Vendor-supported capabilities reduce custom engineering and operational burden.
- Compliance and sovereignty requirements are easier to fulfill in the replacement setup.
Process Transformation Is Mandatory
Section titled “Process Transformation Is Mandatory”In this framework, Repurchase means process migration, not only product replacement.
- Process design first: Define the target process model before finalizing tool configuration.
- Role and ownership changes: Clarify new responsibilities, decision paths, and support model.
- Integration redesign: Adjust data flows, interfaces, and control points to the new process model.
- Adoption and enablement: Train users and service teams on new operational behavior, not only on UI.
Solution-Oriented Design Focus
Section titled “Solution-Oriented Design Focus”Workspace by STACKIT
Assess collaboration and workplace process migration, identity integration, and user adoption planning.
ServiceNow on STACKIT
Evaluate ITSM/ITOM process fit, workflow migration, data mapping, and integration boundaries.
RISE with SAP on STACKIT
Evaluate SAP landscape transition path, governance model, and business continuity requirements.
STACKIT Domain Solutions
Evaluate domain-specific fit, regulatory alignment, and operational handover requirements.
Recommended Design Flow
Section titled “Recommended Design Flow”- Define repurchase candidate scope and business outcomes.
- Compare migration-of-old vs replacement-of-solution across risk, cost, and timeline.
- Design the target business process model before finalizing product setup.
- Design integration model, control model, and data transition approach.
- Validate process fit with business owners and operations teams in walkthrough sessions.
- Define cutover and coexistence model for business continuity.
- Finalize adoption, training, and support transition plan.
Required Outputs
Section titled “Required Outputs”Shared outputs across all migration paths
Section titled “Shared outputs across all migration paths”- Approved design decision record with scope, assumptions, and governance sign-off.
- Validation evidence package for security, compliance, and operational readiness.
- Strategy-specific migration runbook draft from the Design phase.
- Handover package for Migration Factory Setup and wave planning.
Repurchase-specific outputs
Section titled “Repurchase-specific outputs”- Repurchase business case with decision criteria.
- Target solution architecture and integration design.
- Data transition and coexistence strategy.
- Cutover and rollback/contingency plan.
- Adoption and operations handover package.
Diagram Step Reference
Section titled “Diagram Step Reference”Purchase COTS/SaaS and licensing
Section titled “Purchase COTS/SaaS and licensing”Define the selected replacement solution, licensing model, and governance boundaries. Include operating responsibilities, sovereignty constraints, and contractual checkpoints so target solution decisions remain executable in delivery waves.
Migrate business process
Section titled “Migrate business process”Describe the business-process transition and operational adoption path. Define process ownership transfer, coexistence period controls, and user enablement milestones so the organization can adopt the new solution model without service disruption.
Asset Sections Condensed (default, no cards flag)
Accelerator architecture
Section titled “Accelerator architecture”
Overview
Section titled “Overview”This asset provides a reusable foundation for implementing a STACKIT platform landing zone. It is designed for enterprise environments that need a structured baseline for governance, security, networking, cost controls, and automation.
Repository:
How the repository works
Section titled “How the repository works”This repository is a single root-module accelerator with modular submodules.
- The root module in
src/main.tforchestrates all platform and landing-zone building blocks. - Configuration is provided through flavor-specific variable files in
src/config/. - You can deploy with OpenTofu or Terraform (same module graph).
- The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.
Deployment flavours and what they enable
Section titled “Deployment flavours and what they enable”The repository provides eight reference configurations in src/config/. Choose the simplest
topology that satisfies the required network, security, organizational, tenant, and regional
boundaries.
Standalone
Section titled “Standalone”
Use standalone.tfvars for the smallest foundation: governance, management, a sandbox, and a
public application landing zone with its own network and direct internet access. It creates no
shared Network Area or connectivity hub, making it suitable when workloads do not require private
east-west connectivity or central DNS.
Hub-and-spoke
Section titled “Hub-and-spoke”
Use hub-and-spoke.tfvars when corporate workloads need shared private connectivity. A central
connectivity project provides the Network Area and DNS, the corporate data platform joins that
private domain, and public workloads retain independent networks with direct internet access.
Hub-and-spoke with firewall
Section titled “Hub-and-spoke with firewall”
Use hub-and-spoke-firewall.tfvars when corporate egress needs a consistent inspection and control
point. It extends the shared Network Area with an OPNsense firewall and steers corporate default
routes through the appliance, while public landing zones remain directly connected.
Finance and research separation
Section titled “Finance and research separation”
Use hub-and-spoke-finance-research.tfvars when business units require independent ownership and
private connectivity. Finance and research each receive their own address plan, connectivity
project, Network Area, and workload landing zone within the same STACKIT organization.
Regulated and shared network areas
Section titled “Regulated and shared network areas”
Use hub-and-spoke-multi-area.tfvars when regulated and shared workloads must occupy separate
private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit
routing between them.
Independent regional hubs
Section titled “Independent regional hubs”
Use hub-and-spoke-multi-region.tfvars for regional foundations in eu01 and eu02. Each region
receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes
cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.
Production and non-production isolation
Section titled “Production and non-production isolation”
Use hub-and-spoke-prod-nonprod-firewall.tfvars when production must be isolated from
non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development
and test share the non-production domain while remaining separate landing zones.
Tenant isolation
Section titled “Tenant isolation”
Use hub-and-spoke-tenant-isolation.tfvars for multiple tenants inside one organization. Every
tenant receives an independent owner, address plan, Network Area, connectivity project, and
workload landing zone, without private routing to the other tenant domains.
Module-by-module breakdown
Section titled “Module-by-module breakdown”1. Governance module (src/modules/governance)
Section titled “1. Governance module (src/modules/governance)”Purpose:
- Creates RM folder structure (
platform,landing_zones_corporate,landing_zones_public,sandboxes). - Assigns folder-level owners and auditors.
- Assigns organization-level owners and auditors.
- Creates custom roles at organization scope.
Landing-zone classification:
- Platform Landing Zone: core governance baseline.
2. Management module (src/modules/management)
Section titled “2. Management module (src/modules/management)”Purpose:
- Creates a central management project.
- Provisions Secrets Manager and default access user.
- Provisions object storage buckets (including a remote state bucket).
- Creates object-storage credentials and stores them in Secrets Manager.
- Creates automation service account + rotating keys, stores key in Secrets Manager.
- Optionally provisions observability and stores observability credentials in Secrets Manager.
- Optionally configures federated identity providers for the automation service account.
Landing-zone classification:
- Platform Landing Zone: shared operations and automation control plane.
3. Connectivity module (src/modules/connectivity)
Section titled “3. Connectivity module (src/modules/connectivity)”Purpose:
- Creates a dedicated connectivity project.
- Creates network area and regional network-area configuration.
- Creates DNS zones for shared naming domains.
- Optionally creates firewall image, volume, server, interfaces, public IP.
- Exposes firewall next-hop IP for route injection into corporate landing zones.
Landing-zone classification:
- Platform Landing Zone: shared network and routing baseline.
4. DevOps module (src/modules/devops)
Section titled “4. DevOps module (src/modules/devops)”Purpose:
- Creates a dedicated DevOps project.
- Optionally creates a central STACKIT Git instance with ACL ranges.
Landing-zone classification:
- Platform Landing Zone in this accelerator’s architecture.
- Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.
5. Landing-Zone module (src/modules/landing-zone)
Section titled “5. Landing-Zone module (src/modules/landing-zone)”Purpose:
- Creates application-facing landing-zone projects (iterative via
for_each). - Supports corporate landing zones (network area-connected) and public landing zones.
- Creates routed networks, optional routing-table default route via firewall next hop.
- Optionally creates per-project child DNS zones.
- Creates project-level custom roles and role assignments.
- Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.
Landing-zone classification:
- Application Landing Zone: primary ALZ implementation module.
6. Sandboxes module (src/modules/sandboxes)
Section titled “6. Sandboxes module (src/modules/sandboxes)”Purpose:
- Creates lightweight sandbox projects in the dedicated
sandboxesfolder. - Assigns project owners.
Landing-zone classification:
- Application Landing Zone (supporting): non-production experimentation space close to ALZ usage patterns.
Newly implemented scope in this asset
Section titled “Newly implemented scope in this asset”The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.
Platform landing zone for central Kubernetes
Section titled “Platform landing zone for central Kubernetes”The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.
- Central cluster foundation: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
- Secrets policy readiness: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
- Shared service model: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
- Operational baseline: Cluster-level outputs and access information are exposed for automation and controlled platform operations.
Application landing zone for namespace tenants
Section titled “Application landing zone for namespace tenants”Application landing zones can now consume namespace service from the central Kubernetes platform cluster.
- Namespace onboarding: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
- Developer access path: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
- Service exposure: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
- Secrets integration: Workloads can consume centrally governed secret flows while staying in namespace scope.
Extra platform features used in this setup
Section titled “Extra platform features used in this setup”- External DNS automation: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
- Central Kubernetes monitoring: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
- Dashboard provisioning workflow: Example dashboards are provisioned and imported for faster operational handover.
- Encrypted volumes option: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
- Flexible network posture: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.
What developers get in an application landing zone
Section titled “What developers get in an application landing zone”- Ready-to-use namespace: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
- Least-privilege access: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
- Consistent endpoint model: Predictable DNS and ingress patterns for service publication.
- Governed secret usage: Central secret governance with namespace-level consumption patterns.
- Observability visibility: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.
Platform vs application landing zone scope in this repository
Section titled “Platform vs application landing zone scope in this repository”- Platform Landing Zone focus (majority of implementation):
governancemanagementconnectivitydevops
- Application Landing Zone scope (narrower by design):
landing-zone(core ALZ provisioning)sandboxes(supporting ALZ-adjacent environments)
This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.
How to use this asset in migration programs
Section titled “How to use this asset in migration programs”- Start the platform baseline early (governance, management, connectivity, optional DevOps).
- Define corporate vs public ALZ patterns based on connectivity and compliance needs.
- Instantiate application landing zones with the
landing-zonemap in your variable files. - Use sandboxes for team onboarding and controlled early experiments.
- Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.
What you get
Section titled “What you get”- Reusable baseline modules: Building blocks for account/project structure, IAM, network, and controls.
- Policy-oriented setup: Guardrails and conventions for secure and governed cloud usage.
- IaC-first approach: OpenTofu/Terraform implementation model for repeatable provisioning.
- Enterprise extensibility: Designed as a baseline to be adapted to customer-specific requirements.
Typical use in migration programs
Section titled “Typical use in migration programs”- Early platform stream: Start foundation setup in parallel with discovery.
- Control baseline before production move: Ensure mandatory controls are in place before productive migrations.
- Template source for application landing zones: Reuse and refine baseline modules for workload archetypes.
Recommended prerequisites
Section titled “Recommended prerequisites”- Organization and ownership model for projects/environments.
- Security and compliance requirements (identity, logging, evidence, segmentation).
- Connectivity constraints and integration requirements.
- Operating model alignment across platform, security, and application teams.
Accelerator architecture
Section titled “Accelerator architecture”
Overview
Section titled “Overview”This asset provides a reusable foundation for implementing a STACKIT platform landing zone. It is designed for enterprise environments that need a structured baseline for governance, security, networking, cost controls, and automation.
Repository:
How the repository works
Section titled “How the repository works”This repository is a single root-module accelerator with modular submodules.
- The root module in
src/main.tforchestrates all platform and landing-zone building blocks. - Configuration is provided through flavor-specific variable files in
src/config/. - You can deploy with OpenTofu or Terraform (same module graph).
- The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.
Deployment flavours and what they enable
Section titled “Deployment flavours and what they enable”The repository provides eight reference configurations in src/config/. Choose the simplest
topology that satisfies the required network, security, organizational, tenant, and regional
boundaries.
Standalone
Section titled “Standalone”
Use standalone.tfvars for the smallest foundation: governance, management, a sandbox, and a
public application landing zone with its own network and direct internet access. It creates no
shared Network Area or connectivity hub, making it suitable when workloads do not require private
east-west connectivity or central DNS.
Hub-and-spoke
Section titled “Hub-and-spoke”
Use hub-and-spoke.tfvars when corporate workloads need shared private connectivity. A central
connectivity project provides the Network Area and DNS, the corporate data platform joins that
private domain, and public workloads retain independent networks with direct internet access.
Hub-and-spoke with firewall
Section titled “Hub-and-spoke with firewall”
Use hub-and-spoke-firewall.tfvars when corporate egress needs a consistent inspection and control
point. It extends the shared Network Area with an OPNsense firewall and steers corporate default
routes through the appliance, while public landing zones remain directly connected.
Finance and research separation
Section titled “Finance and research separation”
Use hub-and-spoke-finance-research.tfvars when business units require independent ownership and
private connectivity. Finance and research each receive their own address plan, connectivity
project, Network Area, and workload landing zone within the same STACKIT organization.
Regulated and shared network areas
Section titled “Regulated and shared network areas”
Use hub-and-spoke-multi-area.tfvars when regulated and shared workloads must occupy separate
private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit
routing between them.
Independent regional hubs
Section titled “Independent regional hubs”
Use hub-and-spoke-multi-region.tfvars for regional foundations in eu01 and eu02. Each region
receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes
cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.
Production and non-production isolation
Section titled “Production and non-production isolation”
Use hub-and-spoke-prod-nonprod-firewall.tfvars when production must be isolated from
non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development
and test share the non-production domain while remaining separate landing zones.
Tenant isolation
Section titled “Tenant isolation”
Use hub-and-spoke-tenant-isolation.tfvars for multiple tenants inside one organization. Every
tenant receives an independent owner, address plan, Network Area, connectivity project, and
workload landing zone, without private routing to the other tenant domains.
Module-by-module breakdown
Section titled “Module-by-module breakdown”1. Governance module (src/modules/governance)
Section titled “1. Governance module (src/modules/governance)”Purpose:
- Creates RM folder structure (
platform,landing_zones_corporate,landing_zones_public,sandboxes). - Assigns folder-level owners and auditors.
- Assigns organization-level owners and auditors.
- Creates custom roles at organization scope.
Landing-zone classification:
- Platform Landing Zone: core governance baseline.
2. Management module (src/modules/management)
Section titled “2. Management module (src/modules/management)”Purpose:
- Creates a central management project.
- Provisions Secrets Manager and default access user.
- Provisions object storage buckets (including a remote state bucket).
- Creates object-storage credentials and stores them in Secrets Manager.
- Creates automation service account + rotating keys, stores key in Secrets Manager.
- Optionally provisions observability and stores observability credentials in Secrets Manager.
- Optionally configures federated identity providers for the automation service account.
Landing-zone classification:
- Platform Landing Zone: shared operations and automation control plane.
3. Connectivity module (src/modules/connectivity)
Section titled “3. Connectivity module (src/modules/connectivity)”Purpose:
- Creates a dedicated connectivity project.
- Creates network area and regional network-area configuration.
- Creates DNS zones for shared naming domains.
- Optionally creates firewall image, volume, server, interfaces, public IP.
- Exposes firewall next-hop IP for route injection into corporate landing zones.
Landing-zone classification:
- Platform Landing Zone: shared network and routing baseline.
4. DevOps module (src/modules/devops)
Section titled “4. DevOps module (src/modules/devops)”Purpose:
- Creates a dedicated DevOps project.
- Optionally creates a central STACKIT Git instance with ACL ranges.
Landing-zone classification:
- Platform Landing Zone in this accelerator’s architecture.
- Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.
5. Landing-Zone module (src/modules/landing-zone)
Section titled “5. Landing-Zone module (src/modules/landing-zone)”Purpose:
- Creates application-facing landing-zone projects (iterative via
for_each). - Supports corporate landing zones (network area-connected) and public landing zones.
- Creates routed networks, optional routing-table default route via firewall next hop.
- Optionally creates per-project child DNS zones.
- Creates project-level custom roles and role assignments.
- Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.
Landing-zone classification:
- Application Landing Zone: primary ALZ implementation module.
6. Sandboxes module (src/modules/sandboxes)
Section titled “6. Sandboxes module (src/modules/sandboxes)”Purpose:
- Creates lightweight sandbox projects in the dedicated
sandboxesfolder. - Assigns project owners.
Landing-zone classification:
- Application Landing Zone (supporting): non-production experimentation space close to ALZ usage patterns.
Newly implemented scope in this asset
Section titled “Newly implemented scope in this asset”The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.
Platform landing zone for central Kubernetes
Section titled “Platform landing zone for central Kubernetes”The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.
- Central cluster foundation: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
- Secrets policy readiness: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
- Shared service model: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
- Operational baseline: Cluster-level outputs and access information are exposed for automation and controlled platform operations.
Application landing zone for namespace tenants
Section titled “Application landing zone for namespace tenants”Application landing zones can now consume namespace service from the central Kubernetes platform cluster.
- Namespace onboarding: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
- Developer access path: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
- Service exposure: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
- Secrets integration: Workloads can consume centrally governed secret flows while staying in namespace scope.
Extra platform features used in this setup
Section titled “Extra platform features used in this setup”- External DNS automation: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
- Central Kubernetes monitoring: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
- Dashboard provisioning workflow: Example dashboards are provisioned and imported for faster operational handover.
- Encrypted volumes option: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
- Flexible network posture: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.
What developers get in an application landing zone
Section titled “What developers get in an application landing zone”- Ready-to-use namespace: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
- Least-privilege access: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
- Consistent endpoint model: Predictable DNS and ingress patterns for service publication.
- Governed secret usage: Central secret governance with namespace-level consumption patterns.
- Observability visibility: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.
Platform vs application landing zone scope in this repository
Section titled “Platform vs application landing zone scope in this repository”- Platform Landing Zone focus (majority of implementation):
governancemanagementconnectivitydevops
- Application Landing Zone scope (narrower by design):
landing-zone(core ALZ provisioning)sandboxes(supporting ALZ-adjacent environments)
This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.
How to use this asset in migration programs
Section titled “How to use this asset in migration programs”- Start the platform baseline early (governance, management, connectivity, optional DevOps).
- Define corporate vs public ALZ patterns based on connectivity and compliance needs.
- Instantiate application landing zones with the
landing-zonemap in your variable files. - Use sandboxes for team onboarding and controlled early experiments.
- Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.
What you get
Section titled “What you get”- Reusable baseline modules: Building blocks for account/project structure, IAM, network, and controls.
- Policy-oriented setup: Guardrails and conventions for secure and governed cloud usage.
- IaC-first approach: OpenTofu/Terraform implementation model for repeatable provisioning.
- Enterprise extensibility: Designed as a baseline to be adapted to customer-specific requirements.
Typical use in migration programs
Section titled “Typical use in migration programs”- Early platform stream: Start foundation setup in parallel with discovery.
- Control baseline before production move: Ensure mandatory controls are in place before productive migrations.
- Template source for application landing zones: Reuse and refine baseline modules for workload archetypes.
Recommended prerequisites
Section titled “Recommended prerequisites”- Organization and ownership model for projects/environments.
- Security and compliance requirements (identity, logging, evidence, segmentation).
- Connectivity constraints and integration requirements.
- Operating model alignment across platform, security, and application teams.
Accelerator architecture
Section titled “Accelerator architecture”
Overview
Section titled “Overview”This asset provides a reusable foundation for implementing a STACKIT platform landing zone. It is designed for enterprise environments that need a structured baseline for governance, security, networking, cost controls, and automation.
Repository:
How the repository works
Section titled “How the repository works”This repository is a single root-module accelerator with modular submodules.
- The root module in
src/main.tforchestrates all platform and landing-zone building blocks. - Configuration is provided through flavor-specific variable files in
src/config/. - You can deploy with OpenTofu or Terraform (same module graph).
- The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.
Deployment flavours and what they enable
Section titled “Deployment flavours and what they enable”The repository provides eight reference configurations in src/config/. Choose the simplest
topology that satisfies the required network, security, organizational, tenant, and regional
boundaries.
Standalone
Section titled “Standalone”
Use standalone.tfvars for the smallest foundation: governance, management, a sandbox, and a
public application landing zone with its own network and direct internet access. It creates no
shared Network Area or connectivity hub, making it suitable when workloads do not require private
east-west connectivity or central DNS.
Hub-and-spoke
Section titled “Hub-and-spoke”
Use hub-and-spoke.tfvars when corporate workloads need shared private connectivity. A central
connectivity project provides the Network Area and DNS, the corporate data platform joins that
private domain, and public workloads retain independent networks with direct internet access.
Hub-and-spoke with firewall
Section titled “Hub-and-spoke with firewall”
Use hub-and-spoke-firewall.tfvars when corporate egress needs a consistent inspection and control
point. It extends the shared Network Area with an OPNsense firewall and steers corporate default
routes through the appliance, while public landing zones remain directly connected.
Finance and research separation
Section titled “Finance and research separation”
Use hub-and-spoke-finance-research.tfvars when business units require independent ownership and
private connectivity. Finance and research each receive their own address plan, connectivity
project, Network Area, and workload landing zone within the same STACKIT organization.
Regulated and shared network areas
Section titled “Regulated and shared network areas”
Use hub-and-spoke-multi-area.tfvars when regulated and shared workloads must occupy separate
private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit
routing between them.
Independent regional hubs
Section titled “Independent regional hubs”
Use hub-and-spoke-multi-region.tfvars for regional foundations in eu01 and eu02. Each region
receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes
cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.
Production and non-production isolation
Section titled “Production and non-production isolation”
Use hub-and-spoke-prod-nonprod-firewall.tfvars when production must be isolated from
non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development
and test share the non-production domain while remaining separate landing zones.
Tenant isolation
Section titled “Tenant isolation”
Use hub-and-spoke-tenant-isolation.tfvars for multiple tenants inside one organization. Every
tenant receives an independent owner, address plan, Network Area, connectivity project, and
workload landing zone, without private routing to the other tenant domains.
Module-by-module breakdown
Section titled “Module-by-module breakdown”1. Governance module (src/modules/governance)
Section titled “1. Governance module (src/modules/governance)”Purpose:
- Creates RM folder structure (
platform,landing_zones_corporate,landing_zones_public,sandboxes). - Assigns folder-level owners and auditors.
- Assigns organization-level owners and auditors.
- Creates custom roles at organization scope.
Landing-zone classification:
- Platform Landing Zone: core governance baseline.
2. Management module (src/modules/management)
Section titled “2. Management module (src/modules/management)”Purpose:
- Creates a central management project.
- Provisions Secrets Manager and default access user.
- Provisions object storage buckets (including a remote state bucket).
- Creates object-storage credentials and stores them in Secrets Manager.
- Creates automation service account + rotating keys, stores key in Secrets Manager.
- Optionally provisions observability and stores observability credentials in Secrets Manager.
- Optionally configures federated identity providers for the automation service account.
Landing-zone classification:
- Platform Landing Zone: shared operations and automation control plane.
3. Connectivity module (src/modules/connectivity)
Section titled “3. Connectivity module (src/modules/connectivity)”Purpose:
- Creates a dedicated connectivity project.
- Creates network area and regional network-area configuration.
- Creates DNS zones for shared naming domains.
- Optionally creates firewall image, volume, server, interfaces, public IP.
- Exposes firewall next-hop IP for route injection into corporate landing zones.
Landing-zone classification:
- Platform Landing Zone: shared network and routing baseline.
4. DevOps module (src/modules/devops)
Section titled “4. DevOps module (src/modules/devops)”Purpose:
- Creates a dedicated DevOps project.
- Optionally creates a central STACKIT Git instance with ACL ranges.
Landing-zone classification:
- Platform Landing Zone in this accelerator’s architecture.
- Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.
5. Landing-Zone module (src/modules/landing-zone)
Section titled “5. Landing-Zone module (src/modules/landing-zone)”Purpose:
- Creates application-facing landing-zone projects (iterative via
for_each). - Supports corporate landing zones (network area-connected) and public landing zones.
- Creates routed networks, optional routing-table default route via firewall next hop.
- Optionally creates per-project child DNS zones.
- Creates project-level custom roles and role assignments.
- Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.
Landing-zone classification:
- Application Landing Zone: primary ALZ implementation module.
6. Sandboxes module (src/modules/sandboxes)
Section titled “6. Sandboxes module (src/modules/sandboxes)”Purpose:
- Creates lightweight sandbox projects in the dedicated
sandboxesfolder. - Assigns project owners.
Landing-zone classification:
- Application Landing Zone (supporting): non-production experimentation space close to ALZ usage patterns.
Newly implemented scope in this asset
Section titled “Newly implemented scope in this asset”The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.
Platform landing zone for central Kubernetes
Section titled “Platform landing zone for central Kubernetes”The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.
- Central cluster foundation: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
- Secrets policy readiness: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
- Shared service model: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
- Operational baseline: Cluster-level outputs and access information are exposed for automation and controlled platform operations.
Application landing zone for namespace tenants
Section titled “Application landing zone for namespace tenants”Application landing zones can now consume namespace service from the central Kubernetes platform cluster.
- Namespace onboarding: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
- Developer access path: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
- Service exposure: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
- Secrets integration: Workloads can consume centrally governed secret flows while staying in namespace scope.
Extra platform features used in this setup
Section titled “Extra platform features used in this setup”- External DNS automation: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
- Central Kubernetes monitoring: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
- Dashboard provisioning workflow: Example dashboards are provisioned and imported for faster operational handover.
- Encrypted volumes option: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
- Flexible network posture: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.
What developers get in an application landing zone
Section titled “What developers get in an application landing zone”- Ready-to-use namespace: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
- Least-privilege access: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
- Consistent endpoint model: Predictable DNS and ingress patterns for service publication.
- Governed secret usage: Central secret governance with namespace-level consumption patterns.
- Observability visibility: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.
Platform vs application landing zone scope in this repository
Section titled “Platform vs application landing zone scope in this repository”- Platform Landing Zone focus (majority of implementation):
governancemanagementconnectivitydevops
- Application Landing Zone scope (narrower by design):
landing-zone(core ALZ provisioning)sandboxes(supporting ALZ-adjacent environments)
This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.
How to use this asset in migration programs
Section titled “How to use this asset in migration programs”- Start the platform baseline early (governance, management, connectivity, optional DevOps).
- Define corporate vs public ALZ patterns based on connectivity and compliance needs.
- Instantiate application landing zones with the
landing-zonemap in your variable files. - Use sandboxes for team onboarding and controlled early experiments.
- Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.
What you get
Section titled “What you get”- Reusable baseline modules: Building blocks for account/project structure, IAM, network, and controls.
- Policy-oriented setup: Guardrails and conventions for secure and governed cloud usage.
- IaC-first approach: OpenTofu/Terraform implementation model for repeatable provisioning.
- Enterprise extensibility: Designed as a baseline to be adapted to customer-specific requirements.
Typical use in migration programs
Section titled “Typical use in migration programs”- Early platform stream: Start foundation setup in parallel with discovery.
- Control baseline before production move: Ensure mandatory controls are in place before productive migrations.
- Template source for application landing zones: Reuse and refine baseline modules for workload archetypes.
Recommended prerequisites
Section titled “Recommended prerequisites”- Organization and ownership model for projects/environments.
- Security and compliance requirements (identity, logging, evidence, segmentation).
- Connectivity constraints and integration requirements.
- Operating model alignment across platform, security, and application teams.
Use Case
Section titled “Use Case”- Migration strategy: Rehost (lift and shift)
- Application type: Spring Boot service (JAR), no Kubernetes target
- Target platform: VM-based runtime on STACKIT
- Data backend: PostgreSQL
Scope and Assumptions
Section titled “Scope and Assumptions”- In scope: Terraform provisioning, Ansible configuration, source dump evidence, temporary-database rehearsal, controlled restore, runtime validation, rollback, Observability, and Server Backup schedule.
- Out of scope: Code refactoring, database engine change, load balancing, DNS switch, TLS termination, multi-VM availability, Kubernetes, Cloud Foundry, and PostgreSQL Flex.
- Assumptions: The source uses a PostgreSQL version compatible with the target restore tools, and approved source CIDRs are known for SSH and application access.
Roles and Ownership
Section titled “Roles and Ownership”- Migration lead: Coordinates timeline, checkpoints, and go/no-go decision.
- Application owner: Validates app behavior and business-critical user journeys.
- Platform engineer: Prepares the VM, restricted network rules, monitoring, and backup schedule.
- DB owner: Executes DB backup, restore, consistency checks, and rollback trigger.
- Operations owner: Accepts handover and owns Day-1/Day-2 incident response.
Pre-Migration Checks
Section titled “Pre-Migration Checks”- Access readiness: SSH, deployment credentials, DB access, secrets access validated.
- Baseline captured: Current versions, environment variables, ports, certificates, scheduled jobs documented.
- Capacity validated: CPU, RAM, disk IOPS, and storage capacity on target VM confirmed.
- Security controls ready: Firewall rules, IAM mapping, TLS cert chain, and logging in place.
- Source evidence ready: Dump checksum, expected record count, and deterministic data fingerprint recorded.
- Rollback readiness: Pre-restore dump path, expected original record count, authority, and deadline agreed.
Run Plan (Cutover Window)
Section titled “Run Plan (Cutover Window)”Phase 1: Prepare target runtime
Section titled “Phase 1: Prepare target runtime”- Create target app user and required filesystem layout.
- Install Java runtime and supporting OS packages.
- Deploy app artifact to target path.
- Configure service unit (systemd) and environment file.
- Install self-managed PostgreSQL, create the application role and database, and restrict access to localhost.
- Enable node exporter, Observability scraping, and the Server Backup schedule.
Phase 2: Data and config alignment
Section titled “Phase 2: Data and config alignment”- Create a custom-format PostgreSQL dump without source ownership or privileges.
- Record and validate its checksum, expected row count, and deterministic fingerprint.
- Run
./scripts/run_migration_rehearsal.shagainst a temporary target database. - Confirm that rehearsal removed its temporary database and left the production target database unchanged.
- Verify the original target rollback dump in a separate temporary database.
Phase 3: Cutover and release
Section titled “Phase 3: Cutover and release”- Freeze source writes and create the final approved dump.
- Run
./scripts/run_cutover.sh --confirmwith the approved source evidence. - Require the saved Terraform plan to change only the Ansible orchestration resource.
- Validate row count, fingerprint, ownership, application-role write behavior, services, and endpoint.
- Require a final Terraform no-op plan, record acceptance, and start stabilization watch.
Validation Checklist
Section titled “Validation Checklist”- Technical health: Spring Boot, PostgreSQL, and node exporter active; local and approved public HTTP checks pass.
- Functional checks: The application returns the migrated Spring Music records.
- Data checks: Expected row count and fingerprint match; table ownership belongs to the application role.
- Security checks: Runtime environment and rollback dump have root-only or database-owner-only permissions.
- Operations checks: Observability scrape, Server Backup schedule, evidence files, and escalation ownership verified.
Rollback Criteria and Steps
Section titled “Rollback Criteria and Steps”Rollback triggers
Section titled “Rollback triggers”- Critical functional failure: Core business flow unavailable after fix window.
- Data integrity risk: Mismatch in critical records with no fast remediation.
- Operational instability: Repeated restarts or unresolved severe alerts.
Rollback steps
Section titled “Rollback steps”- Invoke the approved rollback decision before the deadline and preserve logs and evidence.
- Run
./scripts/rollback_postgresql.sh --confirmto stop Spring Boot and preserve the current target database. - Restore the protected pre-cutover dump and validate the expected original row count.
- Restart Spring Boot and validate local and approved public reachability.
- Resume the agreed source or target operating state and publish the rollback evidence and decision.
Handover to Operations
Section titled “Handover to Operations”- Artifacts delivered: Final config set, deployment manifest, validation evidence, rollback log.
- Ownership transfer: Named on-call owner and escalation route confirmed.
- Stabilization period: 24-72 hours with enhanced monitoring and daily status check.
- Exit criteria: No critical alerts, stable key metrics, and business owner sign-off.
Evidence Log Template
Section titled “Evidence Log Template”| Checkpoint | Owner | Timestamp | Result | Evidence Link |
|---|---|---|---|---|
| Target VM runtime prepared | Platform engineer | YYYY-MM-DD HH:MM | Pass/Fail | link |
| Rehearsal completed | DB owner | YYYY-MM-DD HH:MM | Pass/Fail | link |
| DB restore and integrity check | DB owner | YYYY-MM-DD HH:MM | Pass/Fail | link |
| Terraform no-op confirmed | Platform engineer | YYYY-MM-DD HH:MM | Pass/Fail | link |
| Post-cutover business checks | Application owner | YYYY-MM-DD HH:MM | Pass/Fail | link |
| Handover accepted | Operations owner | YYYY-MM-DD HH:MM | Pass/Fail | link |
Continue the reference implementation
Section titled “Continue the reference implementation”This asset continues the same Spring Boot and PostgreSQL reference implementation used for provisioning, migration, cutover, and stabilization. It does not introduce another example or repository. The existing Terraform variables, Ansible configuration, Observability instance, and validation workflows remain the technical baseline for Optimize.
The Optimize extension answers one practical question: how to detect overprovisioning or underprovisioning and then change VM or storage capacity through a controlled IaC workflow.
STACKIT CMF Rehost Spring Boot repository Continue with the same Terraform and Ansible reference implementation used by the preceding Rehost migration steps. Open the repository Rehost implementation assetObservability setup used for optimization
Section titled “Observability setup used for optimization”Use the managed STACKIT Observability stack as evidence source.
- Prometheus: metric collection
- Thanos: long-term metric retention
- Grafana Loki: log analysis
- Grafana Tempo: distributed traces
- Grafana: dashboards and visualization
Architecture reference:
Observability decision dashboard
Section titled “Observability decision dashboard”Use the dashboard to review infrastructure saturation, application health, request behavior, and alert history together before changing VM capacity.
Signals and thresholds for rightsizing
Section titled “Signals and thresholds for rightsizing”Define technical thresholds before changing capacity.
- Candidate for downsizing: CPU p95 under 30% and memory p95 under 50% for at least 14 days.
- Scale-up candidate: CPU p95 over 75% or memory p95 over 80% during business load windows for at least 3 consecutive days.
- Stability guardrail: No unresolved critical alerts and no regression in error-rate SLOs.
Keep thresholds workload-specific and validate with business traffic patterns.
Database visibility for optimize decisions
Section titled “Database visibility for optimize decisions”For stateful Rehost workloads, include database signals in the same dashboard review cycle.
- Connection pressure: active connection trend and burst behavior.
- Database growth: database size progression over time.
- Transaction behavior: commit/rollback trend for stability checks.
Use these metrics together with VM signals to avoid CPU-only or memory-only optimization decisions.
PostgreSQL Flex optimization path for migrated data tiers
Section titled “PostgreSQL Flex optimization path for migrated data tiers”If the Rehost workload later moves its database tier to PostgreSQL Flex, include database-tier rightsizing and tuning in the same optimize cycle.
- Plan the target DB profile: use Plan your PostgreSQL Flex instance to align expected data growth and concurrency.
- Tune flavor and storage class: use Flavors and performance classes of PostgreSQL Flex to adjust CPU, RAM, and storage performance.
- Use the integrated dashboard first: review Dashboard metrics in PostgreSQL Flex for fast checks.
- Use scraped observability metrics for deep analysis: follow Observability metrics in PostgreSQL Flex for alert and threshold design.
Use the offered Flex combinations and storage performance limits to assess a database-tier change. Keep the VM thresholds above workload-specific; the product catalog does not supply acceptance criteria or prove that an infrastructure change is reversible.
From the STACKIT docsFlavors and performance classes › Flavors
| Description | ID | CPU | RAM | max_connections | shared_buffers | work_mem | maintenance_work_mem | effective_cache_size |
|---|---|---|---|---|---|---|---|---|
| Small, Compute optimized | 2.4 | 2 | 4 GB | 95 | 950 MB | 14 MB | 380 MB | 2660 MB |
| Small, Memory optimized | 2.16 | 2 | 16 GB | 385 | 3950 MB | 14 MB | 1580 MB | 11060 MB |
| Medium, Compute optimized | 4.8 | 4 | 8 GB | 195 | 1950 MB | 14 MB | 780 MB | 5460 MB |
| Medium, Memory optimized | 4.32 | 4 | 32 GB | 785 | 7950 MB | 14 MB | 3180 MB | 22260 MB |
| Large, Processor optimized | 8.16 | 8 | 16 GB | 385 | 3950 MB | 14 MB | 1580 MB | 11060 MB |
| X-Large, Compute optimized | 16.32 | 16 | 32 GB | 785 | 7950 MB | 14 MB | 3180 MB | 22260 MB |
| X-Large, Memory optimized | 16.128 | 16 | 128 GB | 3170 | 31950 MB | 14 MB | 12780 MB | 89460 MB |
Notes
- CPU and RAM is always per node.
- The system uses up to 15 connections for internal essential processes such as backup, monitoring, etc. These connections will be counted towards the
max_connectionslimit.
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 docsFlavors and performance classes › Performance Classes
| Description | ID | Max. IOPS | Max. throughput (MB/s) |
|---|---|---|---|
| Performance class 2 | premium-perf2-stackit | 1000 | 100 |
| Performance class 4 | premium-perf4-stackit | 2000 | 150 |
| Performance class 6 | premium-perf6-stackit | 5000 | 200 |
| Performance class 8 | premium-perf8-stackit | 10000 | 250 |
| Performance class 10 | premium-perf10-stackit | 15000 | 300 |
| Performance class 12 | premium-perf12-stackit | 20000 | 350 |
Currently, we offer three types of instances. For each type there is a different set of flavors available.
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.
Rightsizing workflow
Section titled “Rightsizing workflow”- Collect baseline metrics and traces for a representative period.
- Confirm optimization candidate with dashboards and alert history.
- Plan capacity change and rollback checkpoint.
- Apply VM size change with Terraform/OpenTofu.
- Re-validate latency, error rates, throughput, and cost.
- Keep or revert based on objective acceptance criteria.
Technical implementation example
Section titled “Technical implementation example”Example A: Downsize after sustained low utilization
Section titled “Example A: Downsize after sustained low utilization”Update VM sizing in env.tfvars:
machine_type = "g3i.2"Apply and inspect plan output:
terraform plan -var-file=env.tfvarsterraform apply -var-file=env.tfvarsThen validate:
- Service health (
systemctl status, synthetic checks) - p95 latency and error-rate trend
- Cost delta in reporting window
Example B: Scale up under sustained overload
Section titled “Example B: Scale up under sustained overload”Update VM sizing in env.tfvars:
machine_type = "g3i.4"Apply and validate with the same post-change checks.
Rollback pattern
Section titled “Rollback pattern”If SLOs regress after rightsizing, roll back by restoring the previous machine_type and re-applying IaC.
Treat rollback as a standard runbook step, not as an emergency-only path.
- Depending on platform constraints and machine type, resize can require restart or replacement. Confirm behavior in
terraform planbefore apply.
Storage as optimization dimension
Section titled “Storage as optimization dimension”In Rehost scenarios, CPU and memory are only one side of rightsizing. Storage performance can also become the limiting factor.
- When to investigate storage: elevated I/O wait, unstable latency under write-heavy load, or throughput saturation despite available CPU.
- What to select: a storage service plan and performance class that matches the observed IOPS and throughput profile.
- Guidance: Block Storage service plans
Select the performance class before provisioning
Section titled “Select the performance class before provisioning”A Block Storage performance class defines the maximum IOPS and throughput available to the complete volume. Application, database, operating-system, and backup access share this performance envelope. Select the class from measured peak demand, latency requirements, backup activity, and explicit growth headroom before creating the volume.
From the STACKIT docsService plans › Currently available Service Plans (performance classes)
The following table lists currently available performance classes for the EU01 region:
| Performance class | Name | Max. IOPS | Max. Throughput (MB/s) |
|---|---|---|---|
| Performance class 0 | storage_premium_perf0 | 120 | 25 |
| Performance class 1 | storage_premium_perf1 | 500 | 50 |
| Performance class 2 | storage_premium_perf2 | 1000 | 100 |
| Performance class 4 | storage_premium_perf4 | 2000 | 150 |
| Performance class 6 | storage_premium_perf6 | 5000 | 200 |
| Performance class 8 | storage_premium_perf8 | 10000 | 250 |
| Performance class 10 | storage_premium_perf10 | 15000 | 300 |
| Performance class 12 | storage_premium_perf12 | 20000 | 350 |
| Performance class 13 | storage_premium_perf13 | 20000 | 700 |
| Performance class 14 | storage_premium_perf14 | 25000 | 400 |
| Performance class 15 | storage_premium_perf15 | 25000 | 800 |
| Performance class 16 | storage_premium_perf16 | 30000 | 450 |
| Performance class 17 | storage_premium_perf17 | 30000 | 900 |
| Performance class 18 | storage_premium_perf18 | 35000 | 500 |
| Performance class 19 | storage_premium_perf19 | 35000 | 1000 |
| Performance class 20 | storage_premium_perf20 | 40000 | 550 |
| Performance class 21 | storage_premium_perf21 | 40000 | 1100 |
| Performance class 29 | storage_premium_perf29 | 60000 | 1500 |
IOPS - Input/Output Operations per second
Throughput - Throughput in Megabytes per second
Thus, the classes used can be distinguished in detail based on the naming. Example: “Block Storage Premium - Performance Class 2” corresponds to SSD hard disks with max. 1000 IOPS and max. 100 Mbyte/s throughput.
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.
For the Rehost baseline, the operating system, Spring Boot application, and PostgreSQL data share the boot volume. Changing its performance class therefore requires a controlled replacement target:
- Select the new class from observed IOPS, throughput, latency, and I/O-wait data.
- Verify backup and database-level rollback readiness.
- Provision the replacement VM and boot volume through IaC with the selected class.
- Reapply the Ansible configuration and restore or migrate the workload data.
- Validate application behavior, data integrity, storage latency, backup coverage, and cost before switching.
Use a separate data volume when storage capacity or performance must evolve independently from the VM lifecycle. To change its performance class, create a new volume in the required availability model with sufficient capacity, stop writes, migrate and verify the data, switch the attachment or mount, and retain the source volume until acceptance and rollback gates have passed.
Migrate data from Block StorageTreat storage checks as part of the same Optimize loop and validate latency, error behavior, recovery, and cost impact after any change.
Trail historyActive 6 of the last 12 weeksLWUpdatedNo updates · 1 bar = 1 week i
Maintainers
- TMTobias M.Head of STACKIT Cloud Framework · STACKITOwnerTobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updateswww.linkedin.com/in/tobias-müller-011304172
LWLukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081TMTobias 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ß-a360b081TMTobias 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 25, 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
· Sep 7, 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 31, 2026
Show full history (6 more)
Tobias 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, 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
· Jul 29, 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
· Jul 24, 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
· Jul 23, 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
· Jul 22, 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
· Jul 20, 2026