Es gibt diesen Moment in fast jedem IT-Meeting: Jemand nennt ein Problem, alle nicken, kurze Stille und dann geht die Agenda weiter. Das Thema landet auf der Prioritätenliste, irgendwo zwischen Punkt 7 und „das klären wir am besten beim nächsten Meeting.“ Wochen später steht es immer noch da. Unbearbeitet und ignoriert.
Bekannte IT-Risiken werden nicht ignoriert, weil niemand sie ernst nimmt, sondern weil der operative Alltag lauter ist als jede strategische Warnung. Und weil das, was noch nicht explodiert ist, stillschweigend als stabil gilt.
Was das konkret bedeutet, haben wir bereits am Beispiel der Modernisierung von KUNO dargestellt. Eine sehr systemrelevante Plattform des deutschen Einzelhandels, die wir gemeinsam mit dem EHI Retail Institute auf STACKIT überführt haben. (Zum Artikel hier klicken)
Die versteckten Kosten von Legacy-Architekturen.
Wie bereits im Artikel „Legacy-Systeme sind kein IT-Problem“ berichtet, erzeugen alte Systeme Reibung. Sie brauchen mehr Wartung, mehr manuelle Eingriffe, mehr spezialisiertes Know-how, das zunehmend schwer zu finden ist. Jede neue Anforderung, sei es nun Compliance, neue Schnittstellen oder skalierendes Datenvolumen, kostet überproportional viel Aufwand, weil die zugrundeliegende Architektur dafür nie vorgesehen war.
Das KUNO-Projekt belegt genau die Problematik. KUNO lief seit rund 20 Jahren erst auf einer gewachsenen On-Premise-Infrastruktur, dann bereits in Teilen in der Cloud. Die technologische Basis war .NET, die Datenbankabfragen waren eng mit der bestehenden Umgebung verknüpft, und einzelne Komponenten nutzten Windows-spezifische DLLs, die niemand mehr vollständig im Überblick hatte.
Was das in der Praxis bedeutet:
- Sonderlogiken, die historisch gewachsen sind, können bei einer Modernisierung erhebliche Zeit kosten – weil niemand mehr genau weiß, was sie tun und warum
- Enge Plattformabhängigkeiten (z. B. Windows-spezifische Bibliotheken) blockieren einen Wechsel auf moderne, containerbasierte Architekturen
- Datenbanken, die nie für Portabilität ausgelegt wurden, erfordern ein vollständiges Refactoring der Abfrageschicht
Das Tückische: All das erscheint im Budget nicht als „Legacy-Kosten“. Es erscheint als Überstunden, als Verzögerungen, als erhöhter Aufwand im IT-Betrieb. Wer keine explizite IT Modernisierung angeht, zahlt dennoch, nur ohne die Gegenleistung.
Und noch ein Punkt, den wir aus dem KUNO-Projekt direkt mitnehmen: Der Hauptaufwand bei einer Modernisierung liegt in der Anwendung, nicht in der Infrastruktur. Wer das unterschätzt, riskiert die Projektstabilität.
Cloud Transformation, mehr als ein Umzug!
Viele Unternehmen haben in den letzten Jahren begonnen, Workloads in die Cloud zu verlagern. Oft unter Zeitdruck, oft ohne klares Architekturkonzept. Das Ergebnis: „Lift-and-Shift“. Die alten Systeme laufen jetzt in der Cloud, aber das war’s dann auch.
Echte Cloud Transformation bedeutet etwas anderes. Sie fragt: Welche Architektur brauche ich eigentlich für das, was ich vorhabe? Welche Services ergeben Sinn, welche erzeuge ich selbst? Wie viel Flexibilität brauche ich, und wie viel Kontrolle will ich behalten?
Beim KUNO-Projekt haben wir das bewusst in zwei parallele Workstreams getrennt: Das Entwicklungsteam hat sich um die Anwendungsmodernisierung gekümmert, also Migration von .NET auf .NET Core, Refactoring der Datenbankabfragen und Austausch der plattformspezifischen Bibliotheken. Das Cloud Operations Team hat parallel die Infrastruktur auf STACKIT aufgebaut. Beide Spuren liefen gleichzeitig, und nach vielen Wochen Parallelbetrieb, zunächst ohne Produktivdaten, dann mit echten Daten, erfolgte im Februar 2026 der finale Switch.
Dieses Vorgehen hat sich bewährt. Aber es zeigt auch: Wer Cloud Migration und Anwendungsmodernisierung als dasselbe Projekt behandelt, unterschätzt den Aufwand strukturell.
Eine sinnvolle Multi-Cloud Strategie oder ein Hybrid Cloud Ansatz entsteht nicht durch Zufall. Sie ist das Ergebnis eines bewussten Designs. Unternehmen, die das nicht aktiv gestalten, gestalten es trotzdem, nur reaktiv.
Azure Cloud und STACKIT: warum der Kontext entscheidet!
Ja, wir wiederholen uns, aber die Wahrheit kann nicht oft genug genannt werden: Die Wahl zwischen Cloud-Plattformen ist keine Geschmacksfrage, sondern eine Frage von Anforderungen: technisch, regulatorisch und strategisch.
Microsoft Azure Cloud bietet einen reifen Funktionsumfang, tiefe Integration in Microsoft-Ökosysteme und eine globale Infrastruktur. Für viele Unternehmen in der DACH-Region ist Azure die Standardwahl, in vielen Kontexten völlig richtig.
STACKIT ist ein anderes Angebot, bewusst so positioniert. Als Public Cloud der Schwarz Digits (dem IT/Digital-Arm der Schwarz-Gruppe) wird STACKIT ausschließlich aus Rechenzentren in Europa (aktuell Deutschland und Österreich) betrieben, basiert auf OpenStack und setzt konsequent auf Open-Source-Komponenten. Das hat direkte Konsequenzen für die Frage der Datensouveränität: keine Anknüpfungspunkte an den US Cloud Act, politische und rechtliche Klarheit über Datenspeicherort und Zugriffsrechte.
Für das KUNO-Projekt war genau das entscheidend. KUNO verarbeitet sensible Daten mit direktem Bezug zur Strafverfolgung: Kartensperrdaten, die an alle 16 LKA der Bundesländer und an Payment-Service-Provider übermittelt werden. Rechtliche Klarheit war keine Nice-to-have-Anforderung, sondern eine harte Bedingung.
Zur Kostenfrage, und das ehrlich: Aus unseren eigenen Kalkulationen heraus lagen die Kosten auf STACKIT im schlechtesten beobachteten Fall rund 10 bis 15 Prozent über US-Hyperscalern. Häufig sind die Preise aber vergleichbar, abhängig davon, welche Services tatsächlich genutzt werden. Wer ausschließlich auf den Preis schaut, findet möglicherweise günstigere Alternativen. Aber Preis ist nicht der einzige relevante Faktor, und in regulierten Umgebungen oft nicht einmal der wichtigste.
Hinzu kommt ein weiterer struktureller Vorteil von STACKIT: Ingress und Egress sind derzeit kostenfrei, das Pricing-Modell ist transparent kalkulierbar, und proprietäre Lock-in-Mechanismen werden bewusst vermieden. Eine Exit-Strategie ist damit technisch realisierbar, was für kritische Infrastruktur keine Selbstverständlichkeit ist.
Managed Services: was sie wirklich leisten sollten
Managed Services ist ein Begriff, den viele IT-Entscheider kennen, den sie aber trotzdem unterschiedlich verstehen. Für manche bedeutet er: jemand überwacht die Infrastruktur und greift ein, wenn etwas ausfällt. Das ist der Mindestfall.
Was ein seriöser Managed-Services-Partner tatsächlich leistet, geht deutlich weiter:
- Proaktives Monitoring statt reaktiver Fehlerbehebung
- FinOps-Ansätze zur kontinuierlichen Optimierung der Cloud Kosten, weil ungenutztes Compute und falsch dimensionierte Ressourcen in vielen Cloud-Umgebungen einen signifikanten Teil des Budgets binden
- Sicherheitsreviews und Patch-Management als Dauerbetrieb, nicht als Einmalprojekt
- Transparenz über den aktuellen Zustand der Infrastruktur, nicht nur im Problemfall
Ein konkretes Beispiel dafür, wie Managed Services im Betrieb aussieht: Beim KUNO-Projekt hat unser Cloud Operations Team nicht nur die Infrastruktur aufgebaut (Netzwerk, Security Services, Cloud Foundry, Managed Kubernetes), sondern auch stabile CI/CD-Prozesse implementiert, die reproduzierbare Deployments ermöglichen. Der Aufwand, den wir dort hineingesteckt haben, zahlt sich im laufenden Betrieb aus: keine manuellen Eingriffe, kein Rätselraten bei jedem Update.
Das ist auch der Grund, warum „wir haben intern jemanden dafür“ oft nicht ausreicht, nicht weil interne Teams schlecht sind, sondern weil der Betrieb keine Kapazität lässt, um strategisch zu denken.
Die unsichtbaren Risiken: was CTOs oft übersehen
Jetzt kommen wir zu dem unangenehmen Teil, über den selten offen gesprochen wird.
Gewachsener Code, den niemand mehr vollständig versteht:
Systeme, die zwei Jahrzehnte lang zuverlässig laufen, haben einen Preis: technische Schulden, die sich unsichtbar aufschichten. Das KUNO-System lief vor der Modernisierung 20 Jahre lang und hat in dieser Zeit Abhängigkeiten angesammelt, die beim Start der Modernisierung niemand mehr vollständig überblickte. Sonderlogiken, Windows-spezifische DLL-Abhängigkeiten, enge Datenbankintegration. Das sind keine Ausnahmefälle. Das ist der Normalfall bei langlebigen Systemen.
Falsche Kostenvergleiche bei der Cloud-Planung:
Ein häufiger Fehler: Wer eine neue Cloud-Plattform plant, vergleicht bestehende Services 1:1 mit den Äquivalenten auf der neuen Plattform. Das führt zu falschen Kostenschätzungen. Beim KUNO-Projekt haben wir das selbst erlebt und unseren initialen Kostenvergleich korrigieren müssen. Der Wechsel von SQL Server auf MariaDB war nicht nur technisch sinnvoll, sondern deutlich günstiger. Wer diese Analyse nicht macht, zahlt für Dienste, die er nicht braucht.
Fehlkonfigurierte Ressourcen als Sicherheitsrisiko:
Offene Storage-Buckets, zu weit gefasste IAM-Berechtigungen, Dienste ohne Netzwerk-Segmentierung: das sind keine theoretischen Szenarien. Sie entstehen in der Realität, weil Geschwindigkeit vor Sorgfalt kommt und weil es keine systematische Überprüfung gibt. Cloud Migration schafft hier keine Probleme, die vorher nicht da waren, sie macht bestehende Konfigurationsfehler nur schwerer zu finden.
Vendor Lock-in ohne Exit-Strategie:
Wer heute ohne Exit-Strategie in eine Plattform investiert, hat morgen weniger Verhandlungsspielraum bei Preiserhöhungen und mehr Aufwand bei einem Anbieterwechsel. Beim KUNO-Projekt war das kein nachgelagertes Thema, sondern ein konkretes Auswahlkriterium von Anfang an.
Compliance-Lücken, die niemand sucht:
DSGVO-Konformität ist kein Projekt mit Abnahmeprotokoll. Systeme ändern sich, neue Dienste kommen dazu, Datenflüsse verschieben sich. Wer das nicht aktiv im Blick behält, hat irgendwann eine Lücke, die niemand bemerkt hat, bis es zu spät ist.
Cloud Consulting: worauf es wirklich ankommt
Gutes Cloud Consulting beginnt nicht mit einer Produktempfehlung. Es beginnt mit dem Verständnis des Ist-Zustands, technisch, organisatorisch und strategisch.
Was wir aus Projekten wie KUNO mitgenommen haben: Der Einstieg in eine neue Plattform ist beherrschbarer, als viele erwarten, wenn man weiß, welche Fragen man stellen muss. Cloud-Konzepte ähneln sich plattformübergreifend. Wer containerbasiert unterwegs ist, findet sich auf einer neuen Umgebung schnell zurecht. Was Zeit kostet, ist nicht die Infrastruktur, sondern das Verständnis der Anwendung selbst.
Ein seriöser Cloud-Berater bringt deshalb mit:
- Die Fähigkeit, den aktuellen Stack zu analysieren und Schwachstellen zu benennen, bevor er in Lösungen denkt
- Erfahrung mit verschiedenen Szenarien: Cloud Migration, Hybrid Cloud, Legacy-Ablösung, ohne ein Standardprogramm anzubieten
- Die Bereitschaft, auch unbequeme Wahrheiten auszusprechen: dass ein Projekt nicht die richtige Priorität hat, dass eine bestimmte Technologie nicht passt, dass der Zeitplan unrealistisch ist
Der Unterschied zu einem reinen Lizenz-Reseller ist fundamental. Wer nur verkauft, was er verkauft, berät nicht, er platziert. Ein echter Partner arbeitet darauf hin, dass das interne Team versteht, was gebaut wird, nicht darauf, dauerhaft unersetzlich zu sein.
Fazit: ein konkreter nächster Schritt
IT-Entscheidungen werden aufgeschoben, weil der operative Druck keine Luft lässt, weil Risiken, die noch nicht sichtbar sind, wenig Priorität bekommen, und weil „funktioniert ja noch“ als ausreichende Begründung gilt.
Das Problem: Die meisten Risiken, die Unternehmen wirklich teuer zu stehen kommen, waren lange vorher sichtbar, für denjenigen, der genau hingesehen hätte. Das KUNO-Projekt zeigt das exemplarisch: 20 Jahre gewachsener Code, eine enge Plattformabhängigkeit, eine Infrastruktur, die niemand mehr vollständig überblickte. Nicht weil das EHI nachlässig war, sondern weil das der Normalzustand langlebiger Systeme ist.
Warum schreiben wir all das?
Wir analysieren gerne Probleme, wir beraten gerne die, die keine Berater haben wollen und wenn du uns sagst, was du willst, dann sagen wir dir, was du brauchst.
Gerne hier mehr über uns erfahren!
