Montagmorgen in einem mittelständischen Maschinenbauunternehmen. Das ERP-System antwortet nicht, das Ticketsystem arbeitet nur eingeschränkt, und der IT-Leiter wechselt zwischen Excel-Listen für ein BSI-Audit und einem Anbieter, der auf das vereinbarte Service-Level verweist. Technisch läuft irgendwo eine Cloud-Umgebung. Operativ fühlt sie sich trotzdem wie Eigenbetrieb an.
Genau hier zeigt sich der Unterschied zwischen einem Supportvertrag und einer Managed Service Cloud. Es geht nicht nur darum, ob virtuelle Maschinen erreichbar sind. Es geht um Überwachung, Patches, Sicherheitsvorfälle, Wiederherstellung, Nachweise, Zuständigkeiten und die Frage, wie ein Unternehmen den Anbieter wieder verlassen kann. Der deutsche Markt liefert dafür einen klaren historischen Referenzpunkt: Vertriebspartner erwirtschafteten 2022 mit Managed Services 22,2 Milliarden US-Dollar Umsatz, ein Plus von 15,5 % gegenüber dem Vorjahr. Die Cisco-Daten nennen außerdem 16.843 Partner, die solche Leistungen erbracht haben (Grand View Research zur Entwicklung in Deutschland).
Ein Softwarehaus, das seine Systeme von einem US-Hyperscaler in eine europäische Managed-Umgebung zurückführt, trifft deshalb keine reine Infrastrukturentscheidung. Es entscheidet über Datenpfade, Zugriffsmöglichkeiten, Auditfähigkeit und Vertragsrisiken. Managed Service Cloud ist eine betriebliche und juristische Entscheidung, kein Feature-Katalog.
Inhaltsverzeichnis
- Wenn die Cloud nachts zu brennen beginnt
- Was Managed Service Cloud wirklich bedeutet
- Self Managed versus Hyperscaler versus Managed Cloud
- Architekturbeispiele aus der Praxis
- Compliance als Auswahlkriterium
- SLA, Kosten und wo Managed Cloud teuer wird
- Migration und Betrieb Schritt für Schritt
- Drei Handlungsempfehlungen für Entscheider
Wenn die Cloud nachts zu brennen beginnt
Der IT-Leiter aus dem Maschinenbau hat wahrscheinlich keine neue Technologie bestellt. Er hat eine Entlastung erwartet. Der Anbieter sollte die Plattform überwachen, bei Störungen reagieren, Backups prüfen und den Betrieb so dokumentieren, dass interne und externe Prüfer die Kontrollen nachvollziehen können. Wenn am Ende trotzdem interne Listen, manuelle Eskalationen und ungeklärte Verantwortlichkeiten bleiben, wurde nur Hosting eingekauft.
Der Supportvertrag reicht nicht
Ein klassischer Supportvertrag beantwortet meist die Frage, wann jemand auf ein Ticket reagiert. Eine Managed Service Cloud muss weitergehen. Sie braucht definierte Betriebsprozesse für Monitoring, Incident Response, Patch-Management, Backup, Wiederanlauf und regelmäßige Sicherheitsüberprüfung.
Das ist besonders relevant, weil Unternehmen nicht nur Verfügbarkeit nachweisen müssen. Sie müssen erklären können, wer Zugriff auf produktive Daten hat, welche Subunternehmer beteiligt sind, wo Backups liegen und wie ein Sicherheitsvorfall eskaliert wird. Für betroffene Cloud-Computing-Anbieter und Managed-Service-nahe Unternehmen gelten in Deutschland zudem strengere Anforderungen aus dem NIS2- und BSIG-E-Umfeld. Dazu gehören laut den einschlägigen Fachinformationen unter anderem Registrierungspflichten innerhalb von drei Monaten sowie Angaben zu Hauptniederlassung, EU-Ländern und öffentlichen IP-Bereichen (Fachinformationen zum NIS2-Update 2026).
Praktische Regel: Wenn der Anbieter bei einer Störung nur auf das SLA verweist, aber keine belastbare Eskalationskette und keine technische Ursachenanalyse liefert, betreibt er wahrscheinlich keinen vollständigen Managed Service.
Souveränität beginnt im Vertrag
Das Softwarehaus mit dem europäischen Zielbetrieb hat die richtige Frage nicht erst beim fehlgeschlagenen Audit gestellt. Es hat vor der Migration geklärt, welche Daten die EU verlassen dürfen, welche Fernzugriffe zulässig sind und wie ein späterer Wechsel technisch funktioniert. Seit dem 12. September 2025 gelten die zentralen Switching-Pflichten des Data Act. Ab dem 12. Januar 2027 sind Switching-Gebühren vollständig verboten, bis dahin dürfen nur kostendeckende Gebühren verlangt werden (Einordnung der Switching-Gebühren im Data Act).
Ein belastbarer Vertrag beschreibt deshalb nicht nur Betriebszeiten. Er regelt Datenexporte, Format, Fristen, Verantwortlichkeiten und Unterstützung beim Wechsel. Cloud-Betrieb ohne Exit-Konzept ist keine Souveränität, sondern eine langfristige Abhängigkeit mit monatlicher Rechnung.
Was Managed Service Cloud wirklich bedeutet
Managed Service Cloud wird oft als Sammelbegriff verwendet. Das führt zu Fehlkäufen. Ein Unternehmen kann eine Cloud-Plattform mieten und trotzdem fast alle Betriebsaufgaben selbst tragen. Entscheidend ist nicht, ob der Anbieter „managed“ im Namen führt, sondern welche Zustände er dauerhaft verantwortet.
Von IaaS bis zum vollständigen Betrieb
Bei IaaS mietet der Kunde grundlegende Infrastruktur, etwa virtuelle Maschinen, Speicher und Netzwerke. Der Provider stellt die Plattform bereit, der Kunde bleibt für Betriebssysteme, Anwendungen, Konfigurationen, Patches und viele Sicherheitskontrollen verantwortlich.
PaaS verschiebt einen Teil dieser Arbeit nach aussen. Der Anbieter betreibt beispielsweise Datenbanken, Laufzeitumgebungen oder Middleware. Die Anwendung, ihre Berechtigungen, Datenklassifizierung und fachliche Betriebslogik bleiben jedoch meist beim Kunden.
Bei SaaS steht die fertige Anwendung im Mittelpunkt. Microsoft 365, Salesforce oder ein ERP aus der Cloud liefern einen definierten Funktionsumfang. Der Kunde konfiguriert die Anwendung und steuert Benutzer, Daten und Prozesse, kann die darunterliegende Plattform aber nur begrenzt beeinflussen.
Ein Full Managed Service übernimmt dagegen eine fortlaufende Betriebsverantwortung. Dazu gehören je nach Vertrag:
- Architektur und Plattform: Der Provider plant und pflegt die technische Zielumgebung.
- Security und Identitäten: Er unterstützt bei Zugriffsschutz, Protokollierung und Reaktion auf Sicherheitsereignisse.
- Monitoring und Incident Response: Er erkennt Störungen, bewertet sie und führt definierte Wiederherstellungsschritte aus.
- Backup und Notfallbetrieb: Er prüft Sicherungen und dokumentiert Wiederanlaufverfahren.
- Compliance-Nachweise: Er stellt aktuelle Berichte, Kontrollbeschreibungen und Nachweise für den vereinbarten Scope bereit.
Die Hausverwaltung als brauchbare Analogie
Eine Mietwohnung veranschaulicht IaaS gut. Der Vermieter stellt Räume und grundlegende Versorgung bereit. Für Einrichtung, Organisation und viele Reparaturen bleibt der Mieter zuständig.
Ein bewirtschaftetes Haus funktioniert anders. Die Hausverwaltung koordiniert Wartung, Brandschutz, Winterdienst, Dienstleister und Dokumentation. Sie schuldet nicht nur einzelne Handgriffe, sondern einen vereinbarten Zustand. Genau diese Verschiebung macht Managed Service Cloud interessant.
Für die IT-Abteilung lautet die zentrale Frage deshalb nicht mehr nur: „Läuft der Server?“ Sie lautet: „Wer trägt wofür die Verantwortung, und wie lässt sich das nachweisen?“ Daraus folgt ein Lieferantenrisiko. Der Kunde kauft nicht lediglich Technologie, sondern eine wiederkehrende organisatorische Leistung. Unklare Grenzen zwischen Provider, interner IT und Fachbereich erzeugen im Ernstfall dieselbe Reibung wie ein Eigenbetrieb.
Self Managed versus Hyperscaler versus Managed Cloud
Die drei Modelle unterscheiden sich weniger durch ihre Marketingbegriffe als durch die Verteilung von Verantwortung. Beim Self Managed Betrieb kontrolliert das Unternehmen Architektur, Daten und Prozesse selbst. Dafür muss es auch selbst für Bereitschaft, Patch-Management, Monitoring, Notfalltests und Auditvorbereitung sorgen.
Hyperscaler wie AWS, Microsoft Azure und Google Cloud bieten eine grosse Servicebreite und globale Plattformen. Das schafft technische Optionen, bringt aber komplexe Preislogiken, Datentransferkosten, zahlreiche Einzelservices und anspruchsvolle Verantwortungsgrenzen mit. Ein mittelständisches Team kann diese Plattformen sicher betreiben. Es braucht dafür aber passende Spezialkenntnisse und klare interne Governance.
Managed Service Cloud liegt dazwischen. Der Kunde behält die Kontrolle über Architektur, Datenklassifizierung und Anbieterwahl. Der Provider übernimmt den laufenden Betrieb, die vereinbarten Sicherheitsaufgaben und die Nachweisführung. Das kann auf EU-only-Infrastruktur erfolgen, muss aber ausdrücklich vertraglich und technisch geprüft werden.
Verantwortung und Kontrolle im Vergleich
| Kriterium | Self Managed | Hyperscaler | Managed Service Cloud |
|---|---|---|---|
| Betriebsverantwortung | Vollständig beim eigenen Team | Geteilt nach Provider-Modell | Weitgehend beim Dienstleister, innerhalb klarer Grenzen |
| Architekturkontrolle | Sehr hoch | Hoch, aber an Plattformdienste gebunden | Hoch, abhängig von Provider und eingesetzten Standards |
| Datenhoheit | Intern steuerbar | Muss je Dienst und Region geprüft werden | Vertraglich und technisch definierbar, etwa mit EU-only-Betrieb |
| Sicherheitsbetrieb | Eigenes Monitoring, Patching und Incident Response | Plattformkontrollen plus Eigenverantwortung | Provider übernimmt vereinbarte Kontrollen und Reaktionen |
| Kostenverlauf | Personal- und Investitionskosten dominieren | Verbrauch, Transfer und Zusatzservices können schwanken | Grundgebühr plus variable Workload- und Servicekosten |
| Personalbedarf | Eigene Spezialisten und Bereitschaft nötig | Spezialwissen für Plattform und FinOps erforderlich | Weniger operative Kapazität, aber starke Steuerungskompetenz nötig |
| Exit | Intern organisiert | Technisch möglich, aber oft aufwendig | Muss als vertragliche und technische Leistung vereinbart werden |
Das Personalargument wird häufig zu grob behandelt. Ein Eigenbetrieb kann mit wenigen Personen funktionieren, solange Arbeitszeiten, Bereitschaft und Vertretung realistisch geplant sind. Ein Team mit drei Vollzeitäquivalenten für den Eigenbetrieb kann kurzfristig günstiger wirken als ein Managed-Vertrag, trägt aber das Ausfall- und Wissensrisiko selbst.
Wann die Zwischenlösung nicht passt
Managed Service Cloud ist nicht automatisch wirtschaftlicher. Unternehmen mit wenigen, stabilen Workloads und ohne nennenswerten Auditdruck können für Leistungen bezahlen, die sie kaum benötigen. Auch ein Providervertrag beseitigt keine Architekturfehler. Er verlagert sie nur in einen kostenpflichtigen Betriebsprozess.
Meine Empfehlung ist klar: Entscheider sollten zuerst die tatsächlich benötigte Betriebsleistung beschreiben. Erst danach gehört der Marktvergleich auf den Tisch.
Architekturbeispiele aus der Praxis
Souveränität entsteht nicht durch ein Logo im Angebot, sondern durch konkrete Datenpfade und Zuständigkeiten. Drei Architekturvarianten zeigen, wie unterschiedlich eine Managed Service Cloud umgesetzt werden kann.
Szenario A mit EU-only-Betrieb
Ein deutscher Anbieter betreibt die produktiven Systeme in Rechenzentren innerhalb der EU. Die Umgebung nutzt eine Frankfurt-only-Region, verschlüsselte Backups liegen in einer zweiten EU-Zone. Der Provider verantwortet Plattform, Monitoring, Patching und Nachweise. Der Kunde bleibt für Anwendungscode, Rollenmodell und fachliche Datenfreigaben zuständig.
Die Stärke liegt in der klaren Datenresidenz. Die Schwachstellen liegen oft ausserhalb der Hauptplattform. Remote-Support, Subunternehmer, zentrale Logging-Systeme und externe Backup-Dienste müssen denselben Region-Pinning-Regeln folgen. Ein einzelner API-Aufruf zu einem globalen Dienst kann sonst den gewünschten EU-only-Betrieb unterlaufen.
Szenario B mit Private-Cloud-Anbindung
Ein produzierendes Unternehmen lässt ERP und produktionsnahe Systeme in einer privaten Managed Cloud betreiben. Sichere Leitungen und Cloud-Connect verbinden die Umgebung mit dem bestehenden On-Premises-Netzwerk. Der Provider überwacht Infrastruktur und Datenbanken, die interne IT steuert Werksnetze, Endgeräte und fachliche Freigaben.
Dieses Modell reduziert den Umstellungsdruck. Es eignet sich besonders für Systeme mit engen Abhängigkeiten zu Maschinen, Lagertechnik oder lokalen Identitätsdiensten. Die kritische Stelle ist die Übergabe: Ohne eindeutige Netzwerkverantwortung, getestete Wiederanlaufwege und dokumentierte Abhängigkeiten wird aus der Verbindung ein zusätzlicher Fehlerpfad. Für komplexe Schnittstellen lohnt eine spezialisierte Software-Architektur-Beratung für Münster und NRW.
Szenario C als hybrides Portfolio
In einem hybriden Setup laufen SaaS-Komponenten, IaaS-Workloads und Managed Kubernetes parallel. Ein einheitliches Identity-Management, zentrales Logging und abgestimmtes Patch-Management verbinden die Modelle. Der Provider betreibt Kubernetes und die Plattform, der SaaS-Anbieter verantwortet seine Anwendung, der Kunde bleibt für Daten, Berechtigungen und Geschäftsprozesse zuständig.
Typische Schwachstellen sind geteilte Service-Accounts, fehlende Egress-Kontrolle und unklare Regionseinstellungen einzelner Hyperscaler-APIs. Ein Architekturboard muss deshalb jede Schnittstelle prüfen, nicht nur die primäre Cloud. Auch die Energieeffizienz des Betriebs gehört in die Bewertung. Der Effizienzratgeber für Rechenzentren von Energieaudit365 GmbH liefert dafür einen nützlichen technischen Blick auf Betrieb und Optimierung.
Compliance als Auswahlkriterium
Compliance sollte Anbieter aus dem Auswahlprozess herausfiltern, nicht erst nach der Vertragsunterzeichnung auftauchen. Für Cloud-Dienste ist der BSI-Kriterienkatalog C5 ein zentraler technischer Referenzrahmen. Das BSI beschreibt ihn als Prüfstandard mit Mindestanforderungen für sicheres Cloud Computing. Die aktualisierte Fassung C5:2026 wurde 2026 veröffentlicht (Pressemitteilung des BSI zu C5:2026).
C5:2026 umfasst 17 Anforderungsbereiche mit 114 Basis-Anforderungen. Diese Struktur macht den Katalog für Beschaffung, Vertragsgestaltung und Auditierbarkeit praktisch nutzbar (Einordnung der C5-Anforderungen durch PwC). Entscheidend ist dabei nicht das Vorhandensein eines PDFs, sondern der geprüfte Scope. Deckt das Testat genau die Region, den Service und die Betriebsprozesse ab, die der Kunde einkauft?
Nachweise im direkten Vergleich
| Nachweis | Adressiert | Verbindlichkeit für den Mittelstand | Typische Schwäche |
|---|---|---|---|
| C5:2026 | Cloud-spezifische Informationssicherheit und Kontrollen | Besonders relevant bei regulierten Kunden und anspruchsvoller Lieferantenprüfung | Scope und Aktualität werden oft nicht genau gelesen |
| ISO 27001 | Managementsystem für Informationssicherheit | Sinnvolle Grundlage für Organisation und Prozesse | Ersetzt keinen cloud-spezifischen C5-Nachweis |
| SOC 2 | Kontrollziele und deren Prüfung | Kann international hilfreich sein | Passt nicht automatisch zu deutschen Cloud-Audit-Anforderungen |
| Vertragliche Zusicherung | Zuständigkeiten, Subunternehmer und Leistungen | Für den konkreten Einkauf unverzichtbar | Bleibt wirkungslos, wenn Anlagen und Durchsetzung fehlen |
| Exit-Dokumentation | Datenexport, Übergabe und Wechselunterstützung | Muss vor Vertragsabschluss geprüft werden | Fehlt häufig oder beschränkt sich auf Marketingformulierungen |
NIS2 verschärft die Lieferantensteuerung für betroffene Organisationen. Der Kunde muss die Reaktionsfähigkeit des Providers, die Sicherheit der Lieferkette und die Behandlung von Vorfällen in die eigene Risikobewertung aufnehmen. Eine gute Übersicht dazu, wie Unternehmen Daten schützen, ersetzt keine Prüfung, hilft aber beim Schärfen der internen Datenschutzfragen.
Der Data Act macht Wechselbarkeit zusätzlich operational. Ein Anbieter muss Switching technisch und vertraglich unterstützen. Für den Wechsel gelten in den Fachquellen eine maximale Ankündigungsfrist von zwei Monaten, eine Übergangsphase von höchstens 30 Kalendertagen und danach mindestens 30 Tage Datenabruf (Erläuterungen zu den Switching-Pflichten des Data Act). Wer eine souveräne Cloud für Open-Source-ERP und CRM plant, sollte diese Anforderungen bereits im Zielbild berücksichtigen.
SLA, Kosten und wo Managed Cloud teuer wird
Die Wirtschaftlichkeit steht und fällt mit der Vergleichsbasis. Wer nur die monatliche Providerrechnung betrachtet, vergleicht nicht Managed Service Cloud mit Eigenbetrieb, sondern eine sichtbare Rechnung mit unsichtbarem Aufwand. Zur internen Rechnung gehören Rufbereitschaft, Patchpflege, Schulungen, Dokumentation, Urlaubsvertretung und die Zeit, die bei jeder Störung aus strategischen Projekten abgezogen wird.
Diese Kosten müssen auf den Tisch
Jeder Anbieter sollte mindestens drei Positionen transparent ausweisen:
- Grundgebühr: Welche Plattform- und Betriebsleistungen sind monatlich enthalten?
- Variable Kosten: Wie werden Workloads, Datenvolumen, Nutzer, Speicher, Backups und Zusatzservices berechnet?
- SLA-Folgen: Welche Gutschriften oder Vertragsfolgen entstehen bei einer Verletzung der zugesagten Leistung?
Teuer wird es meist nicht beim Basispaket, sondern an den Rändern. Datenabruf und Wiederherstellung können Egress- oder API-Gebühren auslösen. Eine Mindestabnahme bindet Budget, auch wenn Workloads saisonal weniger genutzt werden. Managed Kubernetes und betreute Datenbanken entwickeln sich schnell zu Sonderprofilen mit eigenen Zuschlägen.
Die vier klassischen Fallen
Erstens, der Datenausgang. Ein Backup ist nur dann ein echter Schutz, wenn es im Notfall bezahlbar und technisch nutzbar wiederhergestellt werden kann.
Zweitens, die Mindestabnahme. Ein Vertrag kann eine fixe Kapazität oder eine feste Serviceklasse verlangen, obwohl der tatsächliche Bedarf schwankt.
Drittens, proprietäre Betriebsbausteine. Nicht standardisierte Snapshots, individuelle Agenten oder fehlende Standard-APIs erschweren den späteren Wechsel.
Viertens, die interne Restarbeit. Wenn der Provider nur Infrastruktur überwacht, aber Anwendung, Datenbank, Security und Compliance beim Kunden bleiben, wird die erwartete Entlastung überschätzt.
Meine wirtschaftliche Faustregel lautet: Managed Cloud lohnt sich besonders dann, wenn das interne Team dauerhaft mehr als fünf Stunden pro Woche mit operativer Stabilität verbringt und dadurch strategische Themen liegen bleiben. Diese Grenze ist keine Marktstatistik, sondern eine praktische Entscheidungsheuristik. Sie muss mit den eigenen Personalkosten, Risiken und Betriebsanforderungen gerechnet werden.
Migration und Betrieb Schritt für Schritt
Eine Migration scheitert selten an der virtuellen Maschine. Sie scheitert an fehlender Bestandsaufnahme, unklarer Datenklassifizierung, nicht getesteten Schnittstellen oder einem Regelbetrieb, für den niemand die Verantwortung übernimmt. Ein mittelständisches Team sollte die Umstellung deshalb als kontrollierten Betriebswechsel planen.
Phase eins mit belastbarer Ist-Aufnahme
Die IT-Leitung erfasst Workloads, Datenarten, Abhängigkeiten, Benutzergruppen, Schnittstellen, Backup-Ziele und bestehende Verträge. Der Datenschutz prüft Verarbeitungen und Auftragsverarbeitungsverträge. Der Fachbereich bewertet Kritikalität und akzeptable Ausfallzeiten.
Am Ende muss für jede Anwendung feststehen, welches RPO und RTO erforderlich sind. RPO beschreibt den maximal akzeptierten Datenverlust, RTO die zulässige Wiederanlaufzeit. Wer diese Werte nicht festlegt, kann weder Backup noch SLA sinnvoll bewerten.
Phase zwei mit Zielbild und Vertrag
Jetzt werden Region, Netzwerk, Identitäten, Logging, Verschlüsselung, Patchfenster, Subunternehmer und Exit-Leistungen definiert. Die IT-Leitung erstellt eine Verantwortungsmatrix. Der Anbieter muss nicht nur Leistungen versprechen, sondern Zuständigkeiten mit Nachweisen und Eskalationswegen verbinden.
Eine belastbare Leistungsbeschreibung enthält mindestens:
- Betriebsumfang: Plattform, Betriebssystem, Datenbank, Middleware, Anwendung und Schnittstellen.
- Sicherheitsumfang: Schwachstellenmanagement, Patch-Zeit, Zugriffskontrolle und Incident Response.
- Serviceumfang: Verfügbarkeit, Ticket-Bearbeitungszeit, Eskalation und Service-Review.
- Exitumfang: Datenformat, Export, Übergangsunterstützung und Löschbestätigung.
Phase drei mit Pilot-Migration
Der Pilot sollte einen repräsentativen, aber beherrschbaren Workload enthalten. Das Team testet Datenübernahme, Performance, Berechtigungen, Monitoring, Backup und Rückfallverfahren. Eine separate Test-Stage ist Pflicht. Ohne sie wird der erste Fehler im Produktivbetrieb entdeckt.
Schulungen gehören vor den Go-Live. Fachanwender müssen wissen, wie sie Störungen melden, welche Änderungen zulässig sind und wann der Provider oder die interne IT zuständig ist. Für Integrationen und SaaS-Übergaben kann eine strukturierte Beratung zu IT-Integrationen, Migrationen und SaaS die Abhängigkeiten sichtbar machen.
Phase vier mit gemessenem Regelbetrieb
Nach dem Go-Live beginnt die eigentliche Bewährungsprobe. Das monatliche Service-Review bewertet Verfügbarkeit, Patch-Zeit, Ticket-Bearbeitungszeit, Backup-Ergebnisse und Kosten pro Workload. Das quartalsweise Architektur-Review prüft Kapazität, Sicherheitslage, Abhängigkeiten und Exit-Fähigkeit.
Eine Eskalationskette benennt operative, technische und geschäftliche Ansprechpartner. Ein Team mit zwei bis vier Personen kann einen solchen Wechsel in einem kompakten Projektfenster von acht bis sechzehn Wochen realistisch vorbereiten, wenn Scope und Entscheidungswege begrenzt bleiben. Die Zahl ist eine Planungsheuristik, keine Zusage für jedes Vorhaben.
Drei Handlungsempfehlungen für Entscheider
Erst die Betriebsstrategie festlegen
Unterschreiben Sie keinen Managed-Vertrag, bevor Workloads, Datenresidenz, Schutzbedarf, RPO, RTO und Verantwortungsgrenzen schriftlich feststehen. Der Anbieter darf nicht durch seine Produktstruktur entscheiden, welche Architektur Ihr Unternehmen bekommt.
Die PwC Cloud Business Survey 2025 zeigt, dass 69 % der deutschen Unternehmen mehrere Cloud-Modelle parallel nutzen (Bericht zur deutschen Cloud- und Managed-Service-Entwicklung). Das spricht gegen eine pauschale „alles in eine Cloud“-Strategie. Planen Sie ein Portfolio, nicht einen einzigen Zielkasten.
Managed Betrieb nach Reifegrad einsetzen
Wenn die interne Operations-Kapazität klein ist oder Audit- und Sicherheitsanforderungen deutlich steigen, ist Managed Service Cloud oft die vernünftigere Wahl. Wenn die Workloads überschaubar sind und das Team den Betrieb sicher beherrscht, kann Self Managed sinnvoller bleiben.
Prüfen Sie dabei nicht nur die Zahl der Mitarbeitenden. Entscheidend sind tatsächliche Bereitschaft, Vertretung, Dokumentationsqualität und die Fähigkeit, Sicherheitsvorfälle nachweisbar zu bearbeiten. Ein kleiner, gut organisierter Betrieb kann besser funktionieren als ein grosser, aber unklar geteilter Service.
Wechselbarkeit vor dem Wechsel verhandeln
Exit-Regeln gehören in die erste Vertragsrunde. Fordern Sie Datenformate, Exportwege, Fristen, Unterstützung, Löschung und Kosten schriftlich an. Testen Sie einen ausgewählten Datenexport, bevor die Migration abgeschlossen ist.
Der deutsche Markt für Cloud Managed Services wurde 2024 auf 7.053,1 Millionen US-Dollar beziffert und soll laut Grand View Research bis 2030 auf 14.331,5 Millionen US-Dollar wachsen. Für den Zeitraum 2025 bis 2030 wird eine jährliche Wachstumsrate von 12,7 % erwartet, während Security Services 2024 29,1 % des Umsatzes ausmachten (Marktprognose für Cloud Managed Services in Deutschland). Das Wachstum macht Anbieter nicht automatisch passend. Es erhöht nur die Zahl der Optionen. Entscheiden Sie nach Betriebsrisiko, Nachweisqualität und Exit-Fähigkeit.
Wenn Sie Ihre bestehende Cloud-Landschaft prüfen oder eine souveräne Managed-Service-Architektur für ERP, SaaS und hybride Workloads planen möchten, lassen Sie zuerst eine unabhängige Bestandsaufnahme erstellen. Fordern Sie eine Workload-Liste, eine Verantwortungsmatrix und eine nachvollziehbare Kosten- und Exit-Bewertung an, bevor Sie Anbieterangebote vergleichen.
