Finanzielle Transparenz
Eine erste Kostenbandbreite und TCO-Sicht liegt für Investitionsentscheidungen vor.
VM-Anwendungsmigration mit kontrolliertem Cutover
STACKIT
Migration at a Glance
Zuletzt aktualisiert am
STACKIT
Migration at a Glance
Schneller, bildzentrierter Rundgang durch das STACKIT Migration Framework für Messestände und Kurzbriefings: ein Bild je Phase und Modul, im Automatik-Loop.
Die Reise in die Cloud
Beginnen Sie an der Touristeninformation, bereiten Sie sich im Basecamp vor und folgen Sie dem Weg zu Migration, Betrieb und Innovation. Fragen Sie, wo Ihre Organisation heute steht. Die sechs Bildstationen erzählen eine vereinfachte Geschichte und sind keine formalen Framework-Phasen.
Migrationsphasen
Assess
Positionieren Sie Assess als die schnelle Phase mit geringem Aufwand, die eine erste Faktenbasis schafft und die Migrationsabsicht qualifiziert, bevor die tiefere Design-Arbeit beginnt.
Überblick: Diese Phase
Abschnitt betitelt „Überblick: Diese Phase“Assess ist die erste Phase des STACKIT Migration Frameworks. Sie schafft eine belastbare, faktenbasierte Grundlage für Migrationsentscheidungen, bevor Zielbilder und Migrationswellen detailliert ausgearbeitet werden.
Die Phase verbindet technische Bewertung, kommerzielle Transparenz und organisatorische Abstimmung, damit die nachfolgende Umsetzung mit klaren Prioritäten startet.
Wann Assess startet und endet
Abschnitt betitelt „Wann Assess startet und endet“Assess startet typischerweise dann, wenn ein Vorhaben strategisch priorisiert ist, aber noch keine belastbare Grundlage für Entscheidungen vorliegt.
- Start mit grob definiertem Scope, Business-Treibern und benannten Entscheidungsträgern.
- Aufbau der Basis durch Rapid Discovery, Readiness-Bewertung, Kostenmodellierung und Workshops.
- Abschluss, sobald Scope-Annahmen, Migrationsreife und wirtschaftliche Leitplanken belastbar sind.
Assess ist abgeschlossen, wenn der Übergang in Design and Mobilize auf einer gemeinsamen Sicht zu Kosten, Risiken und Umsetzbarkeit freigegeben werden kann.
Warum diese Phase wichtig ist
Abschnitt betitelt „Warum diese Phase wichtig ist“Assess reduziert Unsicherheit in einem frühen Stadium und richtet Business und IT aus, bevor umfangreiche Umsetzungsaufwände entstehen.
Klarheit zur Readiness
Lücken in Technologie, Governance, Fähigkeiten und Betriebsmodell werden früh sichtbar.
Stakeholder-Alignment
Führung, Delivery-Teams und technische Verantwortliche einigen sich auf Ziele und Erwartungen.
Risikoreduktion
Kritische Annahmen und Restriktionen werden dokumentiert, bevor das Zielbild detailliert wird.
Module in dieser Phase
Abschnitt betitelt „Module in dieser Phase“- Rapid Discovery: Liefert Mengen und Daten für frühe Kostenabschätzungen.
- TCO Report: Bewertet die Gesamtkosten und den wirtschaftlichen Verlauf der Migration.
- Readiness Assessment: Bewertet die Bereitschaft zur Migration in Technologie und Organisation.
- Deepdive Workshop: Macht die technischen Teams früh mit der STACKIT Plattform und relevanten Services vertraut.
- Briefings and Workshops: Stimmt Kunde und STACKIT zu Anforderungen, Verantwortlichkeiten und der vorvertraglichen Zusammenarbeit ab.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“Am Ende von Assess sollten mindestens folgende Ergebnisse vorliegen:
- Entscheidungsreife Ausgangsbasis: Dokumentierte Sicht auf Ist-Landschaft, Umfang und Kandidaten für die Migration.
- Erste Kostenübersicht: Kostenindikation und TCO-Richtung mit transparenten Annahmen.
- Readiness und Sicht auf Risiken: Priorisierte Lücken und notwendige Maßnahmen für die Mobilisierung.
- Übergabekriterien: Klare Entry-Kriterien für Design and Mobilize.
Übergang zu Design and Mobilize
Abschnitt betitelt „Übergang zu Design and Mobilize“Assess finalisiert nicht die gesamte Zielarchitektur. Die Phase liefert die validierten Eingaben, um in Design and Mobilize die detaillierte Planung, Wellenplanung und Factory-Vorbereitung umzusetzen.
Rapid Discovery
Readiness Assessment
Bewerten Sie technische, prozessuale, personelle, finanzielle und Governance-Readiness und ordnen Sie jede Lücke einer verantwortlichen Person und einem Wellen-Gate zu.
Design and Mobilize
Positionieren Sie Design and Mobilize als die Phase mit dem größten inhaltlichen Gewicht: Sie überführt Assess-Signale in einen ausführbaren, factory-fähigen Lieferplan.
Überblick: Diese Phase
Abschnitt betitelt „Überblick: Diese Phase“Design and Mobilize ist die Planungs- und Befähigungsphase zwischen Assess und Migrate. Sie überführt die Ergebnisse aus Assess in umsetzbare Zielbilder, Governance, Migrationsplanung und operative Readiness.
Damit schafft die Phase die Voraussetzungen, um Migration in Wellen kontrolliert, skalierbar und sicher umzusetzen.
Wann Design and Mobilize startet und endet
Abschnitt betitelt „Wann Design and Mobilize startet und endet“Die Phase startet, sobald Assess Scope, Readiness und wirtschaftliche Richtung bestätigt hat.
- Start mit vertiefter Erfassung von Anwendungen, Abhängigkeiten und Restriktionen.
- Ausarbeitung von Zieldesigns, Business Cases und Wellenplanung bei gleichzeitigem Factory-Aufbau.
- Abschluss, sobald die ersten Wellen freigegeben sind und Runbooks, Governance und Teams einsatzbereit sind.
Design and Mobilize ist abgeschlossen, wenn Migrationswellen mit stabilen Eingaben, klaren Verantwortlichkeiten und definierten Kontrollen gestartet werden können.
Warum diese Phase wichtig ist
Abschnitt betitelt „Warum diese Phase wichtig ist“Diese Phase macht aus strategischer Ausrichtung eine belastbare Umsetzungsfähigkeit und verhindert ungeplante oder nicht steuerbare Migrationsläufe.
Architektur-Readiness
Zielbilder und Migrationspfade je Anwendung werden nachvollziehbar definiert.
Factory-Befähigung
Rollen, Prozesse, Tooling und Runbook-Governance stehen vor der Skalierung bereit.
Security by Design
Security- und Compliance-Anforderungen werden früh in Design und Planung verankert.
Hohe Umsetzungsqualität
Wellen werden abhängigkeitsbewusst, realistisch und operativ belastbar geplant.
Module in dieser Phase
Abschnitt betitelt „Module in dieser Phase“- Discovery: Schafft Transparenz zu Anwendungen, Abhängigkeiten und Randbedingungen.
- Migrationsplan: Überführt Strategie in eine umsetzbare Wellenplanung.
- Design: Definiert den Ansatz für die Migration und Zielbilder je Gruppe von Anwendungen.
- Migration Factory Setup: Etabliert Betriebsmodell, Schnittstellen und Vorgehen.
- Business Case: Konsolidiert Aufwand, Nutzen und die Sicht auf Investitionen pro Scope.
- Enablement: Bündelt Governance, Trainings, Lernpfade und Referenz.
- Landing Zone: Implementiert die sichere und skalierbare Basis der Plattform.
- Target Operating Model: Legt Governance, Verantwortlichkeiten und Fähigkeiten für einen stabilen Cloud-Betrieb fest.
- Security und Compliance: Definiert verbindliche Anforderungen für Kontrollen und Nachweise.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“Am Ende von Design and Mobilize sollten mindestens folgende Ergebnisse vorliegen:
- Freigegebene Zielbilder: Architektur- und Migrationsentscheidungen pro Workload-Klasse.
- Migrationsplan bereit für Wellen: Sequenzierte, abhängigkeitsbewusste Wellen mit priorisiertem Backlog.
- Etabliertes Factory-Modell: Governance-Taktung, Runbook-Standards und Delivery-Ownership.
- Plattform und Rahmen für Kontrollen: Landing Zone und Security-/Compliance-Leitplanken für die Umsetzung.
Übergang zu Migrate
Abschnitt betitelt „Übergang zu Migrate“Design and Mobilize kann sich mit den ersten Migrationswellen überlappen. Sobald der Zuschnitt der Wellen und Runbooks für die ersten Umsetzungen validiert sind, startet Migrate und die detaillierte Planung wird iterativ für Folgewellen fortgeführt.
Discovery
Design
Erkunden Sie mit dieser interaktiven Karte das STACKIT Serviceportfolio. Wählen Sie ein Produkt oder Zugriffstool aus, um die aktuelle Dokumentation oder das zugehörige Cloud-Framework-Asset zu öffnen.
Interaktives Serviceportfolio
Abschnitt betitelt „Interaktives Serviceportfolio“Nutzungshinweise
Abschnitt betitelt „Nutzungshinweise“Die Karte dient als Navigationshilfe und stellt keine Lifecycle-Zusage dar. Prüfen Sie auf den verlinkten Produktseiten die aktuellen Regionen, Verfügbarkeiten, Service Levels und Release-Status.
Gesamte STACKIT Produktdokumentation durchsuchen Dokumentation öffnenWarum diese Seite existiert
Abschnitt betitelt „Warum diese Seite existiert“Die R-Strategie erklärt, wie migriert wird. Diese Seite ergänzt die Workload-Sicht und klärt, was migriert wird. Sie ist bewusst lösungsneutral und fokussiert auf transparente Kategorisierung, Machbarkeitsgrenzen und Entscheidungskontext.
Use-Case-Kategorien im Scope
Abschnitt betitelt „Use-Case-Kategorien im Scope“Application-Runtime-Migration
Migration kompletter Anwendungs-Runtimes über VM- und Plattform-Ziele hinweg, inklusive Abhängigkeiten, Cutover-Verhalten und Betriebs-Handover.
Container-Plattform-Migration
Migration zwischen Kubernetes-Plattformen mit getrennter Behandlung von stateless und stateful Workload-Profilen.
Datenmigration
Migration großer Dateibestände, Datenbanken und Datenplattform-Workloads mit expliziten Konsistenz-, Performance- und Integritätsgrenzen.
Identity- und Access-Migration
Migration von IAM-Grundlagen wie SSO, Föderation, Rollen, Service-Accounts und Berechtigungsmodellen.
Netzwerk- und Konnektivitäts-Migration
Migration von Routing, DNS, Firewall-Regeln, Segmentierung, privater Konnektivität und umgebungsübergreifenden Kommunikationspfaden.
Integrations- und API-Migration
Migration von API-Verträgen, Messaging, Eventing und Integrations-Endpunkten über Quell- und Zielumgebungen hinweg.
Migration von Security- und Compliance-Controls
Migration von Controls, Nachweisketten, Schlüsselmaterial und Audit-Anforderungen für regulierte Produktionsreife.
Operations- und Observability-Migration
Migration von Monitoring, Alerting, Logging, Incident-Workflows und Service-Level-Baselines für den Betrieb.
Delivery- und Resilienz-Migration
Migration von CI/CD-Pipelines, Automatisierungs-Controls, Backup-Ketten und Disaster-Recovery-Fähigkeiten.
Wie sich die aktuellen Kategorien in dieses Modell einfügen
Abschnitt betitelt „Wie sich die aktuellen Kategorien in dieses Modell einfügen“- Application-Stack-Migration ist Teil der Application-Runtime-Migration.
- Migration großer Dateibestände ist Teil der Datenmigration.
- Kubernetes-zu-Kubernetes-Migration ist Teil der Container-Plattform-Migration.
Migrations-Use-Cases von AWS und Azure zu STACKIT
Abschnitt betitelt „Migrations-Use-Cases von AWS und Azure zu STACKIT“STACKIT unterstützt Migrationspfade von AWS und Azure über Anwendungs-Runtimes, Daten, Netzwerk, Identität, Betrieb und Delivery hinweg. Der Zielpfad wird je Workload anhand von Architektur, Datenprofil, Verfügbarkeitsanforderungen und Betriebsmodell ausgewählt.
| Use Case | Migrationsmöglichkeit zu STACKIT |
|---|---|
| Landing-Zone-Migration | AWS-Account- und Azure-Subscription-Strukturen, Netzwerksegmentierung, Identity- und Access-Controls, Security-Policies, Logging, Monitoring und Governance-Leitplanken werden vor Beginn der Applikationswellen auf eine STACKIT Landing Zone abgebildet. Der STACKIT Landing Zone Accelerator liefert eine wiederverwendbare, automatisierte Grundlage, um diese Controls konsistent und skalierbar umzusetzen. |
| VM-basierte Anwendungen | AWS-EC2- und Azure-VM-Workloads können zu STACKIT Compute Engine migriert werden, einschließlich Betriebssystemen, Middleware, Anwendungen, Konfigurationen und angebundenen Daten. |
| VM-Landschaften mit hohen Verfügbarkeitsanforderungen | Die toolgestützte Relocate-Migration unterstützt kontinuierliche Replikation, kontrollierte Validierung und geplanten Cutover für große VM-Landschaften und wiederholbare Migrationswellen. |
| Container- und Kubernetes-Workloads | AWS EKS, Azure AKS und selbstbetriebene Kubernetes-Cluster können zu STACKIT Kubernetes Engine migriert werden. Stateless Anwendungen werden deklarativ neu ausgerollt; stateful Anwendungen nutzen Backup und Restore oder Datenreplikation mit schrittweiser Traffic-Verlagerung. |
| PaaS- und Web-Anwendungen | Anwendungen mit gängigen Runtimes wie Java, Node.js, Python oder Ruby können auf STACKIT Cloud Foundry betrieben werden, wenn sie zum Plattformmodell passen. |
| Datenbanken und Datenplattformen | Selbstbetriebene und cloudbasierte Datenbanken können zu STACKIT Managed Database Services oder zunächst auf Compute-Engine-Instanzen migriert werden; die Umsetzung erfolgt über Export/Import, Replikation und kontrollierte Cutover-Verfahren. |
| Object Storage und Dateispeicher | AWS S3 und Azure Blob Storage können zu STACKIT Object Storage migriert werden. AWS EFS, Azure Files und NFS-basierte Dateisysteme können über Erstkopie, Delta-Synchronisation und finalen Konsistenz-Cutover nach STACKIT File Storage migriert werden. |
| Identity und Access Management | AWS IAM, Azure RBAC und Microsoft-Entra-basierte Zugriffsmodelle können auf STACKIT Rollen, Berechtigungen, Service Accounts und Föderation abgebildet werden. |
| Netzwerk, DNS und Konnektivität | AWS VPCs und Azure VNets können auf STACKIT Network Areas, Routing, Security Groups, Load Balancing, DNS und Site-to-Site-VPN-Konnektivität abgebildet werden. |
| Integration, Messaging und APIs | APIs, Integrationsendpunkte und Messaging-Workloads können zusammen mit ihren Verträgen, Sicherheitsmechanismen und Umschaltreihenfolgen migriert werden. STACKIT RabbitMQ unterstützt AMQP- und RabbitMQ-basierte Muster. |
| Security, Compliance und Betrieb | Secrets, Schlüssel, Audit-Anforderungen, Logging, Monitoring, Alerting, Backup und Betriebsprozesse werden vor dem Go-live als Teil der Zielumgebung aufgebaut. |
| CI/CD und Delivery | Deployment-Pipelines, Infrastrukturautomatisierung und Versionsverwaltung können auf STACKIT Git, Terraform oder OpenTofu, CLI, APIs und geeignete Image-Management-Prozesse überführt werden. |
Das servicebezogene Ziel-Mapping finden Sie unter Zielservice-Mappings für AWS und Azure.
Klassifikationsdimensionen
Abschnitt betitelt „Klassifikationsdimensionen“Nutzen Sie diese Dimensionen, um Anfragen vor der Auswahl von Umsetzungsvarianten zu kategorisieren:
- Migrationsobjekt: Application Stack, Datenbestand oder Container-Plattform.
- State-Profil: Stateless, stateful oder gemischt.
- Kritikalitätsprofil: Business-Kritikalität und akzeptiertes Migrationsrisiko.
- Konnektivitätsprofil: Netzwerk-Erreichbarkeit und Protokollkompatibilität zwischen Quelle und Ziel.
- Downtime-Profil: Erlaubte Service-Unterbrechung und Grenzen des Cutover-Fensters.
- Compliance-Profil: Security-, Audit- und regulatorische Grenzen.
Wie eine Migrationsanfrage klassifiziert wird
Abschnitt betitelt „Wie eine Migrationsanfrage klassifiziert wird“- Das primäre Migrationsobjekt identifizieren.
- Workload-State-Profil und Kritikalität bestimmen.
- Konnektivitäts- und Transfer-Einschränkungen erfassen.
- Rahmenbedingungen für Downtime, Konsistenz und Compliance definieren.
- Die Anfrage einer Use-Case-Kategorie zuordnen und Annahmen dokumentieren.
Use-Case-Katalog und Grenzen
Abschnitt betitelt „Use-Case-Katalog und Grenzen“1. Application-Runtime-Migration
Abschnitt betitelt „1. Application-Runtime-Migration“- Umfasst: Application-Stack-Migration (inklusive VM-zentrierter Migrationen).
- Primäres Ziel: Anwendungs-Runtimes mit planbarem Cutover und Betriebs-Handover überführen.
Verbindliche Grenzen:
- Abhängigkeits-Klarheit: Integrationsabhängigkeiten und Übergangsfenster müssen bekannt sein.
- Cutover-Modell: Unterbrechungsmodell und Entscheidungs-Gates müssen freigegeben sein.
- Rollback-Readiness: Trigger und Ownership müssen definiert sein.
2. Container-Plattform-Migration
Abschnitt betitelt „2. Container-Plattform-Migration“- Umfasst: Kubernetes-zu-Kubernetes-Migration.
- Primäres Ziel: Containerisierte Workloads in Ziel-Cluster-Modelle überführen.
Verbindliche Grenzen:
- State-Klassifikation: Stateless-/Stateful-Grenzen müssen je Komponente explizit sein.
- State-Portabilität: Storage- und Datenbank-Kompatibilität müssen validiert sein.
- Traffic-Steuerung: Die Fähigkeit zum progressiven Switch muss bestätigt sein.
3. Datenmigration
Abschnitt betitelt „3. Datenmigration“- Umfasst: Migration großer Dateibestände sowie Datenbank-/Datenplattform-Übergänge.
- Primäres Ziel: Datenbestände mit kontrollierter Konsistenz und Integrität überführen.
Verbindliche Grenzen:
- Konnektivitäts-Machbarkeit: Die erforderliche Endpunkt-Erreichbarkeit muss validiert sein.
- Konsistenzmodell: Freeze-Fenster, Delta-Strategie und Validierungsmethoden müssen definiert sein.
- Performance-Machbarkeit: Durchsatzprofil und Laufzeitgrenzen müssen validiert sein.
4. Identity- und Access-Migration
Abschnitt betitelt „4. Identity- und Access-Migration“- Primäres Ziel: Identity-Trust- und Access-Modelle ohne Security-Regression überführen.
Verbindliche Grenzen:
- Trust-Modell-Mapping: Föderation, SSO und Token-Flows müssen gemappt sein.
- Autorisierungs-Mapping: Rollen- und Entitlement-Mapping müssen validiert sein.
- Credential-Übergang: Secret-Rotation und Notfall-Zugriffspfade müssen freigegeben sein.
5. Netzwerk- und Konnektivitäts-Migration
Abschnitt betitelt „5. Netzwerk- und Konnektivitäts-Migration“- Primäres Ziel: Kommunikationspfade und Security-Grenzen zwischen Umgebungen überführen.
Verbindliche Grenzen:
- Adressierung und Routing: IP-Planung und Routen-Ownership müssen definiert sein.
- Policy-Parität der Controls: Firewall- und Segmentierungs-Policies müssen abgeglichen sein.
- Kontinuität der Namensauflösung: Das DNS-Übergangsverhalten muss geplant sein.
6. Integrations- und API-Migration
Abschnitt betitelt „6. Integrations- und API-Migration“- Primäres Ziel: Service-Schnittstellen und Integrationsmuster überführen, ohne Consumer zu brechen.
Verbindliche Grenzen:
- Vertragskompatibilität: Versionierungs- und Kompatibilitätsstrategie müssen explizit sein.
- Abhängigkeits-Sequenzierung: Die Switch-Reihenfolge von Producer/Consumer muss gesteuert werden.
- Message-Semantik: Annahmen zu Ordering, Retries und wiederholungssicherem Verhalten müssen validiert sein.
7. Migration von Security- und Compliance-Controls
Abschnitt betitelt „7. Migration von Security- und Compliance-Controls“- Primäres Ziel: Wirksamkeit der Controls und Audit-Readiness während des Übergangs erhalten oder verbessern.
Verbindliche Grenzen:
- Control-Mapping: Erforderliche Controls und Nachweispunkte müssen gemappt sein.
- Schlüssel- und Zertifikats-Handling: Der Übergang kryptografischen Materials muss gesteuert sein.
- Audit-Kontinuität: Logging- und Nachweis-Aufbewahrungspflichten müssen intakt bleiben.
8. Operations- und Observability-Migration
Abschnitt betitelt „8. Operations- und Observability-Migration“- Primäres Ziel: Operative Kontrolle und Incident-Response-Readiness nach der Migration sicherstellen.
Verbindliche Grenzen:
- Observability-Baseline: Metriken, Logs, Traces und Alerts müssen vor dem Cutover aktiv sein.
- Betriebs-Ownership: On-Call- und Eskalationspfade müssen zugewiesen sein.
- Service-Ziele: SLO-/SLA-Ziele und Schwellwerte müssen definiert sein.
9. Delivery- und Resilienz-Migration
Abschnitt betitelt „9. Delivery- und Resilienz-Migration“- Primäres Ziel: Software-Delivery- und Resilienz-Fähigkeiten in den Zielbetrieb überführen.
Verbindliche Grenzen:
- Pipeline-Kontinuität: CI/CD- und Release-Controls müssen auditierbar bleiben.
- Recovery-Readiness: Backup-/Restore- und DR-Annahmen müssen validiert sein.
- Automatisierungs-Sicherheit: Leitplanken für Deployment-Automatisierung müssen vorhanden sein.
Fallübergreifende Entscheidungskriterien
Abschnitt betitelt „Fallübergreifende Entscheidungskriterien“- Downtime-Ziel: Geplantes Downtime-Fenster versus Erwartung durchgehender Verfügbarkeit.
- Konsistenzanforderung: Eventual Consistency, Near-Real-Time oder strikte transaktionale Konsistenz.
- Änderungstoleranz: Wie viel Architektur- und Anwendungsänderung in der aktuellen Welle akzeptabel ist.
- Automatisierungsgrad: Manueller, teilautomatisierter oder vollautomatisierter Ausführungspfad.
- Risiko und Reversibilität: Fähigkeit, Fehler schnell zu erkennen und ohne business-kritische Auswirkung zurückzurollen.
Konkrete Asset-Vorlagen
Abschnitt betitelt „Konkrete Asset-Vorlagen“Die Umsetzungsdetails werden auf dedizierten Asset-Seiten gepflegt. Das hält die Übersichtsseite kategorie-fokussiert und lässt konkrete Vorlagen unabhängig weiterentwickeln.
Anwendung mit VM-Runtime
Abschnitt betitelt „Anwendung mit VM-Runtime“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Große Datenmigration zum STACKIT File Service
Abschnitt betitelt „Große Datenmigration zum STACKIT File Service“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Migration
Runbook
Kubernetes-zu-Kubernetes-Migration
Abschnitt betitelt „Kubernetes-zu-Kubernetes-Migration“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Migration
Blueprint
Migration
Runbook
Data and AI
Blueprint
Migration
Runbook
Migration
Runbook
Migration
Runbook
Migration
Service
Zielmuster und Runtime auswählen
Warum diese Seite existiert
Abschnitt betitelt „Warum diese Seite existiert“Das Design-Modul entscheidet vor der Ausführung der Migration, wie eine Anwendung auf STACKIT betrieben werden soll. Diese Seite fokussiert auf Zielarchitektur-Entscheidungen für Anwendungen, nicht auf Landing-Zone-Basisthemen.
Welche Fragen ein gutes Design der Anwendung beantworten muss
Abschnitt betitelt „Welche Fragen ein gutes Design der Anwendung beantworten muss“Für jede Anwendung sollte das Zielbild diese zentralen Fragen beantworten:
- Workload-Modell: Soll die Anwendung auf VM, Kubernetes, Cloud Foundry, als statische Auslieferung oder auf einem SaaS-Ziel laufen?
- Service-Modell-Fit: Welches Service-Modell (IaaS, PaaS, SaaS) balanciert Kontrolle, Geschwindigkeit und Betriebsaufwand am besten?
- State- und Weg der Daten: Wie werden Datenkonsistenz, Cutover-Sequenz und Rollback umgesetzt?
- Betriebsmodell: Welches Team verantwortet Day-1/Day-2-Betrieb, Alerting, Backup und Incident Response?
- Regeln für Risiken: Welche Architekturentscheidungen sind verpflichtend, nur als Ausnahme zulässig oder ausdrücklich ausgeschlossen?
Orientierung zum Service-Modell (IaaS, PaaS, SaaS)
Abschnitt betitelt „Orientierung zum Service-Modell (IaaS, PaaS, SaaS)“Diese Orientierung hilft bei der praktischen Auswahl für Designs von Anwendungen:
- IaaS wählen, wenn: Tiefe OS-/Runtime-Kontrolle, Legacy-Abhängigkeiten oder spezielle Anforderungen ans Netzwerk erforderlich sind.
- PaaS wählen, wenn: Schnellere Lieferung und weniger Betriebsaufwand gewünscht sind, bei weiterhin eigener Verantwortung für die Anwendung.
- SaaS wählen, wenn: Der Geschäftsprozess ein standardisiertes Produkt akzeptiert und Differenzierung keinen eigenen Plattformbetrieb erfordert.
Nicht nach Gewohnheit entscheiden. Auf Basis messbarer Anforderungen, verfügbarer Betriebskapazität und Zielen über den Lebenszyklus entscheiden.
Runtime-Auswahl für typische STACKIT-Zielbilder
Abschnitt betitelt „Runtime-Auswahl für typische STACKIT-Zielbilder“VM-Runtime (IaaS)
Geeignet für Low-Change-Migrationen und Komponenten mit OS-naher Kontrolle, Spezialagenten oder ausgeprägten Legacy-Abhängigkeiten.
Kubernetes-Runtime (PaaS-nahes Betriebsmodell)
Geeignet für containerisierte Workloads mit Bedarf an skalierbarer Ausführung, standardisierten Releases und Plattformbetrieb.
Cloud-Foundry-Runtime (PaaS)
Geeignet, wenn Teams hohe Entwicklerproduktivität und schnelle Bereitstellung über tiefe Plattformkontrolle priorisieren.
Statische Auslieferung mit Object Storage/CDN
Geeignet für Frontend-/Static-Workloads mit hohem Verteilungsbedarf und geringer Runtime-Komplexität.
SaaS-Ersatzpfad
Geeignet, wenn Prozessfit und Standardfähigkeiten mehr Mehrwert liefern als Migration und Betrieb des bisherigen Stacks.
Architektur-Guardrails für Designs von Anwendungen
Abschnitt betitelt „Architektur-Guardrails für Designs von Anwendungen“- Immer umsetzen: Ziel-Runtime, Verantwortung für Daten, Rollback-Trigger und Day-1-Betrieb vor Freigabe der Migration festlegen.
- Nur als Ausnahme: Temporärer Dual-Run, manuelle Handover oder teilweise Automatisierung nur mit explizitem Risiko und Enddatum.
- Vermeiden: Runtime-Wechsel, Datenmigration und große Integrationsänderungen in einem unkontrollierten Cutover bündeln.
- Nie umsetzen: Kein Zielbild ohne Observability-Baseline, Backup-/Recovery-Modell und klar benannte Betriebsverantwortung freigeben.
Praktischer Design-Ablauf pro Anwendung
Abschnitt betitelt „Praktischer Design-Ablauf pro Anwendung“- Anwendungsscope, Abhängigkeiten und nicht-funktionale Anforderungen bestätigen.
- Service-Modell-Fit (IaaS, PaaS, SaaS) bewerten und zulässige Runtime-Ziele eingrenzen.
- Ein Zielmuster auswählen und dokumentieren, warum Alternativen verworfen wurden.
- Datenpfad, Cutover-Sequenz, Validierungsgates und Rollback-Logik festlegen.
- Betriebsverantwortung, Monitoring-Baseline und Handover-Kriterien definieren.
- Architekturentscheidungen in das Migrations-Runbook überführen.
Typische STACKIT-Designoptionen
Abschnitt betitelt „Typische STACKIT-Designoptionen“VM-Muster mit Betriebsbaseline
Spring Boot auf VM mit Application Load Balancer, Observability-Integration und Backup-Strategie.
Kubernetes-Plattformmuster
Spring Boot auf SKE mit gemanagten Datendiensten, Object Storage, Secret Handling und Messaging.
Statische Auslieferung mit CDN-Option
Statische Auslieferung aus Object Storage mit optionaler CDN-Beschleunigung für internetseitige Nutzung.
Hybrides Connectivity-Muster
Zugriff auf den Workload über VPN und zentrale Firewall-Controls für Enterprise-Netze.
Cloud-Foundry-Muster
Spring Boot auf Cloud Foundry mit angebundenen Backing Services wie Redis und RabbitMQ.
Die Pattern-Karten dienen als mögliche Zielbilder. Pro Anwendung sollte ein explizites Zielbild gewählt werden. Mehrere Muster nur kombinieren, wenn Koexistenz bewusst als Übergangszustand geplant ist.
Best practices für Zielbilder auf STACKIT
Abschnitt betitelt „Best practices für Zielbilder auf STACKIT“- Architektur und Runbook trennen: zuerst das Zielbild definieren, danach Sequenz und Rollback für die Migration ableiten.
- Betrieb von Anfang an einplanen: Observability-Signale, Alarm-Grenzen und Backup- oder Recovery-Erwartungen im Zielzustand festlegen.
- Managed Services bewusst nutzen: gemanagte Plattform-Services bevorzugen, wenn sie Betriebsaufwand senken und keine unnötige Codeänderung erzwingen.
- Vertrauensgrenzen im Netzwerk explizit definieren: Ingress, Egress, Ost-West-Controls und Hybrid-Bedarf vor der Umsetzung dokumentieren.
- Secrets und Zugriffe als Design-Input behandeln: IAM-Rollen, Service Accounts und Secret-Manager-Nutzung früh im Architektur-Paket aufnehmen.
- Datenmigration vom Runtime-Wechsel entkoppeln: bei stateful Workloads Daten-Gates getrennt von Runtime-Cutover validieren.
- Messbare Abnahmekriterien festlegen: Verfügbarkeit, Latenz, Skalierung und Recovery müssen vor Handover prüfbar sein.
Verwandte Design-Seiten
Abschnitt betitelt „Verwandte Design-Seiten“Architektur-Assets
Abschnitt betitelt „Architektur-Assets“Diese Architektur-Assets dienen als konkrete Design-Referenzen.
Asset-Titel
Framework
Asset-Typ
Migration
Blueprint
Migration
Anleitung
Migration
Software
Migration
Software
Migration
Software
Migration
Runbook
Migration
Blueprint
Migration
Runbook
Migration
Blueprint
Migration
Blueprint
Migration
Blueprint
Migration
Software
Migration
Service
Migration
Anleitung
Ausführbare Beispiele für Migrationen (bestehend)
Abschnitt betitelt „Ausführbare Beispiele für Migrationen (bestehend)“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Migration
Runbook
Migration
Runbook
Die Architektur-Assets helfen bei Auswahl und Begründung der Zielarchitektur, die Runbook-Assets bei der konkreten Umsetzung des Migrationspfad.
Warum diese Seite existiert
Abschnitt betitelt „Warum diese Seite existiert“Das Design-Modul entscheidet vor der Ausführung der Migration, wie eine Anwendung auf STACKIT betrieben werden soll. Diese Seite fokussiert auf Zielarchitektur-Entscheidungen für Anwendungen, nicht auf Landing-Zone-Basisthemen.
Welche Fragen ein gutes Design der Anwendung beantworten muss
Abschnitt betitelt „Welche Fragen ein gutes Design der Anwendung beantworten muss“Für jede Anwendung sollte das Zielbild diese zentralen Fragen beantworten:
- Workload-Modell: Soll die Anwendung auf VM, Kubernetes, Cloud Foundry, als statische Auslieferung oder auf einem SaaS-Ziel laufen?
- Service-Modell-Fit: Welches Service-Modell (IaaS, PaaS, SaaS) balanciert Kontrolle, Geschwindigkeit und Betriebsaufwand am besten?
- State- und Weg der Daten: Wie werden Datenkonsistenz, Cutover-Sequenz und Rollback umgesetzt?
- Betriebsmodell: Welches Team verantwortet Day-1/Day-2-Betrieb, Alerting, Backup und Incident Response?
- Regeln für Risiken: Welche Architekturentscheidungen sind verpflichtend, nur als Ausnahme zulässig oder ausdrücklich ausgeschlossen?
Orientierung zum Service-Modell (IaaS, PaaS, SaaS)
Abschnitt betitelt „Orientierung zum Service-Modell (IaaS, PaaS, SaaS)“Diese Orientierung hilft bei der praktischen Auswahl für Designs von Anwendungen:
- IaaS wählen, wenn: Tiefe OS-/Runtime-Kontrolle, Legacy-Abhängigkeiten oder spezielle Anforderungen ans Netzwerk erforderlich sind.
- PaaS wählen, wenn: Schnellere Lieferung und weniger Betriebsaufwand gewünscht sind, bei weiterhin eigener Verantwortung für die Anwendung.
- SaaS wählen, wenn: Der Geschäftsprozess ein standardisiertes Produkt akzeptiert und Differenzierung keinen eigenen Plattformbetrieb erfordert.
Nicht nach Gewohnheit entscheiden. Auf Basis messbarer Anforderungen, verfügbarer Betriebskapazität und Zielen über den Lebenszyklus entscheiden.
Runtime-Auswahl für typische STACKIT-Zielbilder
Abschnitt betitelt „Runtime-Auswahl für typische STACKIT-Zielbilder“VM-Runtime (IaaS)
Geeignet für Low-Change-Migrationen und Komponenten mit OS-naher Kontrolle, Spezialagenten oder ausgeprägten Legacy-Abhängigkeiten.
Kubernetes-Runtime (PaaS-nahes Betriebsmodell)
Geeignet für containerisierte Workloads mit Bedarf an skalierbarer Ausführung, standardisierten Releases und Plattformbetrieb.
Cloud-Foundry-Runtime (PaaS)
Geeignet, wenn Teams hohe Entwicklerproduktivität und schnelle Bereitstellung über tiefe Plattformkontrolle priorisieren.
Statische Auslieferung mit Object Storage/CDN
Geeignet für Frontend-/Static-Workloads mit hohem Verteilungsbedarf und geringer Runtime-Komplexität.
SaaS-Ersatzpfad
Geeignet, wenn Prozessfit und Standardfähigkeiten mehr Mehrwert liefern als Migration und Betrieb des bisherigen Stacks.
Architektur-Guardrails für Designs von Anwendungen
Abschnitt betitelt „Architektur-Guardrails für Designs von Anwendungen“- Immer umsetzen: Ziel-Runtime, Verantwortung für Daten, Rollback-Trigger und Day-1-Betrieb vor Freigabe der Migration festlegen.
- Nur als Ausnahme: Temporärer Dual-Run, manuelle Handover oder teilweise Automatisierung nur mit explizitem Risiko und Enddatum.
- Vermeiden: Runtime-Wechsel, Datenmigration und große Integrationsänderungen in einem unkontrollierten Cutover bündeln.
- Nie umsetzen: Kein Zielbild ohne Observability-Baseline, Backup-/Recovery-Modell und klar benannte Betriebsverantwortung freigeben.
Praktischer Design-Ablauf pro Anwendung
Abschnitt betitelt „Praktischer Design-Ablauf pro Anwendung“- Anwendungsscope, Abhängigkeiten und nicht-funktionale Anforderungen bestätigen.
- Service-Modell-Fit (IaaS, PaaS, SaaS) bewerten und zulässige Runtime-Ziele eingrenzen.
- Ein Zielmuster auswählen und dokumentieren, warum Alternativen verworfen wurden.
- Datenpfad, Cutover-Sequenz, Validierungsgates und Rollback-Logik festlegen.
- Betriebsverantwortung, Monitoring-Baseline und Handover-Kriterien definieren.
- Architekturentscheidungen in das Migrations-Runbook überführen.
Typische STACKIT-Designoptionen
Abschnitt betitelt „Typische STACKIT-Designoptionen“VM-Muster mit Betriebsbaseline
Spring Boot auf VM mit Application Load Balancer, Observability-Integration und Backup-Strategie.
Kubernetes-Plattformmuster
Spring Boot auf SKE mit gemanagten Datendiensten, Object Storage, Secret Handling und Messaging.
Statische Auslieferung mit CDN-Option
Statische Auslieferung aus Object Storage mit optionaler CDN-Beschleunigung für internetseitige Nutzung.
Hybrides Connectivity-Muster
Zugriff auf den Workload über VPN und zentrale Firewall-Controls für Enterprise-Netze.
Cloud-Foundry-Muster
Spring Boot auf Cloud Foundry mit angebundenen Backing Services wie Redis und RabbitMQ.
Die Pattern-Karten dienen als mögliche Zielbilder. Pro Anwendung sollte ein explizites Zielbild gewählt werden. Mehrere Muster nur kombinieren, wenn Koexistenz bewusst als Übergangszustand geplant ist.
Best practices für Zielbilder auf STACKIT
Abschnitt betitelt „Best practices für Zielbilder auf STACKIT“- Architektur und Runbook trennen: zuerst das Zielbild definieren, danach Sequenz und Rollback für die Migration ableiten.
- Betrieb von Anfang an einplanen: Observability-Signale, Alarm-Grenzen und Backup- oder Recovery-Erwartungen im Zielzustand festlegen.
- Managed Services bewusst nutzen: gemanagte Plattform-Services bevorzugen, wenn sie Betriebsaufwand senken und keine unnötige Codeänderung erzwingen.
- Vertrauensgrenzen im Netzwerk explizit definieren: Ingress, Egress, Ost-West-Controls und Hybrid-Bedarf vor der Umsetzung dokumentieren.
- Secrets und Zugriffe als Design-Input behandeln: IAM-Rollen, Service Accounts und Secret-Manager-Nutzung früh im Architektur-Paket aufnehmen.
- Datenmigration vom Runtime-Wechsel entkoppeln: bei stateful Workloads Daten-Gates getrennt von Runtime-Cutover validieren.
- Messbare Abnahmekriterien festlegen: Verfügbarkeit, Latenz, Skalierung und Recovery müssen vor Handover prüfbar sein.
Verwandte Design-Seiten
Abschnitt betitelt „Verwandte Design-Seiten“Architektur-Assets
Abschnitt betitelt „Architektur-Assets“Diese Architektur-Assets dienen als konkrete Design-Referenzen.
Asset-Titel
Framework
Asset-Typ
Migration
Blueprint
Migration
Anleitung
Migration
Software
Migration
Software
Migration
Software
Migration
Runbook
Migration
Blueprint
Migration
Runbook
Migration
Blueprint
Migration
Blueprint
Migration
Blueprint
Migration
Software
Migration
Service
Migration
Anleitung
Ausführbare Beispiele für Migrationen (bestehend)
Abschnitt betitelt „Ausführbare Beispiele für Migrationen (bestehend)“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Migration
Runbook
Migration
Runbook
Die Architektur-Assets helfen bei Auswahl und Begründung der Zielarchitektur, die Runbook-Assets bei der konkreten Umsetzung des Migrationspfad.
Runbook und Cutover vorbereiten
Warum ein Runbook ein Design-Ergebnis ist
Abschnitt betitelt „Warum ein Runbook ein Design-Ergebnis ist“In diesem Framework wird das Runbook in der Design-Phase erstellt. Es beschreibt den geplanten Ablauf, Controls, Rollback-Logik und Handover-Kriterien je Migrationsstrategie.
Migration Factory Setup erstellt nicht die erste Runbook-Version. Dort werden Design-Runbook-Entwuerfe operativ gehärtet, standardisiert und für die Wellen-Delivery validiert.
Pflicht-Kapitel eines Runbooks
Abschnitt betitelt „Pflicht-Kapitel eines Runbooks“Jedes Migrations-Runbook sollte diese Kapitel enthalten:
- Scope und Kontext: Scope der Anwendung, Kontext von Quelle und Ziel, Annahmen, Ausschlüsse.
- Owner und Entscheidungsrechte: Technischer Owner, Release-Owner, Rollback-Verantwortung, Eskalationsweg.
- Abhängigkeiten und Voraussetzungen: Plattform-Readiness, Zugriffe, Datenlage, externe Wartungsfenster.
- Cutover-Plan: Geordnete Run-Schritte, erwartete Dauer, Freeze-Punkte, Punkte für Kommunikation.
- Validierungsprüfungen: Funktionale, nicht-funktionale, Security- und Observability-Checks mit Nachweisen.
- Rollback und Fallback: Trigger-Bedingungen, Rollback-Schritte, Fallback-Kommunikationsfluss.
- Handover und Day-1-Betrieb: Übergabe an den Betrieb, Incident-Ownership, Post-Cutover-Stabilisierungsphase.
Qualitätskriterien für ein gutes Runbook
Abschnitt betitelt „Qualitätskriterien für ein gutes Runbook“Ausführbar
Schritte sind konkret, geordnet und klar Rollen zuweisbar.
Verifizierbar
Validierungspunkte definieren eindeutige Pass/Fail-Kriterien und benötigte Nachweise.
Wiederherstellbar
Der Rollback-Pfad ist vollständig, zeitlich geplant und an explizite Trigger-Bedingungen gekoppelt.
Handover-ready
Day-1-Betrieb und Ownership-Übergabe sind vollständig spezifiziert.
Empfohlener Design-zu-Factory-Ablauf
Abschnitt betitelt „Empfohlener Design-zu-Factory-Ablauf“- Strategie-spezifischen Runbook-Entwurf in der Design-Phase erstellen.
- Technische Annahmen mit Plattform-, Security- und Operations-Stakeholdern validieren.
- Nachweis-Checkpoints und Rollback-Trigger ergänzen.
- Zur Standardisierung und Readiness-Prüfung an Migration Factory Setup übergeben.
- Nach Probe oder Pilot-Validierung für Wellen-Ausführung freigeben.
Konkretes Beispiel-Asset
Abschnitt betitelt „Konkretes Beispiel-Asset“Nutzen Sie dieses konkrete Beispiel-Runbook für einen klassischen Rehost-Fall (Spring Boot auf VM):
Asset-Titel
Framework
Asset-Typ
Migration
Runbook
- Muster: Lift-and-Shift auf Ziel-VM (kein Kubernetes)
- Anwendungstyp: Typischer Enterprise-Spring-Boot-Service mit PostgreSQL-Backend
Warum ein Runbook ein Design-Ergebnis ist
Abschnitt betitelt „Warum ein Runbook ein Design-Ergebnis ist“In diesem Framework wird das Runbook in der Design-Phase erstellt. Es beschreibt den geplanten Ablauf, Controls, Rollback-Logik und Handover-Kriterien je Migrationsstrategie.
Migration Factory Setup erstellt nicht die erste Runbook-Version. Dort werden Design-Runbook-Entwuerfe operativ gehärtet, standardisiert und für die Wellen-Delivery validiert.
Pflicht-Kapitel eines Runbooks
Abschnitt betitelt „Pflicht-Kapitel eines Runbooks“Jedes Migrations-Runbook sollte diese Kapitel enthalten:
- Scope und Kontext: Scope der Anwendung, Kontext von Quelle und Ziel, Annahmen, Ausschlüsse.
- Owner und Entscheidungsrechte: Technischer Owner, Release-Owner, Rollback-Verantwortung, Eskalationsweg.
- Abhängigkeiten und Voraussetzungen: Plattform-Readiness, Zugriffe, Datenlage, externe Wartungsfenster.
- Cutover-Plan: Geordnete Run-Schritte, erwartete Dauer, Freeze-Punkte, Punkte für Kommunikation.
- Validierungsprüfungen: Funktionale, nicht-funktionale, Security- und Observability-Checks mit Nachweisen.
- Rollback und Fallback: Trigger-Bedingungen, Rollback-Schritte, Fallback-Kommunikationsfluss.
- Handover und Day-1-Betrieb: Übergabe an den Betrieb, Incident-Ownership, Post-Cutover-Stabilisierungsphase.
Qualitätskriterien für ein gutes Runbook
Abschnitt betitelt „Qualitätskriterien für ein gutes Runbook“Ausführbar
Schritte sind konkret, geordnet und klar Rollen zuweisbar.
Verifizierbar
Validierungspunkte definieren eindeutige Pass/Fail-Kriterien und benötigte Nachweise.
Wiederherstellbar
Der Rollback-Pfad ist vollständig, zeitlich geplant und an explizite Trigger-Bedingungen gekoppelt.
Handover-ready
Day-1-Betrieb und Ownership-Übergabe sind vollständig spezifiziert.
Empfohlener Design-zu-Factory-Ablauf
Abschnitt betitelt „Empfohlener Design-zu-Factory-Ablauf“- Strategie-spezifischen Runbook-Entwurf in der Design-Phase erstellen.
- Technische Annahmen mit Plattform-, Security- und Operations-Stakeholdern validieren.
- Nachweis-Checkpoints und Rollback-Trigger ergänzen.
- Zur Standardisierung und Readiness-Prüfung an Migration Factory Setup übergeben.
- Nach Probe oder Pilot-Validierung für Wellen-Ausführung freigeben.
Konkretes Beispiel-Asset
Abschnitt betitelt „Konkretes Beispiel-Asset“Nutzen Sie dieses konkrete Beispiel-Runbook für einen klassischen Rehost-Fall (Spring Boot auf VM):
Asset-Titel
Framework
Asset-Typ
Migration
Runbook
- Muster: Lift-and-Shift auf Ziel-VM (kein Kubernetes)
- Anwendungstyp: Typischer Enterprise-Spring-Boot-Service mit PostgreSQL-Backend
Business Case
Migrationsplan
Landing Zone
Zielbild
Abschnitt betitelt „Zielbild“Account Governance beschreibt, wie Teams, Umgebungen und Zuständigkeiten in der Cloud klar getrennt und steuerbar aufgebaut werden.
Damit entsteht die organisatorische Steuerungsebene für Migrationswellen: wo Workloads betrieben werden, wem welcher Scope gehört und wie neue Projekte ohne Umgehung von Guardrails angebunden werden.
Governance-Hierarchie
Abschnitt betitelt „Governance-Hierarchie“
Governance-Design und Delivery
Abschnitt betitelt „Governance-Design und Delivery“Kernbausteine der Governance
Abschnitt betitelt „Kernbausteine der Governance“- Regions: Die Regionenstrategie bestimmt Datenlokalität, Latenzprofil und Resilienzgrenzen für Workloads und Shared Services. Definieren Sie früh verbindliche Nutzungsmuster und stimmen Sie diese mit Compliance- und Kontinuitätsanforderungen ab. Dokumentation
- Customer Account: Der Customer Account ist die oberste Governance-Grenze für Ownership, Abrechnung und Administration. Er bildet den Anker für organisationsweite Standards und Kontrollverantwortung. Dokumentation
- STACKIT Folder: Folder strukturieren organisatorische Domänen (zum Beispiel Plattform, Shared Services, Business Units, Umgebungen) und ermöglichen Policy-Vererbung sowie klare Delegationsmodelle. Dokumentation
- STACKIT Projects: Projects sind die Delivery-Scopes, in denen Ressourcen bereitgestellt und betrieben werden. Sie sollten über ein definiertes Onboarding-Modell an Folder angebunden werden und nicht ad hoc entstehen. Dokumentation
Wie die Bausteine zusammenspielen
Abschnitt betitelt „Wie die Bausteine zusammenspielen“- Regionprinzipien zuerst: Legen Sie fest, welche Regionen für welche Workload-Klassen zulässig sind.
- Customer Account als Governance-Root: Verankern Sie globale Ownership, Policy-Absicht und finanzielle Verantwortlichkeit.
- Folder für Struktur und Delegation: Überführen Sie das Betriebsmodell in skalierbare organisatorische Grenzen.
- Projects für Delivery: Stellen Sie Projektscopes über einen standardisierten Lebenszyklus mit verpflichtenden, vom Folder geerbten Kontrollen bereit.
Wichtige Entscheidungen
Abschnitt betitelt „Wichtige Entscheidungen“- Region-Governance-Modell: Entscheiden Sie zwischen Single-Region-, Dual-Region- oder Workload-basiertem Regionenansatz inklusive Ausnahmen.
- Customer-Account-Verantwortung: Definieren Sie, welche zentralen Teams Governance, Billing-Transparenz und Kontrollbetrieb verantworten.
- Folder-Topologie: Legen Sie fest, wie Folder auf Domänen wie Plattform, Umgebungen und Business Units abgebildet werden.
- Project-Onboarding-Modell: Standardisieren Sie Projekterstellung, Namenskonventionen, Tagging und Lebenszyklus-Kontrollen.
- Policies und Ausnahmen: Definieren Sie verpflichtende Guardrails und transparente Ausnahmeprozesse.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“- Governance-Blueprint: Customer-Account-, Folder- und Project-Topologie mit Verantwortungsmatrix.
- Regionen-Nutzungsrichtlinie: Freigegebene Regionenmuster je Workload-Typ und Risikoprofil.
- Project-Onboarding-Standard: Wiederholbarer Prozess für die Erstellung und Anbindung gesteuerter Projekte.
- Control-Baseline: Erzwungene Namens-, Tagging- und Policy-Kontrollen mit dokumentiertem Ausnahmefluss.
Typische Anti-Patterns
Abschnitt betitelt „Typische Anti-Patterns“- Keine Regionenrichtlinie: Regionauswahl pro Team oder Projekt ohne unternehmensweite Leitplanken.
- Unstrukturierte Project-Sprawl: Projekte entstehen ohne Folder-Strategie, klare Ownership oder Lebenszyklusstandards.
- Governance nur auf Papier: Kontrollen sind dokumentiert, aber nicht im Projekt-Onboarding und Betrieb verankert.
Zielbild
Abschnitt betitelt „Zielbild“Die Netzwerkarchitektur regelt sichere Kommunikation, Segmentierung und die Governance zentraler Connectivity-Services über Shared und projektbezogene Landing Zones.
In Enterprise-Migrationen geht es dabei weniger um einzelne Subnetze, sondern um ein dauerhaft steuerbares Konnektivitätsmodell: welches Projekt über welche Pfade angebunden wird und unter welchen Guardrails.
Referenztopologie
Abschnitt betitelt „Referenztopologie“
Connectivity-Design und Delivery
Abschnitt betitelt „Connectivity-Design und Delivery“Kernbausteine der Connectivity
Abschnitt betitelt „Kernbausteine der Connectivity“- STACKIT Network Area: Nutzen Sie eine geteilte Unternehmens-Netzwerkscope als zentrales Rückgrat für Projektanbindung und Governance-Planung. Dokumentation
- Routing Tables: Definieren und erzwingen Sie, wie Projekte innerhalb einer Network Area verbunden sind und ob ein Hub-and-Spoke-Modell mit zentraler Firewall-Kontrolle oder eine flachere Topologie genutzt wird. Dokumentation
- DNS: Standardisieren Sie Namensgebung und Service Discovery frühzeitig, damit Connectivity-Design, Zertifikatshandling und Workload-Cutovers konsistent bleiben. Dokumentation
- VPN (Connectivity): Behandeln Sie VPN als zentrale Connectivity-Fähigkeit für Hybrid- und Multi-Cloud-Integrationsmuster, nicht als isolierte Einzellösung. Dokumentation
Wichtige Entscheidungen
Abschnitt betitelt „Wichtige Entscheidungen“- Network-Area-Ownership-Modell: Entscheiden Sie, wer geteilte Connectivity zentral steuert und welche Onboarding-Kriterien für angebundene Projekte gelten.
- Routing-Strategie je Domäne: Legen Sie fest, wo Hub-and-Spoke mit zentraler Inspektion verpflichtend ist und wo eine flache Routing-Topologie ausreicht.
- Hybrid-Connectivity-Baseline: Definieren Sie, wie VPN-basierte Konnektivität in Plattformstandards und Betriebs-Lifecycle integriert wird.
- Namensauflösungsdesign: Standardisieren Sie DNS-Grenzen und Muster für Plattformservices, Shared Services und Applikations-Landing-Zones.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“- Zieltopologie und Vertrauensgrenzen: Dokumentierter Zielzustand für Segmentierung und projektübergreifende Kommunikation.
- Network-Area-Onboarding-Prinzipien: Klare Kriterien, welche Projekte angebunden werden, wie Reviews ablaufen und wie Änderungen freigegeben werden.
- Routing-Governance-Modell: Definierter Einsatz von Routing Tables inklusive Entscheidungskriterien für Hub-and-Spoke versus flaches Routing.
- Connectivity-Baseline: Wiederverwendbare Standards für VPN, DNS und gemeinsame Netzwerk-Services.
Asset-Container-Referenz
Abschnitt betitelt „Asset-Container-Referenz“Asset-Titel
Framework
Asset-Typ
Migration
Software
Typische Anti-Patterns
Abschnitt betitelt „Typische Anti-Patterns“- Ungeplantes Wachstum der Network Area: Projekte werden ohne zentrale Architekturprüfung und Ownership angebunden.
- Ad-hoc-Einsatz von Routing Tables: Inkonsistente Routing-Logik je Projekt ohne Referenzarchitektur.
- DNS als Nachgedanke: Späte DNS-Entscheidungen bremsen Migrationstermine oder stören Service Discovery.
- VPN als Ausnahmepfad: VPN wird als Sonderlösung statt als geregelte Grundlage für die Konnektivität genutzt.
STACKIT Landing Zone Accelerator
Enablement
Befähigen Sie Migrationsteams durch CCoE-Verantwortung, rollenbasiertes Lernen mit der STACKIT University, verlässliche Dokumentation und validierte KI-Unterstützung.
Migrate
Halten Sie dies so kurz wie Assess und fokussieren Sie auf den End-to-End-Ablauf in der Factory, der jede Welle zum Abschluss bringt.
Überblick: Migrate-Modul
Abschnitt betitelt „Überblick: Migrate-Modul“Dieses Modul setzt die eigentliche technische Migration in der Migration Factory um. Zu diesem Zeitpunkt sind Entscheidungen aus Design getroffen, Landing Zones aufgebaut und Wellen geplant.
Der Fokus liegt auf reproduzierbarer Umsetzung für:
- Relocate: Verlagerung von Workloads mit minimalen Änderungen an Annahmen zur Plattform.
- Rehost: Lift-and-Shift auf STACKIT mit kontrolliertem Cutover und Rollback-Bereitschaft.
- Replatform: Gezielte Anpassungen an der Plattform während der Migration ohne vollständiges Redesign.
Abhängigkeiten aus Design and Mobilize
Abschnitt betitelt „Abhängigkeiten aus Design and Mobilize“Migrate startet erst, wenn aus der vorherigen Phase umsetzbare Ergebnisse vorliegen:
- Design je Anwendung: Zielbild, Schnittstellen, Daten und nicht-funktionale Anforderungen sind festgelegt.
- Zuordnung zur Wellenplanung: Jede Anwendung ist einer freigegebenen Welle mit Zeitfenster und Abhängigkeiten zugeordnet.
- Runbook je Pfad der Migration: Für Pfad und Typ von Workload liegt ein validiertes Runbook vor, inklusive Go/No-Go-, Cutover- und Rollback-Kriterien.
- Zuordnung zur Application Landing Zone: Anwendungen sind der passenden Ziel-Landing-Zone und Ownership zugeordnet.
- Entscheidungswege und Kommunikation: Entscheidungswege, Eskalationsprozess und Kommunikation mit dem Application Owner sind festgelegt, inklusive der Frage, ob der Cutover gemeinsam durchgeführt werden muss.
Verweise auf Module:
End-to-End-Ablauf in der Factory
Abschnitt betitelt „End-to-End-Ablauf in der Factory“- Wellenscope, Cutover-Fenster, Rollback-Kriterien und Runbook-Verantwortung final bestätigen.
- Wellen-Baseline einfrieren (Versionen, Abhängigkeiten, Datenscope, Schnittstellenverträge).
- Technische Readiness-Prüfungen in Quelle und Ziel durchführen.
- Runbook-Schritte je Workload-Archetyp und R-Strategie-Pfad ausführen.
- Cutover durchführen und Traffic gemäß Wellenplan auf STACKIT umschalten.
- Technische, funktionale und operative Akzeptanzkriterien validieren.
- Stabilisierungsmaßnahmen in kurzen Feedback-Schleifen umsetzen.
- Stabilisierte Workloads an Optimize und Operate übergeben.
Ablauf je R-Pfad
Abschnitt betitelt „Ablauf je R-Pfad“Relocate-Ablauf
Abschnitt betitelt „Relocate-Ablauf“- Platzierung im Ziel auf STACKIT mit äquivalenten Annahmen zur Topologie herstellen.
- Daten und Zustände mit Konsistenzprüfungen migrieren.
- Traffic mit Rollback-Leitplanken umschalten.
- Geschäftskontinuität und operative Telemetrie verifizieren.
Rehost-Ablauf
Abschnitt betitelt „Rehost-Ablauf“- Applikationen und Daten weitgehend unverändert übertragen.
- Infrastruktur-Bindings und Konnektivität auf STACKIT neu zuordnen.
- Kontrollierten Cutover mit Smoke-Tests durchführen.
- Phase zur Stabilisierung und Performance-Baseline abschließen.
Replatform-Ablauf
Abschnitt betitelt „Replatform-Ablauf“- Ausgewählte Managed Services und Plattformfunktionen in den Pfad der Migration integrieren.
- Konfiguration, Deployment-Artefakte und Kontrollen im Betrieb anpassen.
- Cutover mit Kompatibilitäts- und Datenintegritätsprüfungen durchführen.
- SLO-Verhalten und Betriebsreife der Zielumgebung nachweisen.
Zentrale Artefakte pro Welle
Abschnitt betitelt „Zentrale Artefakte pro Welle“Runbook-Nachweise
Vollständige Runbook-Protokolle, Entscheidungsnachweise und Rollback-Checkpoints pro Workload.
Cutover-Report
Zeitlich nachvollziehbares Ergebnis mit Abnahme, Defekten und eingeleiteten Maßnahmen.
Operative Baseline
Initiales Monitoring, Alerting, Ownership und Incident-Prozesse in der Zielumgebung.
Optimize-Backlog
Priorisierte Maßnahmen für Rightsizing, Performance-Tuning und Kostenoptimierung.
Abgrenzung zu Optimize, Repurchase und Refactor
Abschnitt betitelt „Abgrenzung zu Optimize, Repurchase und Refactor“- Optimize startet direkt nach stabilem Cutover und nutzt Daten aus dem Betrieb für Tuning und Kostensteuerung: Optimize.
- Repurchase folgt einer anderen SaaS-Logik und läuft bewusst außerhalb des klassischen Modells mit Wellen: Repurchase.
- Refactor wird als eigener Pfad für Transformation geführt: Refactor.
Unterstützung direkt nach dem Cutover kann sich zeitlich mit Optimize überschneiden, wird aber inhaltlich in der Run-Phase behandelt.
Optimize
Halten Sie dies knapp: Optimize macht frisch migrierte Workloads zu kosten- und leistungsoptimierten Regelbetriebs-Services.
Überblick: Optimize-Modul
Abschnitt betitelt „Überblick: Optimize-Modul“Optimize startet, sobald Workloads auf STACKIT laufen und reale Daten aus dem Betrieb vorliegen. Das Modul überführt Beobachtungen aus dem Betrieb in messbare Verbesserungen für Performance, Stabilität und Wirtschaftlichkeit.
Optimize ist keine einmalige Aufgabe, sondern ein iterativer Zyklus, der sich mit früher Stabilisierung und Unterstützung direkt nach dem Cutover überschneiden kann.
Warum Optimize nach dem Cutover liegt
Abschnitt betitelt „Warum Optimize nach dem Cutover liegt“Viele Entscheidungen zu Rightsizing und Tuning sind erst unter echter Last belastbar. Nach dem Cutover lassen sich Annahmen mit Daten aus dem Betrieb validieren und präzisieren.
Optimize-Zyklus
Abschnitt betitelt „Optimize-Zyklus“- Laufzeitdaten erfassen: Auslastung, Latenz, Fehlerquoten, Durchsatz und Kostentreiber.
- Engpässe und Verschwendungsmuster auf Workload-, Plattform- und Datenebene identifizieren.
- Maßnahmen nach Business-Effekt, Risikoreduktion und FinOps-Nutzen priorisieren.
- Tuning-Änderungen in kontrollierten Inkrementen umsetzen.
- Ergebnisse gegen SLO-, Stabilitäts- und Kostenziele validieren.
- Erkenntnisse in Folgewellen und Betriebsstandards zurückführen.
Typische Bereiche
Abschnitt betitelt „Typische Bereiche“- Rightsizing: Compute-, Storage- und Netzwerkressourcen an reale Last anpassen.
- Performance-Tuning: Latenz und Durchsatz durch Konfiguration, Skalierung und Architekturmaßnahmen verbessern.
- Reliability-Hardening: Incident-Häufigkeit durch Resilienz-, Monitoring- und Fehlerbehandlungsmaßnahmen reduzieren.
- FinOps-Steuerung: Kostentransparenz verbessern, Verschwendung abbauen und Run-Rate optimieren.
Von der Theorie zur Umsetzung
Abschnitt betitelt „Von der Theorie zur Umsetzung“Optimierungsentscheidungen sollten auf Laufzeitdaten basieren, nicht auf Annahmen. Für die praktische Umsetzung werden Workload-Telemetrie, Alerting und kontrollierte Infrastrukturänderungen kombiniert.
- Managed-Observability-Basis: Mit STACKIT Observability Metriken, Logs und Traces mit Grafana, Prometheus, Thanos, Loki und Tempo erfassen.
- Erkennungslogik: Klare Schwellwerte und Beobachtungsfenster für Unterauslastung und Überlast definieren.
- Umsetzungspfad: Rightsizing über IaC-Änderungen (zum Beispiel VM-Flavors) mit Rollback-Checkpoints umsetzen.
- Validierungsschleife: Nach jedem Tuning-Inkrement SLO, Fehlerquote und Laufkosten erneut messen.
Konkrete Beispiel-Assets
Abschnitt betitelt „Konkrete Beispiel-Assets“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Migration
Runbook
Migration
Runbook
Migration
Runbook
Replatform-Optimierungsdimensionen
Abschnitt betitelt „Replatform-Optimierungsdimensionen“Für Replatform-Workloads auf Kubernetes umfasst Optimierung mehrere Ebenen und sollte als gemeinsamer Regelkreis gesteuert werden.
- Pod-Skalierung: HPA nutzen, um die Replikazahl anhand von Last mit klaren Min-/Max-Grenzen anzupassen.
- Node-Pool-Skalierung: Ausreichend Cluster-Headroom sicherstellen und den Maschinentyp (Flavor) für CPU-/Memory-Dichteanforderungen abstimmen.
- Ingress-Skalierung: Den Serviceplan des Load Balancers neu bewerten, wenn Ingress-Durchsatz oder Verbindungsverhalten zum Engpass werden.
- Storage-Rightsizing: Storage-Klassen nach Performance-Anforderungen persistenter Workloads auswählen.
- Validierungsdisziplin: Nach jeder inkrementellen Tuning-Änderung Latenz, Fehlerquote und Kosten erneut prüfen.
Eingaben und Ergebnisse
Abschnitt betitelt „Eingaben und Ergebnisse“Zentrale Eingaben
Cutover-Berichte, Incident-Trends, SLO-Messwerte, Telemetrie-Baselines und Kostenberichte.
Ergebnisse
Priorisiertes Verbesserungs-Backlog, validierte Tuning-Änderungen und aktualisierte Betriebsstandards.
Governance-Effekt
Nachvollziehbare Trade-off-Entscheidungen zwischen Performance, Stabilität und Kosten.
Abgrenzung zu anderen Modulen
Abschnitt betitelt „Abgrenzung zu anderen Modulen“Run
Schließen Sie die Reise kurz mit dem Run-Phasenmodell ab, damit das Publikum sieht, wo Migrationsergebnisse letztlich landen.
Überblick: Diese Phase
Abschnitt betitelt „Überblick: Diese Phase“Run ist der Zielzustand der Migration: Workloads laufen auf STACKIT mit klarer Verantwortung, stabilem Betrieb und messbarer Servicequalität.
Die Phase startet mit der Stabilisierung direkt nach dem Cutover und geht in den langfristigen Regelbetrieb über. Hier wird aus Migration ein tragfähiges Betriebsmodell.
Überblick
Abschnitt betitelt „Überblick“Run ist nicht nur ein Nachgang zur Migration, sondern das strategische Zielbild. Für viele Programme ist das operative Leitmotiv klar: möglichst viele Workloads in einen belastbaren “Runs on STACKIT”-Status überführen.
Die Phase verbindet Migrate über Hypercare mit dem laufenden Betrieb und prüft das Target Operating Model in der Praxis.
Wann Run startet und endet
Abschnitt betitelt „Wann Run startet und endet“- Start mit Hypercare direkt nach dem Cutover, solange Projekt- und Migrationsteams greifbar sind.
- Operative Lücken schließen, zum Beispiel fehlendes Monitoring, Alerting und Runbook-Anpassungen.
- Übergabe in DevOps-Verantwortung oder an ein klassisches Betriebsteam formalisieren.
- Support- und Service-Request-Modell zwischen Kunde und Anbieter verbindlich aktivieren.
- In den Regelbetrieb mit kontinuierlicher Optimierung und regelmäßiger Betriebsmodell-Prüfung überführen.
Je nach Betriebsmodell können Teile der Übergabe bereits während Migrate beginnen und mit Wellen überlappen.
Operating Model Handover ist in Migrate verankert und kann bereits vor Start der Run-Phase aktiv sein.
Run-Phasenmodell und Module
Abschnitt betitelt „Run-Phasenmodell und Module“Run verbindet kurzfristige Stabilisierung mit langfristigem Cloud-Betrieb. Das folgende Modell zeigt den Ablauf von der Migrationsübergabe bis zum stabilen Day-2-Betrieb.
Semantische Einordnung
Abschnitt betitelt „Semantische Einordnung“Das Run-Modell arbeitet mit vier semantischen Strömen zur klaren Einordnung von Verantwortung und Zweck:
- Stabilisierung: Hypercare schließt Post-Cutover-Risiken, solange Delivery-Teams noch direkt eingebunden sind.
- Betrieb: Operate sichert Zuverlässigkeit, Security, Observability und kontrollierte Änderungen im Regelbetrieb.
- Service: Support klärt Incident-Verantwortung sowie provider- und kundenseitige Service Requests.
- Nutzen: Customer Success sichert dauerhafte Adoption und Business-Outcome.
Warum diese Phase wichtig ist
Abschnitt betitelt „Warum diese Phase wichtig ist“Brücke von Projekt zu Betrieb
Hypercare stabilisiert offene Migrationsthemen, bevor daraus dauerhafte Störungsmuster entstehen.
Klare Ownership und Supportmodell
Eindeutige Verantwortungen für Störungen und Service Requests reduzieren Reibung und Eskalationen.
Betriebliche Resilienz
Monitoring, Observability und Runbook-Reife stärken Zuverlässigkeit und Wiederherstellungsverhalten.
Dauerhafte Wertrealisierung
Kontinuierliche Verbesserungen halten Performance, Kosten und Service-Ergebnisse im Zielbild.
Module in dieser Phase
Abschnitt betitelt „Module in dieser Phase“- Hypercare: Stabilisierungsbrücke von Migrate nach Run mit schneller Rückkopplung und kontrollierter Nacharbeit.
- Operate: Regelbetrieb in der Cloud auf STACKIT mit Fokus auf Stabilität, Security und Effizienz.
- Support: Betriebsmodell für Störungen und Service Requests zwischen Kunde und Anbieter.
- Customer Success: Baustein mit zentralem Kontakt für Adoption und Outcome-Tracking.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“Zum Ende der initialen Run-Etablierung sollten vorliegen:
- Stabilisierter Post-Cutover-Betrieb: Kritische Themen aus der Migration sind behoben oder mit klaren Maßnahmen abgesichert.
- Geschlossene Betriebslücken: Fehlendes Monitoring, Alerting und betriebliche Nachweise sind umgesetzt.
- Validiertes Übergabemodell: DevOps- oder klassisches Betriebsmodell ist in realen Situationen im Betrieb getestet.
- Aktives Supportmodell: Incident- und Request-Pfade sind produktiv, dokumentiert und messbar.
- Belastbare Run-Governance: Servicequalität, Kostenentwicklung und Verbesserungs-Backlog werden regelmäßig gesteuert.
Überblick zum ISV-Onboarding
Ein Formular auf dem Marketplace vermittelt Ihnen einen festen Partner Manager, und ein 30- bis 45-minütiges Discovery-Gespräch klärt die gegenseitige Passung, bevor eine Seite Zeit in Engineering oder Recht investiert. Bringen Sie einen Business Owner und einen Technical Lead mit, denn das Gespräch deckt beide Perspektiven ab.
Das ISV Factory Framework verstehen
Abschnitt betitelt „Das ISV Factory Framework verstehen“Das ISV Factory Framework führt Softwareanbieter auf einem strukturierten Weg vom ersten Kontakt bis zur vollen Marketplace-Reife. Es ist in klare Phasen unterteilt — vom Onboarding über die technische Validierung bis zu Qualitätsbewertung und Marketplace-Placement — und sorgt dafür, dass deine Lösung in Performance, Sicherheit und Integration mit STACKIT überzeugt. Die einzelnen Schritte unten zeigen dir die wichtigsten Meilensteine und Anforderungen auf deinem Weg.
Framework-Übersicht
Abschnitt betitelt „Framework-Übersicht“Die folgende Übersicht fasst den ISV-Weg vom Erstkontakt bis zum Live-Listing im Marketplace zusammen. Sie schafft ein gemeinsames Verständnis zu Ergebnissen, Abhängigkeiten und Erwartungen über alle zehn Phasen hinweg.
Im KickOff wird aus der ersten Qualifizierung konkrete Strategiearbeit. Beide Teams stimmen Geschäftsmodell, Compute-Ressourcen, Go-to-Market-Ansatz und Förderprogramme ab, damit der Produktlaunch im STACKIT Marketplace tragfähig und skalierbar wird.
Ziele & wichtige Stakeholder
Abschnitt betitelt „Ziele & wichtige Stakeholder“Das wichtigste Ziel des KickOff-Meetings ist zu prüfen, ob das Vorhaben für beide Seiten finanziell und technisch machbar ist — bevor Verträge unterschrieben werden.
- STACKIT-Rollen: Partner Manager, Partner Solution Architect
- ISV-Rollen: Business Lead / Product Manager, Lead Architect / CTO
Business-Case-Angaben, die der ISV liefert
Abschnitt betitelt „Business-Case-Angaben, die der ISV liefert“Um einen realistischen Business Case und die Ressourcen-Baseline zu erstellen, liefert der ISV zentrale Parameter zu Produktarchitektur und kommerziellen Zielen:
| Kategorie | Erforderliche Angaben | Zweck |
|---|---|---|
| Preis- & Lizenzmodell | SaaS-Abo, nutzungsbasiert, BYOL (Bring Your Own License) oder gestufte Preise. | Legt die Transaktionsabwicklung im STACKIT Marketplace fest. |
| Ressourcenbedarf | Geschätzter Durchschnitts- und Spitzenbedarf an Compute (vCPU, RAM), Storage (NVMe/S3), Netzwerkbandbreite und Managed Services (z. B. STACKIT Postgres/Kubernetes). | Berechnet geschätzte STACKIT-Infrastrukturkosten und Margenmodelle. |
| Zielgruppe & Branchen | Konkrete Branchen (z. B. Public Sector, Gesundheitswesen, Finanzen) oder Enterprise-Segmente. | Stimmt GTM-Kampagnen und Compliance-/Zertifizierungsanforderungen ab. |
| Vertriebs- & Umsatzerwartung | Prognostizierte Onboarding-Pipeline und erwartete Kundenanmeldungen über 12–24 Monate. | Validiert die wirtschaftliche Tragfähigkeit und Förderfähigkeit für STACKIT-Programme. |
Partnering- & Go-to-Market-Modelle
Abschnitt betitelt „Partnering- & Go-to-Market-Modelle“Während des KickOff einigen sich beide Parteien auf die Struktur des gemeinsamen Go-to-Market-Ansatzes:
1. Co-Selling & Referral
- Gemeinsame Vertriebsaktivität, bei der der STACKIT-Vertrieb die ISV-Lösung bestehenden Enterprise-Accounts empfiehlt.
- Lead-Sharing sowie Provisions-/Referral-Strukturen werden pro Transaktionstyp vereinbart.
2. Marketplace Resell
- STACKIT tritt im Marketplace als Merchant of Record (bzw. Vermittler) auf.
- Billing und Metering sind vollständig über STACKIT integriert und automatisiert.
Verfügbare Förderung & Unterstützung
Abschnitt betitelt „Verfügbare Förderung & Unterstützung“STACKIT unterstützt qualifizierte ISVs während des Onboardings, um anfängliche Entwicklungsrisiken zu reduzieren:
- PoC-Infrastruktur-Credits: Cloud-Credits zur Deckung der STACKIT-Infrastrukturkosten während Entwicklung, Testing und Technical Quality Gates.
- Architektur-Support: Direkter Zugang zu STACKIT Solution Architects für Reviews von Cloud-native Design, Kubernetes-Deployment und Security-Compliance.
- Co-Marketing-Support: Gemeinsame PR, Blogposts und Featured-Placement-Möglichkeiten im STACKIT Marketplace beim Launch.
Abschlusskriterien der Phase
Abschnitt betitelt „Abschlusskriterien der Phase“Am Ende des KickOff wird eine klare Verantwortung für die unmittelbar nächste Phase zugewiesen:
- ISV-Aufgabe: Business-Case-Angaben finalisiert und der ausgefüllte Onboarding-Fragebogen zurückgesendet.
- STACKIT-Aufgabe: Maßgeschneidertes Partnership Agreement erstellt und die Signing-Phase vorbereitet.
- Gemeinsame Aufgabe: Abstimmungscall zum technischen PoC nach Vertragsunterzeichnung terminiert.
- Meilenstein erreicht: Business Case validiert — bereit für Signing & Legal Alignment.
Support & Kontakt
Abschnitt betitelt „Support & Kontakt“Für Fragen zum Business Case, zu Förderprogrammen oder Go-to-Market-Modellen kontaktiere deinen
festen STACKIT Partner Manager oder das ISV-Factory-Team unter
isv-sales@digits.schwarz.
In der Phase Technical Proof of Concept (PoC) wird aus deiner Architekturplanung Realität. Ziel dieser Phase ist es, eine funktionierende Version deiner Anwendung auf STACKIT zu deployen, um technische Machbarkeit, Performance und Kosteneffizienz zu validieren, bevor du in Richtung Produktionsreife weitergehst.
Deployment-Strategie & Landing Zone
Abschnitt betitelt „Deployment-Strategie & Landing Zone“Eine zentrale Entscheidung vor dem Rollout deiner Infrastruktur ist die Festlegung deiner Tenant-Strategie. Sie wirkt sich stark auf deine STACKIT-Organisation-, Folder- und Projektstruktur aus:
-
Multitenant-Strategie: Mehrere Kunden teilen sich dieselbe Infrastruktur und Anwendungsinstanz, logisch getrennt.
-
Customer Dedicated (Single Tenant): Jeder Kunde erhält ein isoliertes STACKIT-Projekt und eine isolierte Infrastrukturumgebung.
Beschleunige dein Setup. Um einen schnellen, automatisierten und standardisierten Rollout deiner Cloud-Umgebung zu unterstützen, stellt STACKIT Infrastructure-as-Code (IaC)-Assets bereit:
- Landing Zone Accelerator — Best-Practice-Templates zum Aufbau deiner STACKIT-Umgebung. Dedizierte Landing-Zone-Repositories, speziell zugeschnitten auf die Multitenant- und Customer Dedicated-Modelle, sind geplant: github.com/stackitcloud/stackit-landing-zone
- STACKIT GitHub Repositories — Open-Source-Projekte, Terraform Provider und SDKs: github.com/stackitcloud
Resilienz, Skalierung und Compliance
Abschnitt betitelt „Resilienz, Skalierung und Compliance“Beim Bau deines PoC musst du Wachstum, Stabilität und Sicherheit von Anfang an mitdenken:
- Skalierung: Wie skaliert die Architektur deiner Anwendung, um plötzliches Nutzerwachstum oder erhöhte Auslastung ohne Performance-Einbußen zu bewältigen?
- Redundanz & Hochverfügbarkeit (HA): Definiere deine Verfügbarkeitsanforderungen. Benötigt deine Anwendung ein Single-Region-Setup, oder brauchst du eine Multi-Region-Architektur, um Ausfälle zu vermeiden?
- Compliance (TOMs): Mit der Unterzeichnung des Partner Base Agreement (PBA) hat sich deine Organisation technisch zu den Technischen und Organisatorischen Maßnahmen (TOMs) in Annex 2 verpflichtet. Deine PoC-Architektur muss diese Sicherheits- und Datenschutzstandards abbilden und umsetzen.
Architektur-Blueprinting & Zieldesign
Abschnitt betitelt „Architektur-Blueprinting & Zieldesign“Sobald du dein Deployment-Modell, deine Isolationsstrategie und deine Resilienzanforderungen festgelegt hast, überführst du diese Spezifikationen in einen formalen Architektur-Blueprint.
Wenn du deine Software-Komponenten (Microservices, zustandsbehaftete Daten, Caching-Layer, externe Schnittstellen) direkt auf STACKIT-Services abbildest — etwa SKE, PostgreSQL Flex, Object Storage und STACKIT Network Area — entsteht eine klare Zielarchitektur. Dieser Blueprint ist die Grundlage für eine präzise Kostenmodellierung und die anschließende Automatisierung über IaC.
Infrastrukturkalkulation & Kostenverfolgung
Abschnitt betitelt „Infrastrukturkalkulation & Kostenverfolgung“Mit deinem definierten Architektur-Blueprint modellierst und verfolgst du deinen Ressourcenverbrauch gegenüber deinen ursprünglichen Business-Case-Schätzungen:
- Computing Calculator — modelliere deinen geschätzten monatlichen Compute-, Netzwerk- und Storage-Bedarf für die Ziel-PoC-Architektur: calculator.stackit.cloud/computing
- STACKIT-Preisliste — Referenz für einen vollständigen Überblick über alle SKUs, da manche neueren Plattform-Services im Calculator noch nicht abgebildet sein könnten.
Infrastructure as Code (IaC) & CI/CD-Pipelines
Abschnitt betitelt „Infrastructure as Code (IaC) & CI/CD-Pipelines“Für produktionsreife Software solltest du auf manuelle Provisionierung über das Portal verzichten — sie kostet Zuverlässigkeit und erzeugt laufenden Betriebsaufwand. Infrastructure as Code (IaC) ist der Industriestandard für cloud-native Deployments.
Infrastructure as Code
Abschnitt betitelt „Infrastructure as Code“Der Einsatz deklarativer Tools stellt sicher, dass deine Infrastruktur wiederholbar, versionskontrolliert und auditfähig ist:
- Primäres Tooling: Nutze den offiziellen STACKIT Terraform Provider, um Compute, Storage, Netzwerk, SKE (Kubernetes) und Datenbank-Ressourcen zu deklarieren: registry.terraform.io
- Automation-First: Verwalte alle IaC-Skripte in der Versionskontrolle (z. B. GitHub, GitLab, STACKIT GIT).
- STACKIT-Git-Pipelines: Wenn du deine Repositories auf STACKIT Git hostest, laufen die integrierten Pipelines für deine IaC- und Build-Workflows direkt neben dem Code — der First-Steps-Guide führt durch das erste Runner- und Workflow-Setup: docs.stackit.cloud — Pipelines first steps
Empfohlene CI/CD-Pipeline-Architektur
Abschnitt betitelt „Empfohlene CI/CD-Pipeline-Architektur“Eine standardisierte Continuous-Integration-/Continuous-Deployment (CI/CD)-Pipeline automatisiert den Lebenszyklus sowohl deiner Infrastruktur als auch deiner Anwendungs-Workloads.
- Code Commit & Trigger: Änderungen am Anwendungscode oder an IaC-Templates lösen die automatisierte Pipeline aus.
- Linting & statische Sicherheitsanalyse: Validiere Terraform-Konfigurationen (
terraform validate,tflint) und scanne Container-Images auf Schwachstellen — entweder indem du Trivy direkt als Pipeline-Schritt ausführst, oder indem du dich auf die Schwachstellenscans verlässt, die die STACKIT Container Registry bei gepushten Images durchführt. Beides zusammen ergibt sowohl ein Gate in der Pipeline als auch ein fortlaufendes Rescanning bereits gespeicherter Images. - Infrastruktur-Provisionierung (IaC-Schritt): Führe
terraform planzur automatisierten Verifikation aus, gefolgt vonterraform apply, um STACKIT-Ressourcen in der Ziel-PoC-Umgebung zu provisionieren oder zu aktualisieren. - Workload-Deployment: Deploye Anwendungscontainer auf die STACKIT Kubernetes Engine (SKE) mit Helm als Paketierungsformat — entweder pipeline-gesteuert über den Terraform Helm Provider (Infrastruktur und Workload bleiben in einem deklarativen Lauf) oder pull-basiert über eine GitOps-Engine wie Argo CD oder Flux, die den Chart aus deinem Git-Repository abgleicht. Vermeide imperative
kubectl apply-Schritte, da sie keinen abgleichbaren Sollzustand hinterlassen. PaaS-Anwendungen werden über Cloud Foundry (cf push) deployt. - Automatisierte Integrationstests: Führe Smoke-Tests gegen die frisch deployten Endpunkte aus, um die Verfügbarkeit der Services zu prüfen.
- Secrets Management: Stelle sicher, dass Pipeline-Runner über kurzlebige API-Tokens oder die Integration mit dem STACKIT Secrets Manager auf STACKIT-Service-Accounts zugreifen — hinterlege niemals API-Keys oder Zugangsdaten fest im Repository.
- STACKIT Container Registry: Zentrale Registry für deine Build-Artefakte, inklusive Schwachstellenscans gepushter Images: docs.stackit.cloud — Container Registry
Abschlusskriterien der Phase
Abschnitt betitelt „Abschlusskriterien der Phase“Die PoC-Phase ist abgeschlossen, wenn folgende Punkte bestätigt sind:
- Ziel-Architektur-Blueprint erstellt und auf STACKIT-Services gemappt.
- Anwendung erfolgreich im STACKIT-PoC-Projekt deployt und lauffähig.
- Infrastruktur-Provisionierung mittels IaC automatisiert (z. B. Terraform / Landing Zone Accelerator).
- Tenant-Isolationsstrategie (Multitenant oder Customer Dedicated) in der Folder-/Projekthierarchie umgesetzt.
- PoC-Umgebungskosten berechnet und mit dem Partner Manager besprochen.
- Automatisierte CI/CD-Deployment-Pipeline eingerichtet.
- Sicherheits- und Compliance-Kontrollen (PBA Annex 2 TOMs) technisch validiert.
- Meilenstein erreicht: PoC validiert — bereit für das ES³ Self Assessment.
Support & Kontakt
Abschnitt betitelt „Support & Kontakt“Nutze während der PoC-Phase folgende Ressourcen zur Unterstützung deiner Entwicklung:
- STACKIT Knowledge Base — technische Dokumentation, API-Referenzen und praktische Tutorials: docs.stackit.cloud
- STACKIT Status Page — Echtzeitinformationen zur Plattformverfügbarkeit und Systemwartungen: status.stackit.cloud
Brauchst du Unterstützung? Wenn du während deines PoC auf technische Blocker stößt,
kontaktiere deinen Partner Manager oder das ISV-Factory-Team unter
isv-sales@digits.schwarz.
Der European Sovereign Stack Standard (ES³) ist das digitale Souveränitätsprogramm von STACKIT. Er macht das sonst vage Konzept digitaler Souveränität objektiv messbar, in einem Markt, in dem “Sovereignty Washing” und vage Marketingversprechen verbreitet sind. Motor des Programms ist das Sovereignty Maturity Level (SML) Framework, ein auditierbares Bewertungsframework, dessen Kriterien von der unabhängigen Prüfgesellschaft BDO verifiziert wurden.
Das Framework folgt drei Leitprinzipien:
- Auditierbarkeit: Bewertungen müssen evidenzbasiert, nachvollziehbar und reproduzierbar sein.
- SML-Klassifizierung: Reifegrade werden anhand definierter Pflichtkontrollen je Stufe zugewiesen.
- Vergleichbarkeit: Ergebnisse sind zwischen Services und Anbietern sowie über die Zeit vergleichbar.
Die neun Souveränitätsdimensionen
Abschnitt betitelt „Die neun Souveränitätsdimensionen“Das SML-Framework baut auf den acht Souveränitätszielen des offiziellen EU Cloud Sovereignty Framework (CSF) auf und ergänzt eine neunte, zukunftskritische Dimension: Künstliche Intelligenz.
| ID | Dimension | Was bewertet wird |
|---|---|---|
| SML 1 | Strategisch | Unternehmensführungsstruktur, Eigentümerabhängigkeiten, Transparenz der Eigentumsstrukturen und Aufsicht des Managements über Service-Substitution und Exit-Fähigkeit. |
| SML 2 | Rechtlich & Jurisdiktion | Anwendbare Rechtsrahmen, geografische Verarbeitungsgrenzen und Rechtsschutz gegen extraterritoriale Ansprüche Dritter oder widersprüchliche Zugriffsanfragen. |
| SML 3 | Daten | Kundengesteuerte Zugriffsverwaltung, Datenportabilität über Umgebungen hinweg, zweckgebundene Nutzungsbeschränkungen und langfristige kryptografische Resilienz. |
| SML 4 | Operativ | Zuweisung der operativen Tagesverantwortung, Einschränkung und Auditierung privilegierter Zugriffe, autonome Incident Response und Disaster Recovery. |
| SML 5 | Lieferkette | Transparenz von Subprozessoren und Softwarekomponenten (SBOM), Vendor-Risikomanagement, Minderung kritischer Abhängigkeiten und Vendor-Substitutions-Workflows. |
| SML 6 | Technologie | Deployment innerhalb genehmigter geografischer Grenzen, Einsatz offener Standards gegen Vendor-Lock-in, Architekturtransparenz und Komponentenportabilität. |
| SML 7 | Sicherheit & Compliance | Least-Privilege-Identitäts- und Zugriffskontrolle, Verschlüsselung über den gesamten Datenlebenszyklus, Kundeneinblick in Sicherheitslogs und Isolation risikoreicher operativer Aufgaben. |
| SML 8 | Umweltverträglichkeit | Energieabhängigkeiten der Infrastruktur, Abhängigkeiten in der Lieferkette bei Hardware und Kühlung, Umweltrisikoplanung und Offenlegung von Nachhaltigkeitskennzahlen. |
| SML 9 | KI | Unternehmerische Rechenschaftsmodelle, Erklärbarkeit von Systemen, Abhängigkeit von externen Softwareanbietern und Schutz von Trainingsdaten und Modellkomponenten. |
Jede Dimension wird auf drei verpflichtenden Umsetzungsebenen bewertet, sodass eine Anforderung niemals allein auf dem Papier erfüllt ist:
- Ebene 1 — Vertraglich (Regulatorisch): vertragliche Regelungen und Zusicherungen, wie Service-Vereinbarungen, SLAs und rechtliche Vereinbarungen.
- Ebene 2 — Governance & Betrieb (Organisation): organisatorische Verantwortlichkeiten, Richtlinien, Verfahren und operative Prozesse.
- Ebene 3 — Technisch (Technologie): technische Umsetzung und Systemkonfiguration, wie Sicherheitsmaßnahmen, Konfigurationen und Automatisierung.
Die vier Sovereignty Maturity Levels
Abschnitt betitelt „Die vier Sovereignty Maturity Levels“| Stufe | Kurzform | Beschreibung |
|---|---|---|
| 1 Initial | Ad hoc, nicht standardisiert | Starke Abhängigkeit von externen Anbietern. Prozesse sind reaktiv, digitale Abhängigkeiten werden nicht gesteuert und sind nicht im Risikomanagement verankert. |
| 2 Managed | Dokumentiert, regelbasiert | Digitale Abhängigkeiten sind identifiziert und im Risikomanagement dokumentiert. Erste Notfall- und Wiederherstellungspläne existieren, sind aber noch nicht vollständig getestet. |
| 3 Advanced | Strukturiert, konsistent | Souveränität ist als strategisches Ziel verankert. Für jeden geschäftskritischen Service existiert mindestens eine alternative Bezugsoption oder ein dokumentierter Migrationspfad. Daten werden überwiegend innerhalb der EU/EWR verarbeitet. |
| 4 Future-Proof | Optimiert, robust | Nahezu vollständige digitale Autonomie auf selbstbetriebener oder souverän kontrollierter Infrastruktur, offenen Standards und europäischen Lieferketten. Verbleibende Abhängigkeiten sind bewusst gewählt und jederzeit substituierbar. |
Was bewertet wird — und wer verantwortlich ist
Abschnitt betitelt „Was bewertet wird — und wer verantwortlich ist“Bewertungsgegenstand ist immer die Kombination aus einem kundenseitigen Service und seinem Service-Anbieter, einschließlich der zugrunde liegenden Services, auf denen er aufbaut. Bevor die Bewertung beginnt, wird der Service anhand von Servicename, Service-Anbieter und Servicetyp (IaaS, PaaS, SaaS, Managed Service, KI-Service) klassifiziert. Der Servicetyp bestimmt nur, welche Kontrollen anwendbar sind — er hat keinen Einfluss auf den resultierenden Reifegrad.
Jede Kontrolle wird genau einem Control Scope zugeordnet, der festlegt, wer dafür verantwortlich ist:
| Scope | Abk. | Bedeutung für einen ISV |
|---|---|---|
| Underlying Service | US | Die Plattform, auf der du aufbaust — für einen Marketplace-ISV typischerweise STACKIT. |
| Service Provider | SP | Deine Organisation, die den Service entwickelt, betreibt und dafür verantwortlich ist. |
| Client-facing Service | CFS | Das konkrete Produkt, das du an deinen Kunden lieferst. |
Diese Aufteilung vermeidet doppelte Audits und macht vererbte Nachweise prüfbar:
- Kontrollen auf SP-Ebene werden einmal bewertet und für alle deine Services übernommen.
- Kontrollen auf US-Ebene werden nicht von dir umgesetzt. Sie werden durch geeignete Nachweise des Plattformanbieters (Zertifikate, Audit-Berichte) abgedeckt und gelten als übernommen — das bedeutet, der Souveränitätsreifegrad der Plattform, auf der du aufbaust, prägt direkt, welche Stufe dein eigener Service erreichen kann.
- Kontrollen auf CFS-Ebene betreffen das konkrete Produkt, das du an deinen Kunden lieferst, und müssen für jeden Service einzeln bewertet werden — sie werden weder von deinen SP-Kontrollen noch von der zugrunde liegenden Plattform übernommen.
Anforderungen an Nachweise
Abschnitt betitelt „Anforderungen an Nachweise“Das Framework ist hierarchisch aufgebaut: Dimension → Kontrollziel → Kontrolle → Frage → Nachweis. Du antwortest auf der Kontroll-Ebene, nicht auf Fragenebene — die Fragen unter jeder Kontrolle im Katalog sind Beispiele, die die Absicht der Kontrolle verdeutlichen, keine Checkliste, die du separat abarbeiten musst. Jede Kontrolle wird binär beantwortet — “Ja”, “Nein” oder “N/A” — und mit einem Nachweis hinterlegt. Erfüllt ist eine Kontrolle nur, wenn sie mit “Ja” beantwortet ist und der Nachweis das auch stützt. Ein “N/A” wird nur akzeptiert, wo es objektiv nicht anwendbar und begründet ist.
Nachweise müssen spezifisch, überprüfbar und einer Kontrolle direkt zuordenbar sein. Pauschalaussagen wie “Dokumentation vorhanden” oder “Prozess existiert” reichen nicht aus; ein unabhängiger Dritter muss die Bewertung vollständig nachvollziehen können. Zulässige Nachweistypen:
- Verträge oder rechtliche Vereinbarungen
- Richtlinien und Verfahrensdokumentation
- Technische Konfigurationen oder Systemauszüge
- Audit-Berichte oder Zertifizierungen
- Architekturdiagramme
Wie du bei der Bewertung vorgehst
Abschnitt betitelt „Wie du bei der Bewertung vorgehst“Die gesamte Bewertungskette — Serviceklassifizierung, Bearbeitung des Kontrollkatalogs, Nachweis-Upload und Tracking deiner Zielstufe — ist im ES³ Tool abgebildet:
- ES³ Tool: es3.runs.onstackit.cloud
- Bestimme deinen Ausgangspunkt: Nutze die ES³ Lens, das interaktive Presales-Bewertungstool, um vor der Festlegung auf eine Zielstufe eine sofortige Reifegrad-Scorecard für deine Infrastruktur zu erhalten.
- Arbeite dich in Framework und Katalog ein: Lies die SML-Framework-Spezifikation und den herunterladbaren Framework-Katalog, in dem jede Bewertungsfrage mit ihrer Dimension, Kontrolle, Servicetyp, erwartetem Nachweistyp und Nachweisbeispiel aufgeführt ist.
- Klassifiziere deinen Service: Lege Servicename, Service-Anbieter und Servicetyp fest. Diese Klassifizierung ist für die gesamte Bewertung bindend und bestimmt, welche Kontrollen gelten.
- Sammle Nachweise je Kontrolle: Arbeite die anwendbaren Kontrollen entlang aller drei Umsetzungsebenen ab, beantworte jede direkt, und ordne genau einen spezifischen, überprüfbaren Nachweis zu, der deine Antwort belegt.
- Stimme deine Zielstufe ab: Bespreche mit deinem STACKIT Partner Manager, welchen Reifegrad deine Lösung erreichen soll — er bestimmt über die separate SML-Mapping-Tabelle, welche Kontrollen für dich verpflichtend sind.
- Validierung: Deine Ergebnisse werden im Rahmen des Technical Quality Gate überprüft — dort wird auch das Souveränitäts-Siegel für dein Marketplace-Listing vergeben.
- ES³-Programmübersicht: stackit.com — ES³
- SML-Framework-Spezifikation (PDF): Framework and Criteria Specification
- ES³ Tool: es3.runs.onstackit.cloud
- STACKIT Partner Portal: partner-portal.stackit.cloud
Abschlusskriterien der Phase
Abschnitt betitelt „Abschlusskriterien der Phase“- Framework geprüft: Dein Security- oder Technical Lead hat SML-Framework-Spezifikation und Kriterienkatalog durchgearbeitet.
- Service klassifiziert: Servicename, Service-Anbieter und Servicetyp für die Bewertung festgelegt.
- Bewertung abgeschlossen: Alle anwendbaren Kontrollen über die vertragliche, organisatorische und technische Ebene beantwortet, jeweils durch spezifische Nachweise belegt.
- Zielstufe abgestimmt: Der angestrebte Sovereignty Maturity Level ist mit deinem STACKIT Partner Manager festgelegt.
- Ergebnisse eingereicht: Bewertungsergebnisse zur Validierung im Technical Quality Gate übergeben.
Support & Kontakt
Abschnitt betitelt „Support & Kontakt“Für Fragen zu einzelnen Kontrollen, Souveränitätskriterien oder dem Bewertungstooling
kontaktiere das ES³-Programmteam unter ES3@digits.schwarz. Für Fragen, wie die Bewertung in
dein ISV-Onboarding passt, wende dich an das ISV-Factory-Team unter
isv-sales@digits.schwarz.
Die Placement-Phase überführt deine validierte Softwarelösung in ein kommerziell verfügbares Produkt im STACKIT Marketplace. In dieser Phase werden kommerzielle Strukturen aufgesetzt, Produkt-SKUs erzeugt und deine Storefront-Präsenz erstellt.
Den STACKIT Marketplace kennenlernen
Abschnitt betitelt „Den STACKIT Marketplace kennenlernen“Für einen klaren Überblick, wie Softwarelösungen Enterprise-Kunden präsentiert und ausgeliefert werden, sieh dir die offizielle STACKIT-Marketplace-Einführung an:
- STACKIT Marketplace Overview: youtu.be/9FK_SIQAgwM
Marketplace-Vendor-Dokumentation & Onboarding
Abschnitt betitelt „Marketplace-Vendor-Dokumentation & Onboarding“Alle technischen, operativen und kommerziellen Richtlinien für das Listing und die Integration deines Produkts sind in unserer zentralen Vendor-Dokumentation gepflegt.
- STACKIT-Dokumentation für Marketplace Vendors: docs.stackit.cloud — for marketplace vendors
Die Dokumentation führt dich durch folgende Schritte:
- Kommerzielles & operatives Onboarding: Anforderungen zum Aufsetzen deines Vendor-Profils und deiner kommerziellen Strukturen.
- Produkteinreichung: Vervollständigen der erforderlichen Produktdetails, Preismodelle und Marketing-Assets.
- Listing- & Integrationsoptionen: Anleitung zu Standard-Storefront-Listings sowie automatisierter Provisionierung und Metering über Marketplace-APIs.
Kommerzielles Onboarding & SKU-Erstellung
Abschnitt betitelt „Kommerzielles Onboarding & SKU-Erstellung“Bevor ein Listing live gehen kann, müssen die während des KickOff und Signing vereinbarten kommerziellen Parameter operationalisiert werden:
- Product Delivery Sheet: Der ISV liefert finale Produktdetails, Marketing-Assets, Preisstufen und Beschreibungen über das standardisierte Product Delivery Sheet.
- SKU-Erstellung: STACKIT erstellt die offiziellen Stock Keeping Units (SKUs) in der Billing-Engine, um Transaktionsabwicklung, Rechnungsstellung oder Referral-Tracking zu ermöglichen.
Marketplace-Listing vs. Integration
Abschnitt betitelt „Marketplace-Listing vs. Integration“Das kommerzielle Placement gliedert sich je nach gewählter Integrationstiefe in zwei unterschiedliche Stufen:
| Stufe | Umfang & Umsetzung |
|---|---|
| Stufe 1: Marketplace Listing (Standard) | Listing-Erstellung: STACKIT Partner Manager (PDMs, ISV Sales und ISV-GTM-Teams) erstellen deinen Storefront-Eintrag mit dem Marketplace Listing Wizard anhand deines Product Delivery Sheets. Lead-/Anfrage-Handling: Kunden können dein Produkt finden, Angebote anfragen oder eine manuelle Bereitstellung anstoßen. |
| Stufe 2: Marketplace Integration (optional) | Automatisierte Provisionierung & Metering: Tiefe API-Integration zwischen deiner Software und den STACKIT-Marketplace-APIs. Nutzungsbasiertes Billing: Automatisiertes Metering-Tracking und Ein-Klick-Kundenbereitstellung. |
Abschlusskriterien der Phase
Abschnitt betitelt „Abschlusskriterien der Phase“- Vendor-Dokumentation von deinen kommerziellen und technischen Teams geprüft.
- Produktdetails und kommerzielle Strukturen gemäß Vendor-Richtlinien eingereicht.
- Product Delivery Sheet vom ISV ausgefüllt und eingereicht.
- Billing-SKUs im STACKIT-System erstellt.
- Storefront-Entwurf über den Marketplace Listing Wizard erstellt und von beiden Teams freigegeben.
- Meilenstein erreicht: Kommerzielles Listing freigegeben — bereit für Ready for Production.
Support & Kontakt
Abschnitt betitelt „Support & Kontakt“Für Fragen zur Vendor-Dokumentation, zur SKU-Erstellung oder zum Marketplace Listing Wizard
kontaktiere deinen STACKIT Partner Manager oder das ISV-Factory-Team unter
isv-sales@digits.schwarz.