Plattform-Eigentum für KMU: Ein Playbook vom gemieteten Silo zur eigenen, tragfähigen Infrastruktur
Mehr als die Hälfte der EU-Unternehmen setzt auf Cloud-Dienste. So betreiben Sie als KMU kritische Plattformschichten Schritt für Schritt eigenständig, ohne eine 24/7-Plattformcrew aufzubauen.
Inhalt
Mehr als die Hälfte der EU-Unternehmen setzt auf Cloud-Dienste. So betreiben Sie als KMU kritische Plattformschichten Schritt für Schritt eigenständig, ohne eine 24/7-Plattformcrew aufzubauen.
Artikel teilen
Die Erneuerung, die plötzlich doppelt kostet
Es ist Dienstagmorgen. Die Geschäftsführung eines 42-Personen-Industriedienstleisters in Süddeutschland öffnet das E-Mail-Postfach und findet das Angebot zur Verlängerung der verwalteten Kundenportal-Plattform. Der Preis ist um 35 Prozent gestiegen. Die Begründung klingt technisch: neue Sicherheitsfeatures, erweiterte Datenresidenz-Optionen, gestiegene API-Limits.
Das allein wäre ärgerlich, aber nicht das eigentliche Problem. Das Problem ist der Satz, der im Kleingedruckten steht: Daten-Exporte über einem bestimmten Volumen werden zusätzlich berechnet, die bisherige Standard-SLA wandert in ein höheres Preistier, und wer vor dem nächsten Verlängerungstermin wechseln möchte, muss sechs Monate im Voraus kündigen.
Die Geschäftsführung ruft den Operations-Lead und den Software-Engineer in ein kurzes Meeting. Die zentrale Frage ist schnell gestellt: Können wir das auch woanders betreiben? Die Antwort fällt schwerer aus als erwartet. Niemand hat eine vollständige Liste der Abhängigkeiten. Die Daten liegen zwar „in der EU", doch der Vertrag erlaubt Unterauftragnehmer außerhalb des DACH-Raums. Das Backup-Verfahren wurde nie getestet. Die Schnittstellen, über die Kundendaten ein- und ausgehen, sind dokumentiert – aber nur als Screenshots im Wiki des externen Dienstleisters.
Dieser Moment ist der Klassiker des gemieteten Silos: Das Unternehmen betreibt ein geschäftskritisches System, ohne es wirklich zu kontrollieren. Laut der jüngsten Eurostat-Erhebung zu Cloud-Computing in Unternehmen nutzen inzwischen 52,74 Prozent aller EU-Unternehmen kostenpflichtige Cloud-Dienste, bei kleinen Unternehmen mit 10 bis 49 Mitarbeitenden sind es 49,3 Prozent. Noch aufschlussreicher ist der Dependenz-Wert: 77,53 Prozent dieser Cloud-Nutzer gelten als „hoch abhängig", weil sie anspruchsvolle Dienste wie Sicherheitssoftware, gehostete Datenbanken oder Anwendungsplattformen einkaufen. Kurz: Wenn der Vertrag sich ändert, ist das Geschäft in einer schwachen Verhandlungsposition.
Die Erhöhung selbst ist nur der Auslöser. Die eigentliche Belastung ist die Erkenntnis, dass die eigene Infrastruktur nicht mehr beweglich ist.
Warum gemietete Plattformen teurer werden, als sie aussehen
Der sichtbare Preis einer Managed Platform ist nur die Spitze. Darunter liegt ein Kostenstapel, der im Alltag kaum sichtbar wird, weil er über viele Monate und verschiedene Stellen wächst.
Der Abo-Preis ist nur die erste Ebene. Darüber kommen oft egress-basierte Datenexportgebühren, die bei wachsendem Kundenvolumen schnell zur Überraschung werden. Hinzu kommen Zwangsupgrades, wenn der Anbieter ältere Pläne abschafft, und teure Integrationsarbeiten, weil die proprietären Schnittstellen nicht zu den neuen Tools passen, die das Unternehmen eigentlich einführen möchte.
Die zweite Ebene ist operativ. Wenn ein System von niemandem im Haus vollständig verstanden wird, verschwinden Entscheidungen in externen Tickets. Jeder Fehler wird zum Vendor-Ticket, jede Anpassung zum Projektangebot. Die scheinbare Bequemlichkeit einer Managed Platform wird zur administrativen Abhängigkeit.
Die dritte Ebene ist strategisch. Wer seine Workloads nicht verlassen kann, verliert Verhandlungsmacht. Seat-Preise steigen, Funktionen wandern in höhere Tiers, und die Bereitschaft, den Anbieter bei schlechtem Service zu wechseln, sinkt, weil der Exit unübersichtlich erscheint. Laut dem CloudComputing-News-Artikel zu Cloud-Kosten und KI-gestütztem Geschäftssystemen wird der globale Cloud-Infrastrukturmarkt 2026 voraussichtlich um weitere 27 Prozent wachsen und die 500-Milliarden-Dollar-Marke überschreiten. Ein wachsender Markt bedeutet nicht automatisch höhere Rechnungen für jedes einzelne KMU, signalisiert aber, dass Preisdruck und Ressourcenknappheit auch bei kleineren Verträgen ankommen können.
Diese Dynamik macht deutlich: Eigentum ist im Cloud-Zeitalter nicht gleich „alles selbst hosten". Eigentum bedeutet operative Kontrolle über die Schichten, die das Geschäft unterscheiden, plus einen gepflegten Ausstiegsschlüssel für den Fall, dass der Vertrag oder der Anbieter nicht mehr passt.
Die drei Warnsignale, dass Eigentum fehlt
Viele Unternehmen bemerken den Eigentumsverlust nicht, solange alles läuft. Er wird erst sichtbar, wenn sich etwas ändert. Drei Signale deuten darauf hin, dass die Kontrolle über die eigene Plattform abnimmt.
1. Preis-Spirale ohne Verhandlungshebel
Die Verlängerung kommt mit einer deutlichen Erhöhung, aber das Unternehmen hat keine realistische Alternative. Der Wechsel scheint teurer als das Bleiben, weil niemand im Haus den vollen Stack versteht. Genau hier zeigt sich, dass die Infrastruktur nicht mehr austauschbar ist. Der Anbieter kann Preise anheben, weil der Exit nicht praktikabel geplant wurde.
2. Datenort, der auf Unteraufträgern ruht
Der Vertrag sagt „EU", doch für einen Kunden aus der Region ist das nicht genug. Die DACH-Datenresidenz wird zwar behauptet, lässt sich aber nicht zuverlässig nachweisen, weil Unterverträge, Content-Delivery-Netzwerke oder Backup-Standorte fehlen. Das ist ein typisches Warnsignal für Unternehmen, die mit sensiblen Kundendaten arbeiten oder regulatorische Anforderungen erfüllen müssen.
3. Wegzug, der teurer ist als Bleiben
Daten-Exporte kosten Geld, das Format ist proprietär, und die Runbooks für eine Wiederherstellung existieren nur beim Anbieter. Der EU Data Act schreibt vor, dass Switching-Charges, einschließlich Daten-Egress-Gebühren, ab dem 12. Januar 2027 ganz entfallen müssen. Das ist eine wichtige Planungsgröße, aber kein automatischer Migrationshelfer. Ohne eine eigene Betriebsdokumentation bleibt der Wechsel riskant, auch wenn die Gebühren sinken.
Wer eines dieser drei Signale erkennt, sollte nicht panisch alles umziehen, sondern die eigene Plattformstrategie auf Eigentum neu ausrichten.
Was KMU wirklich eigenhändig betreiben können
Nicht jede Schicht einer Plattform muss im eigenen Rechenzentrum laufen. Das Ziel ist selektives Eigentum: die Schichten besitzen, die das meiste Geschäftswert und Kontrollbedürfnis tragen, und den Rest bewusst gemanagt lassen.
Schicht 1: Daten und Anwendungslogik
Das ist für die meisten KMU der wichtigste Eigentumsbereich. Hier liegen Kundendaten, Geschäftsregeln und das, was das Unternehmen von Wettbewerbern unterscheidet. Wenn diese Schicht auf einer proprietären Plattform verbleibt, bindet sie nicht nur Kosten, sondern auch Wissen. Eine portable Anwendungsschicht lässt sich in Containern betreiben, versionieren und auf einem anderen Standort wiederherstellen.
Schicht 2: Laufzeit und Plattform
Kubernetes ist inzwischen eine realistische Option für kleinere Teams. Laut der CNCF-Umfrage 2025 setzen 82 Prozent aller Container-Nutzer Kubernetes in Produktion ein, gegenüber noch 66 Prozent im Jahr 2023. Das bedeutet nicht, dass jedes KMU einen Cluster braucht. Es bedeutet, dass die Technologie etabliert, dokumentiert und portabel ist. Wer diese Schicht eigen betreibt, gewinnt Kontrolle über Releases, Ressourcenauslastung und Wiederherstellung. Wer sie ohne Betriebsdisziplin einführt, baut sich ein neues schwarzes Kästchen.
Schicht 3: Netzwerk, Speicher und Identität
Diese Schicht ist oft der letzte Kandidat für Eigentum. Speicher und Netzwerk sind kommoditätsnah, Identity-Provider erfordern hohe Sicherheitsdisziplin. Viele KMU mieten diese Dienste bewusst weiter, bis ein konkreter Residenz- oder Compliance-Grund dafür spricht, sie selbst zu betreiben. Wichtig ist, dass der Vertrag offene Schnittstellen und klare Datenformate vorsieht, damit ein Wechsel möglich bleibt.
Die Reihenfolge ist bewusst: Eigentum fängt dort an, wo der Geschäftswert am höchsten und die Portabilität am leichtesten umzusetzen ist.
Das Plattform-Eigentum-Playbook in fünf Phasen
Wer Eigentum nicht als Big Bang, sondern als iteratives Betriebsmodell angeht, vermeidet die typischen Fallen: unmaintained islands, cluster-as-black-box und nicht getestete Ausstiegspläne. Das Playbook hat fünf Phasen.
Phase 1: Bestand und Abhängigkeiten auditieren
Zuerst wird kartiert, was heute läuft. Das sind nicht nur Workloads, sondern auch Verträge, Datenflüsse, Schnittstellen, Egress-Kosten, Backup-Regeln und Verantwortlichkeiten. Ziel ist eine Rangliste nach Geschäftskritikalität, Abhängigkeit und Portabilität. Ohne diese Karte wird jede spätere Entscheidung raten.
Phase 2: Wählen, was zuerst eigen wird
Der erste Kandidat sollte einen hohen Geschäftswert haben, aber niedrige Abhängigkeiten. Ein internes Kundenportal, ein interner Reportingservice oder eine Batch-Verarbeitung sind oft besser geeignet als das primäre E-Commerce-System. Der Rest bleibt vorerst beim bestehenden Anbieter. Selective ownership bedeutet bewusstes Behalten genauso wie bewusstes Verlagern.
Phase 3: Portabel aufbauen
Die ausgewählte Schicht wird in Containern verpackt, mit Helm oder Kustomize beschrieben und über GitOps verwaltet. Infrastructure as Code sorgt dafür, dass die Umgebung reproduzierbar ist. Offene Schnittstellen und maschinenlesbare Datenformate sind keine netten Extras, sondern die technische Grundlage des Ausstiegsschlüssels. Der EU Data Act fordert genau solche offenen Formate für Cloud-Dienste – eine Regulierung, die Migration erleichtert, aber nicht automatisiert.
Phase 4: Betrieb und Evidenz etablieren
Eine eigene Plattform ohne Betriebsroutine ist riskanter als eine verwaltete. Backups müssen getestet, Patches müssen zyklisch eingespielt, Incidents müssen dokumentiert und regelmäßig besprochen werden. Observability, Runbooks und ein klarer Incident-Response-Prozess sind keine Nice-to-haves, sondern Voraussetzung dafür, dass das Team Vertrauen in die eigene Schicht gewinnt. Laut der CNCF-Umfrage ist „kultureller Wandel im Entwicklungsteam" inzwischen die größte Herausforderung bei Cloud-Native-Adoption. Das zeigt: Die Technologie ist lösbar, die Organisation ist der kritische Faktor.
Phase 5: Exit-Key pflegen
Der Ausstiegsschlüssel ist die dokumentierte Fähigkeit, den Workload an einen anderen Ort zu verlagern. Er enthält Datenformate, API-Dokumentationen, Rollback-Schritte, Kontaktdaten und das Ergebnis der letzten Restore-Tests. Er muss mindestens vierteljährlich geprüft werden, sonst veraltet er schneller als gedacht.
Ein realistischer KMU-Fall
Ein 42-Personen-Industriedienstleister in Süddeutschland betreibt ein internes Kundenportal für Wartungsverträge, Dokumente und Service-Anfragen. Die Zahlen sind illustrativ, das Szenario ist typisch für den Mittelstand.
Ausgangslage: Etwa 180 monatliche Nutzer arbeiten im Portal. Die Anwendungsdaten umfassen 12 bis 15 Terabyte. Sechs produktive Workloads laufen auf einer verwalteten Plattform. Drei regionale Kunden verlangen explizit DACH-Datenresidenz. Pro Monat gibt es zwei bis drei Plattform-Releases und ein bis zwei Vendor-Tickets für nicht reproduzierbare Fehler.
Rollen im Unternehmen:
- Die Geschäftsführung trägt Budget- und Kundenverantwortung.
- Der Operations-Lead betreibt die aktuelle Plattform und bewertet Alternativen.
- Der Software-Engineer wartet die Anwendung und ihre Abhängigkeiten.
- Ein externer Kubernetes-DevOps-Berater begleitet Migration und Plattformdesign part-time.
Entscheidungspunkte:
- Welche Workloads sind kritisch genug, um Eigentum zu rechtfertigen?
- Welche Abhängigkeiten lassen sich gegen offene Standards oder selbst gehostete Komponenten ersetzen?
- Wo ist DACH-Hosting nötig, und wo reicht ein georedundanter EU-Standort?
- Kann das Team Patch-Zyklen, Backups und Incident-Response ohne 24/7-Rufbereitschaft betreiben?
- Welcher Exit-Key muss vor der nächsten Verlängerung dokumentiert und getestet werden?
Review-Gates: Die Geschäftsführung billigt Kritikalität und Datenresidenz vor jedem Umzug. Der Operations-Lead dokumentiert jede Abhängigkeit und jeden Test; kein Workload wechselt ohne Rollback-Plan. Der Software-Engineer prüft die Portabilität der Anwendungsabhängigkeiten. Der externe Berater validiert Kubernetes-Design und Backup-Restore-Tests. Ein monatlicher Review erfasst Kosten, Vorfälle, Restore-Testergebnisse, offene Tickets und den nächsten Kandidaten für Eigentum.
Illustrativer Verlauf: Das Team entscheidet sich, zuerst das Kundenportal auf eine eigene Kubernetes-Schicht mit DACH-Hosting zu migrieren. Der Preis wird planbarer, die Datenresidenz nachweisbar und die Abhängigkeit von einem einzigen Anbieter sinkt. Nach 90 Tagen liegen dokumentierte Restore-Tests, ein Incident-Review-Format und eine Rangliste der nächsten Workloads vor.
Das ist kein Kundenfall, sondern ein Planungsmodell. Es zeigt aber, dass Eigentum nicht eine riesige Investition ist, sondern eine Sequenz aus klaren Entscheidungen und Review-Gates.
Wie Planfold Eigentum in ein Betriebsmodell übersetzt
Planfold unterscheidet drei Arbeitsphasen, die bei Plattform-Eigentum zusammenwirken müssen. Jede Phase hat eine technische Bedeutung – nicht nur eine Marketing-Bezeichnung.
Plan bedeutet Audit nach Kritikalität, Kosten und Abhängigkeit.
Zusammen mit dem Unternehmen erstellen wir eine Karte der bestehenden Workloads, Verträge, Datenflüsse, Kostenfaktoren und Teamfähigkeiten. Daraus entsteht keine allgemeine Empfehlung, sondern eine Rangliste: welche Schicht zuerst, welche später und welche bewusst beim bestehenden Anbieter bleibt. Die Planfold-Sovereignty-Review ist der Einstieg in diese Phase.
Unfold bedeutet, die eigene Schicht tragfähig aufzubauen.
Das umfasst portable Kubernetes-Operationen, Git-gesteuerte Infrastruktur, DACH-Hosting-Optionen dort, wo sie erforderlich sind, und den bewussten Einsatz selbst gehosteter oder Open-Source-Komponenten, wo sie betreibbar sind. n8n-Workflows übernehmen wiederkehrende Betriebsabläufe, von der Ticket-Verarbeitung bis zur Überwachung. Backup- und Restore-Routinen sowie Observability gehören zum Lieferumfang, nicht zur Nachbereitung.
Resonate bedeutet, das System mit Review-Evidenz laufen zu lassen.
Eigentum wird nur dann nachhaltig, wenn es regelmäßig überprüft wird. Das sind Kosten-Reviews, Restore-Tests, Incident-Reviews und die Pflege des Exit-Keys. Diese Evidenz ist gleichzeitig das Vertrauensfundament für das Management und die operative Grundlage für Audits oder Kundenfragen.
Der erste 90-Tage-Plan: Vom gemieteten Silo zur eigenen Schicht
Eigentum entsteht nicht in einer Strategie-Offsite, sondern durch 90 Tage konkrete Arbeit. Der Plan ist bewusst eng gehalten.
Woche 1 bis 2: Bestandsaufnahme und Exit-Kosten
Inventarisieren Sie alle produktiven Workloads, Verträge, Schnittstellen und Datenflüsse. Schätzen Sie Egress-Kosten, Kündigungsfristen und den Aufwand für eine Migration ab. Definieren Sie den ersten Workload, der umziehen soll, und begründen Sie die Wahl nach Geschäftswert, Abhängigkeit und Teamfähigkeit.
Woche 3 bis 6: Pilot-Workload und tragfähige Plattform
Bauen Sie die Zielumgebung für den Piloten. Verpacken Sie die Anwendung in Container, beschreiben Sie sie mit Helm oder Kustomize, und führen Sie GitOps ein. Führen Sie mindestens einen erfolgreichen Restore-Test durch, bevor Daten produktiv umziehen. Halten Sie den alten Betrieb parallel, bis das Team Vertrauen in die neue Schicht hat.
Woche 7 bis 12: Betriebsroutine und Review-Evidenz
Etablieren Sie den Patch-Zyklus, das Monitoring, die Alarmierung und die Runbooks. Führen Sie einen monatlichen Review durch, in dem Kosten, Vorfälle, Restore-Tests und offene Tickets besprochen werden. Dokumentieren Sie den Exit-Key und legen Sie den nächsten Kandidaten für Eigentum fest.
Das Ziel nach 90 Tagen ist nicht vollständige Unabhängigkeit. Das Ziel ist ein bewiesener Betriebsmodus für eine eigene Schicht und eine klare Entscheidungsgrundlage für den nächsten Schritt.
