Vom Migrations-Laufband herunter: Wie KMU die Kosten erzwungener Anbieter-Migrationen stoppen

Die Deprecation-Notice, die ein 60-Personen-KMU ohne Vorwarnung trifft

Es ist ein gewöhnlicher Dienstagnachmittag, als die E-Mail eintrifft. Herr Weber, Geschäftsführer eines 60-köpfigen Maschinenbau-KMU, liest sie zuerst. Der Anbieter der ERP- und CRM-Plattform, auf der das Unternehmen Produktion, Kundendaten und Analytics betreibt, kündigt die Ablösung der aktuellen Architektur an. In neun Monaten läuft die Unterstützung aus. Wer weiter Sicherheits-Updates und Support erhalten will, muss auf die neue Plattform wechseln. Für den Wechsel gibt es keinen Budgetposten, keine Projektkapazität und keine personelle Reserve.

Frau Lang, IT-Leiterin, schätzt die Lage nüchtern ein: Etwa 1,2 Terabyte Produktions- und Kundendaten liegen in Formaten vor, die die neue Plattform nicht eins zu eins übernimmt. Vierzehn Drittsystem-Schnittstellen sind an die alte Architektur gebunden. Herr Demir, der Controller, rechnet vor, dass eine Notfallmigration das Jahresbudget für ungeplante IT-Ausgaben übersteigt. Frau Vogt, Anwendungsentwicklerin, weiß, dass jeder Schnittstellen-Neubau Wochen bedeutet – und dass niemand die alten Verträge so verfasst hat, dass die Betriebskontinuität gegenüber Kunden nachweisbar bleibt.

Diese Szene ist keine Katastrophe an einem einzigen Tag. Sie ist der Moment, in dem ein wiederkehrendes Muster sichtbar wird: Das Unternehmen steht nicht zum ersten Mal vor einer erzwungenen Migration, und ohne andere Entscheidungen wird es auch nicht zum letzten Mal dastehen. Die Frage ist nicht, ob ein Anbieter irgendwann den Rhythmus bestimmt – sondern wie Ihr Stack reagiert, wenn es passiert.

---

Was das Migrations-Laufband wirklich ist

Das Migrations-Laufband ist der wiederkehrende, anbietergetriebene Zyklus aus Deprecation, End-of-Life (EOL), Lizenzwechsel, Übernahme-Abschaltung und erzwungenem Upgrade. Es ist etwas anderes als ein freiwilliger, geplanter Ausstieg, bei dem Sie selbst Zeitpunkt und Ziel wählen. Beim Laufband bestimmt der Anbieter das Tempo. Sie zahlen die Rework-Kosten – Datenkonvertierung, Umschulung, Schnittstellen-Neubau, Stillstand – und jede erzwungene Migration hinterlässt eine neue Abhängigkeit, die den nächsten Zyklus auslöst.

Drei belegte Ereignisse in knapp zwölf Monaten zeigen, dass dieses Muster kein Ausrutscher ist, sondern geschäftsmotorisch vorhersehbar:

• CentOS Linux 7 erreichte am 30. Juni 2024 das End of Life. Red Hat definiert EOL unmissverständlich: Das Produkt wird eingestellt, und Anwender müssen auf eine neue Lösung migrieren, um weiterhin Updates und Sicherheits-Patches zu erhalten. Wer EOL-Software weiter betreibt, setzt ungeschützte Schwachstellen aus. Ein kostenloses, weit verbreitetes Betriebssystem hat so innerhalb eines festen Zeitfensters eine Migration erzwungen – der Beleg, dass Lock-in nicht vom Kaufpreis kommt, sondern von der operativen Abhängigkeit.
• HashiCorp stellte am 10. August 2023 auf die Business Source License um. Produkte wie Terraform, Vault und Consul wechselten von einer freien Open-Source-Lizenz zur BSL, einer source-available Lizenz mit Einschränkungen für Wettbewerber. Das warf die Frage auf: BSL akzeptieren, wechseln oder aussteigen? Die Antwort der Community war der Fork OpenTofu unter der Linux Foundation – der Beweis, dass die Branche gezwungen war zu ziehen.
• Redis wechselte am 20. März 2024 zu dualer source-available-Lizenzierung. Ab Version 7.4 galt RSALv2/SSPLv1 statt der bisherigen BSD-Lizenz; Redis stellte selbst klar, dass Redis unter der OSI-Definition nicht mehr Open Source ist. Auch hier entstand mit Valkey ein Linux-Foundation-Fork, getragen von AWS, Google und Oracle.

Zwei dieser drei Ereignisse haben ganze Communitys zur Abspaltung gezwungen. Das ist keine hypothetische Gefahr. Es ist ein wiederkehrendes, belegtes Muster.

Wer diese Ereignisse nur einzeln betrachtet, plant für die letzte Migration. Wer das Muster erkennt, fragt anders: Was macht meinen Stack so, dass eine erzwungene Migration ein Redeploy wird statt eines Notfallprojekts?

---

Warum erzwungene Migrationen KMU überproportional treffen

Große Unternehmen betreiben Migrations- und Portabilitäts-Teams. Ein mittelständisches Unternehmen mit 10 bis 100 Beschäftigten hat diese Reserve nicht. Wenn der Anbieter den Takt vorgibt, absorbiert die IT-Abteilung das volle Rework – meist parallel zum Tagesgeschäft.

Die Kosten verteilen sich auf vier Posten, die selten einzeln ausgewiesen werden:

• Die Datenkonvertierungs-Steuer: Bei jeder Migration müssen Daten aus proprietären Formaten exportiert, umgeformt und neu importiert werden. Proprietäre Formate sind das eigentliche Lock-in – nicht der Lizenzpreis.
• Schnittstellen-Neubau: Jede Drittsystem-Anbindung, die an eine spezifische API oder Architektur gebunden war, muss neu entstehen.
• Stillstand und Umschulung: Während der Migration stockt der Betrieb; Mitarbeitende müssen auf neue Oberflächen und Prozesse eingestellt werden.
• Neue Abhängigkeit: Jede erzwungene Migration installiert das nächste Lock-in, das den folgenden Zyklus vorbereitet.

Um das greifbar zu machen, betrachten wir das illustrative Szenario des 60-Personen-KMU aus der Eröffnung. Ohne portable Architektur wird die neunmonatige Deprecation-Notice zu einem Notfallprojekt mit geschätzten Kosten von 90.000 bis 150.000 Euro für Datenkonvertierung, Schnittstellen-Neubau, Stillstand und Umschulung – plus unvorhersehbares Timeline-Risiko. Diese Zahlen sind ein exemplarisches Planungsmodell zur Veranschaulichung, keine harte Gewährleistung. Die Annahmen (Personaltage, Schnittstellenanzahl, Datenmenge) sind im Szenario offengelegt, damit Sie sie an Ihre eigene Lage anpassen können.

Die entscheidende Pointe: Diese Kosten sind nicht das Problem eines einzigen Anbieters. Sie sind die Konsequenz einer Architektur, die Portabilität nie als Eigenschaft eingebaut hat. Wer nur auf den Fork ausweicht – OpenTofu statt Terraform, Valkey statt Redis – behandelt das Symptom. Der Fork existiert gerade, weil der ursprüngliche Anbieter einen Wechsel erzwungen hat. Eine Fork-Entscheidung ist selbst eine Migration mit eigenen Kompromittäten in Kompatibilität, Support und langfristiger Governance.

---

Vier Warnsignale, dass Ihr Unternehmen auf dem Laufband läuft

Die meisten KMU spüren das Laufband lange, bevor sie es benennen. Vier Signale verraten, dass Sie nicht für eine einzelne Migration, sondern für einen Zyklus bezahlen:

1. „Unsere Daten stecken im Datenmodell des Anbieters“

Wenn ein Export nur über händische Umformung oder teure Berater funktioniert, ist das Datenmodell das Lock-in. Solange die Daten nicht in einem Format vorliegen, das Sie selbst kontrollieren, zahlen Sie bei jedem Wechsel erneut die Konvertierungs-Steuer.

2. „Der Architektur-Rhythmus kommt vom Anbieter“

Wenn Sicherheits-Patches oder Compliance-Relevanz an kostenpflichtige Hauptversionen gekoppelt sind, haben Sie keine echte Upgrade-Entscheidung. Sie haben eine erzwungene Entscheidung, die wie eine geplante Investition aussieht. Es gibt einen Unterschied zwischen geplanten Upgrades (budgetiert, terminiert, umkehrbar) und erzwungenen Migrationen (anbietergetrieben, fristgebunden, hinterlassen neues Lock-in).

3. „Wir haben unseren Ausstieg nie geübt“

Der Urlaubs-Test für Infrastruktur: Könnten Sie Ihre Workloads heute auf eine andere Umgebung redeployen, ohne die Anwendung neu zu schreiben? Wenn die Antwort „nein“ ist oder niemand sie beantworten kann, existiert der Ausstieg nur als Annahme – nicht als Fähigkeit.

4. „Niemand kennt alle Abhängigkeiten“

Wenn niemand auf einem Whiteboard skizzieren kann, welche Workloads an welche APIs, Formate und Laufzeitumgebungen gebunden sind, ist ein erzwungener Wechsel ein Blindflug. Unsichtbare Abhängigkeiten werden erst dann entdeckt, wenn sie brechen.

Wenn zwei oder mehr dieser Signale auf Sie zutreffen, haben Sie kein Werkzeugproblem. Sie haben ein Architektur-Problem: Ihr Stack ist so gebaut, dass der Anbieter bestimmt, was ein Wechsel kostet.

---

Wie souveräne Infrastruktur den Migrationsschock absorbiert

Die technische Antwort auf das Laufband ist kein einzelnes Werkzeug, sondern ein Substrat, das Portabilität als Eigenschaft eingebaut hat: Kubernetes, Infrastructure as Code (IaC), eigene Datenformate und DACH-seitige Datenresidenz. Das Ziel ist nicht, Migration kostenlos oder sofort zu machen. Das Ziel ist, eine erzwungene Migration aus einem unvorhersehbaren Projekt in ein wiederholbares Redeploy mit vorhersehbarem Aufwand, Review-Gates und Audit-Trail zu verwandeln.

Die vier Bausteine und warum sie einzeln zählen:

• Kubernetes-Portabilität: Workloads, die als Container mit deklarativen Manifesten laufen, sind nicht an ein spezifisches Rechenzentrum oder einen spezifischen Anbieter gebunden. Ein Redeploy bedeutet, dasselbe Manifest auf einer anderen Umgebung auszurollen – nicht, die Anwendung neu zu schreiben.
• Infrastructure as Code: Was als Code beschrieben ist, ist reproduzierbar. Server, Netzwerke und Konfigurationen lassen sich aus einem Git-Repository neu aufbauen statt aus dem Gedächtnis eines Administrators. IaC macht die Infrastruktur selbst versionierbar und austauschbar.
• Eigene Datenformate: Wer die Export- und Schemakontrolle besitzt, enteignet das Datenmodell vom Anbieter. Die Datenkonvertierungs-Steuer fällt nicht bei jedem Wechsel erneut an, weil die Daten in einem Format leben, das das Unternehmen versteht und steuert.
• DACH-Datenresidenz: Hosting in der DACH-Region mit dokumentierter Eigentümerschaft macht die Datenflüsse für Kundenverträge nachweisbar und reduziert regulatorische Friktion beim Wechsel.

Cloud-Native ist dafür keine Experimentierwiese mehr. Der Jahresbericht der Cloud Native Computing Foundation für 2024 verzeichnet hunderte gehostete Projekte und eine breite, reife Contributor-Basis, und die CNCF-Jahresumfrage zeigt, dass ein erheblicher Anteil der Befragten cloud-native Techniken für nahezu die gesamte Entwicklung und Bereitstellung einsetzt. Das ist die Grundlage, auf der ein portables Redeploy für ein KMU praktisch realistisch ist – nicht die Behauptung, Kubernetes sei nur etwas für Großunternehmen.

Diese Architektur schließt den ersten Einwand gleich mit ein: „Ist der Umstieg auf Kubernetes nicht selbst eine große Migration?“ Ja – aber es ist eine einmalige Investition in ein portables Modell, nicht ein wiederkehrendes erzwungenes Projekt. Der Punkt ist, ein einziges Mal auf ein portables Substrat zu migrieren, statt für immer zu migrieren. Danach wird jede weitere erzwungene Migration zum reproduzierbaren Redeploy.

---

Exit-Readiness als dauerhafter Zustand, nicht als Einmalprojekt

Viele KMU behandeln den Ausstieg wie ein Projekt, das man im Ernstfall startet. Das ist genau die Annahme, die das Laufband am Laufen hält. Exit-Readiness ist nur dann eine echte Fähigkeit, wenn sie zu einer messbaren, wiederkehrenden operativen Eigenschaft wird – nicht zu einer Hoffnung im Notfallplan.

Drei Praktiken machen den Unterschied zwischen „wir könnten theoretisch aussteigen“ und „wir haben den Ausstieg in diesem Quartal bewiesen“:

• Redeploy-Drill: Mindestens einmal im Jahr wird ein Workload tatsächlich auf einer alternativen Umgebung neu ausgerollt. Wer den Drill nie macht, entdeckt die Lücken erst unter Druck.
• Datenformat-Eigentum: Es gibt ein dokumentiertes Schema und einen geprobten Export, der ohne den Anbieter funktioniert.
• Review-Gates und Audit-Trail: Jeder Redeploy läuft über definierte Freigaben und wird protokolliert. Damit wird Portabilität prüfbar – für interne Governance und für Kundenverträge, die Betriebskontinuität verlangen.

Für das 60-Personen-KMU aus der Eröffnung bedeutet das: Statt der neunmonatigen Notfallmigration prüft Frau Lang vierteljährlich einen Portabilitäts-Score – welche Workloads sind heute redeploy-fähig? Herr Demir hat einen dokumentierten Export-Pfad für die Kerndaten. Herr Weber genehmigt den jährlichen Redeploy-Drill als Budgetpunkt, nicht als Reaktion auf eine Deprecation-Notice. Frau Vogt hält die Schnittstellen als Code vor, nicht als Insellösung. Eine erzwungene Migration wird damit zu einem Aufwand mit bekanntem Risikoprofil – und hinterlässt keine neue Lock-in-Schicht, die den nächsten Zyklus triggert.

---

Der Planfold-Blick: Souveränität statt immer neuer Migration

Planfold rahmt das Migrations-Laufband als wiederkehrenden operativen Risiko- und Kapitalabfluss – und Souveränität als den Kostenkontroll-Mechanismus, der eine katastrophale erzwungene Migration in ein routinemäßiges Redeploy verwandelt. Unsere Methodik folgt drei technisch definierten Phasen:

Plan bedeutet, die technische Schuld und Architektur zu auditieren. Wir kartieren, welche Daten in proprietären Formaten liegen, welche Workloads bereits portabel sind und welche Abhängigkeiten beim Wechsel brechen würden. Das Ergebnis ist keine theoretische Landschaft, sondern eine priorisierte Liste konkreter Expositionen.

Unfold bedeutet, Systeme zu bauen und Infrastruktur auszuliefern: ein vendor-neutrales Kubernetes- und IaC-Substrat, eigene Datenformate, DACH-seitige Hosting-Standards. Die Umsetzung folgt anerkannten Standards; unsere Kubernetes-Teams sind CKA- und CKAD-zertifiziert, ergänzt durch LFCS. Das ist ein Planfold-Dienst, kein Headcount, den Sie einstellen müssen.

Resonate bedeutet stabiler Betrieb mit Observability, wiederkehrenden Redeploy-Drills und messbarer Exit-Readiness. Ein System, das läuft, ist nicht fertig – es braucht einen Besitzer, der seine Portabilität kontinuierlich sichert.

Die ehrliche Grenze: Souveräne Infrastruktur eliminiert nicht jede Abhängigkeit – sie reduziert sie systematisch. Lock-in wird gemindert, nicht weggezaubert, und eine Fork-Entscheidung bleibt eine eigene Migrationsentscheidung. Aber wenn der nächste Anbieter den Rhythmus bestimmt, ist Ihre Antwort ein getestetes Redeploy – kein Notfallprojekt ohne Budget.