Ein Maschinenbauzulieferer aus dem Sauerland, 180 Mitarbeitende, steht Anfang 2026 vor einer unangenehmen Kombination: Das ERP muss erweitert werden, die IT-Leitung hat offene Anforderungen aus NIS2 auf dem Tisch, und der Geschäftsführer fragt, ob man jetzt endlich „in die Cloud muss“. Im Hintergrund laufen Microsoft 365, ein separates Exchange-Archiv, ein ERP-Add-on in einem Rechenzentrum und mehrere alte Server weiter.
Genau an diesem Punkt scheitern viele Cloud-Projekte. Die Frage lautet nicht mehr, ob Cloud für Unternehmen grundsätzlich sinnvoll ist. Entscheidend ist, welche Workloads in welches Betriebsmodell gehören, wer Risiken und Kosten steuert und wie die Architektur auditierbar bleibt. Dieser Leitfaden ordnet die Entscheidung aus Sicht mittelständischer IT-Verantwortlicher ein.
Inhaltsverzeichnis
- Warum Cloud für Unternehmen jetzt neu entschieden wird
- Die drei Cloud-Modelle Public, Private und Hybrid
- Skalierbarkeit, Kosten und Verfügbarkeit im Mittelstand
- Microsoft Azure und Microsoft 365 im Überblick
- Sicherheit, NIS2 und Datenresidenz 2026
- Wann sich Cloud für ein KMU wirklich lohnt
- Häufige Fehler bei Cloud-Projekten im Mittelstand
- Klarer nächster Schritt für Ihre Cloud-Strategie
Warum Cloud für Unternehmen jetzt neu entschieden wird
Cloud ist im deutschen Mittelstand vom Sonderprojekt zum normalen Bestandteil der IT geworden. Laut Statistischem Bundesamt nutzten im Jahr 2025 54 % der Unternehmen mit mindestens 10 Beschäftigten kostenpflichtige Cloud-Services. Bei kleinen Unternehmen mit 10 bis 49 Beschäftigten waren es 51 %, bei mittleren Unternehmen mit 50 bis 249 Beschäftigten 65 % und bei Grossunternehmen ab 250 Beschäftigten 86 %.
Die Entwicklung verlief schnell. Das DIW Berlin beschreibt für Deutschland einen Anstieg von 11 % im Jahr 2014 auf 32 % im Jahr 2020 und 42 % im Jahr 2021. Destatis meldete für 2020 ausserdem einen Anstieg von 22 % auf 33 % gegenüber 2018. Cloud ist damit kein Experiment mehr, sondern ein etabliertes Werkzeug für Geschäftsanwendungen, Datenhaltung und Zusammenarbeit.
Drei Kräfte verändern die Entscheidung
Erstens steigt der regulatorische Druck. NIS2 zieht die Cloud-Architektur in das Risikomanagement hinein. Unternehmen müssen Zuständigkeiten, Zugriffe, Lieferketten, Wiederanlauf und Sicherheitsmassnahmen nachvollziehbar organisieren. Das betrifft nicht nur die IT-Abteilung, sondern auch Geschäftsführung, Einkauf und Fachbereiche.
Zweitens wird der Betrieb eigener Infrastruktur anspruchsvoller. Hardware muss ersetzt, Energie muss bezahlt und qualifiziertes Personal muss gefunden werden. Das macht die Cloud nicht automatisch günstiger. Es verändert aber die Frage, ob ein Unternehmen Rechenleistung, Betrieb und Ausfallsicherheit selbst wirtschaftlich organisieren kann.
Drittens wächst der Druck durch neue Plattformdienste und KI-Anwendungen. Dienste wie Microsoft Copilot, Azure-Analysen oder externe KI-Plattformen lassen sich nicht einfach mit der bisherigen Serverlogik abbilden. Wer solche Werkzeuge einführt, muss Datenflüsse, Identitäten und Berechtigungen neu bewerten.
Praktische Regel: „Cloud first“ ist keine Architektur. Eine belastbare Workload-Entscheidung ist eine Architektur.
Für den erwähnten Zulieferer bedeutet das: Microsoft 365 kann sinnvoll standardisiert werden, während ERP, CAD-Daten, Produktionsschnittstellen und Backups getrennt bewertet werden. Die Blogbeiträge von fluesta können ergänzend helfen, unterschiedliche Digitalisierungsthemen aus Unternehmenssicht einzuordnen. Entscheidend bleibt jedoch eine eigene Bestandsaufnahme. Wer Server nur verschiebt, übernimmt auch deren Abhängigkeiten, Rechtefehler und Kostenstrukturen.
Die drei Cloud-Modelle Public, Private und Hybrid
Die drei Cloud-Modelle unterscheiden sich nicht primär durch ihre Etiketten, sondern durch Kontrolle, Elastizität und Betriebsverantwortung. Eine Public Cloud wie Microsoft Azure, AWS oder Google Cloud stellt standardisierte Infrastruktur und Plattformdienste bereit. Unternehmen teilen sich die physische Infrastruktur mit anderen Kunden, erhalten aber logisch getrennte Ressourcen.
Das passt zu variablen Workloads, Entwicklungsumgebungen, Webportalen, Analysen und KI-Anwendungen. Rechenleistung lässt sich kurzfristig anpassen, neue Dienste stehen ohne eigenen Hardwarekauf bereit. Der Preis dafür ist ein höherer Bedarf an Governance, Kostenkontrolle und sauberer Konfiguration.
Private Cloud ist mehr als ein eigener Serverraum
Eine Private Cloud stellt Ressourcen dediziert für eine Organisation bereit. Sie kann in einem modernisierten eigenen Rechenzentrum oder bei einem Provider in Deutschland beziehungsweise Europa betrieben werden. Entscheidend sind Automatisierung, standardisierte Bereitstellung, klare Mandantentrennung und ein professionelles Betriebsmodell.
Das Modell eignet sich für Kernsysteme, besonders sensible personenbezogene Daten, steuerlich relevante Bestände oder Anwendungen mit speziellen Konnektoren. Es bietet mehr Kontrolle, verlangt aber auch mehr Planung. Eine Sammlung klassischer virtueller Maschinen mit manuellen Prozessen ist noch keine Private Cloud.
Hybrid Cloud verbindet beide Ansätze. Microsoft 365 und ausgewählte Azure-Dienste laufen extern, während ERP, CAD-Server oder Produktionssysteme lokal oder in einer dedizierten Umgebung bleiben. Dafür braucht es belastbare Netzwerke, etwa VPN oder ExpressRoute, eine gemeinsame Identität mit Entra ID, zentrale Richtlinien und abgestimmte Backup- und Recovery-Prozesse.
| Kriterium | Public Cloud | Private Cloud | Hybrid Cloud |
|---|---|---|---|
| Zweck | Variable und schnell skalierbare Workloads | Kontrollierte, dedizierte Betriebsumgebung | Passende Platzierung unterschiedlicher Workloads |
| Kontrolle | Logische Kontrolle über Ressourcen und Richtlinien | Hohe Kontrolle über Umgebung und Datenpfade | Abhängig von beiden Umgebungen |
| Kostenmodell | Nutzungsabhängig, mit laufender Optimierung | Investition und planbare Betriebskosten | Gemischtes Modell mit höherer Steuerungskomplexität |
| Geeignete Beispiele | Webportale, Entwicklung, KI, Analysen | Kernsysteme, sensible Daten, Spezialanwendungen | Microsoft 365 plus ERP, Produktion oder CAD |
| Hauptrisiko | Fehlkonfiguration, Verbrauchskosten, Anbieterbindung | Betriebsaufwand und begrenzte Elastizität | Komplexität bei Identität, Netzwerk und Backup |
Multi-Cloud ist davon zu unterscheiden. Es bedeutet, mehrere Cloud-Anbieter zu nutzen. Hybrid beschreibt die Verbindung verschiedener Betriebsformen, Multi-Cloud die Verteilung über Anbieter. Eine Multi-Cloud-Strategie für mittelständische Unternehmen kann sinnvoll sein, sollte aber nicht aus ungeplanten Insellösungen entstehen. Sovereign Cloud wiederum beschreibt zusätzliche Anforderungen an Rechtsraum, Betrieb, Zugriff und technische Isolation. Sie ist ein Ausprägungsmerkmal, kein Ersatz für die Begriffe Public oder Private.
Skalierbarkeit, Kosten und Verfügbarkeit im Mittelstand
Skalierbarkeit ist der stärkste sachliche Grund für Cloud. Ein Logistikunternehmen mit saisonalen Spitzen kann zusätzliche Rechenleistung für Analyse, Portale oder Schnittstellen bereitstellen, ohne dauerhaft Hardware für die höchste Last vorzuhalten. Ein Handwerksbetrieb, der nach einer Übernahme neue Benutzer benötigt, kann Konten und Anwendungen zentral bereitstellen, statt erst Serverkapazität zu beschaffen.
Ein Produktionsunternehmen mit gleichmässiger Last sieht die Rechnung anders. Läuft ein ERP stabil, ist die bestehende Infrastruktur gut ausgelastet und sind Ersatzinvestitionen bereits eingeplant, kann ein On-Premises-Betrieb wirtschaftlich bleiben. Public Cloud ist kein Synonym für niedrige Gesamtkosten.
FinOps beginnt vor der Migration
FinOps ist kein monatlicher Blick auf die Rechnung. Es verbindet Architektur, Betrieb und Finanzplanung. Vor der Migration muss klar sein, welche Workloads schwanken, welche konstant laufen und welche ausserhalb der Arbeitszeit tatsächlich heruntergefahren werden können.
Besonders kritisch sind:
- Unklare Verbrauchstreiber: Compute, Storage, Datenbanken und Backups müssen einem Verantwortlichen und einem Geschäftsprozess zugeordnet werden.
- Egress und Schnittstellen: Häufige Datenbewegungen zwischen Cloud und externen Systemen können Kosten und Latenz erhöhen.
- Unpassende Tarifmodelle: Reservierungen, Lizenzen und Benutzerpläne müssen zum tatsächlichen Nutzungsverhalten passen.
- Fehlende Abschaltregeln: Entwicklungs- und Testumgebungen dürfen nicht dauerhaft wie Produktionssysteme laufen.
Für eine belastbare Entscheidung reicht eine Monatsrechnung nicht. Eine TCO-Berechnung für Cloud und On-Premises muss Personal, Wartung, Backup, Strom, Hardware, Lizenzen, Netzwerk, Migration und Ausfallrisiken berücksichtigen.
Verfügbarkeit ist häufig eine Personalfrage. Ein Mittelständler kann nicht ohne Weiteres einen durchgehend besetzten Bereitschaftsbetrieb mit redundanten Standorten finanzieren. Cloud-Anbieter stellen dafür standardisierte Plattformen und Verfügbarkeitsoptionen bereit. Trotzdem bleibt das Unternehmen für die eigene Anwendung, Konfiguration, Datenwiederherstellung und den Zugang verantwortlich. Eine hohe Plattformverfügbarkeit hilft nicht, wenn ein falsch gesetztes Recht den Betrieb blockiert oder kein getestetes Recovery existiert.
Microsoft Azure und Microsoft 365 im Überblick
Viele Unternehmen sagen „Microsoft Cloud“, meinen aber zwei unterschiedliche Produktwelten. Microsoft Azure liefert Infrastruktur und Plattformdienste. Microsoft 365 liefert Produktivität und Zusammenarbeit. Diese Trennung ist für Kosten, Verantwortlichkeiten und Workload-Platzierung entscheidend.
Azure stellt Rechenleistung, Storage, Netzwerke, Datenbanken, Sicherheitsdienste und Plattformfunktionen bereit. Dort laufen beispielsweise virtuelle Maschinen, individuelle Anwendungen, ERP-Schnittstellen, Datenbanken oder eigene Analyseprozesse. Azure kann On-Premises-Systeme ergänzen, ersetzt aber nicht automatisch die gesamte bestehende Umgebung.
Microsoft 365 bündelt dagegen Dienste wie Exchange Online, Teams, SharePoint, OneDrive und Office-Anwendungen. E-Mail, Dokumentenaustausch und Zusammenarbeit gehören typischerweise in diese Welt. Sicherheitsfunktionen können über passende Microsoft-365-Pläne ergänzt werden, müssen aber konfiguriert und betrieben werden.
Die Zuordnung entscheidet über die Komplexität
Ein Unternehmen sollte nicht jede Anwendung einzeln nach Hersteller sortieren, sondern nach Schutzbedarf, Abhängigkeiten und Betriebsanforderungen. Ein ERP-Add-on kann in Azure laufen, während das ERP selbst lokal bleibt. Eine Fertigungsanwendung kann eine lokale Verbindung benötigen, während Reporting-Daten in Azure ausgewertet werden.
| Kriterium | Microsoft Azure | Microsoft 365 |
|---|---|---|
| Kernfunktion | Rechenleistung, Storage, Netzwerk und Plattform | E-Mail, Office und Zusammenarbeit |
| Abrechnung | Nutzungsabhängig, teilweise reservierungsbasiert | In der Regel pro Benutzer und Monat |
| Typische Nutzer | IT, Entwickler und Anwendungsteams | Mitarbeitende und Fachbereiche |
| Geeignete Workloads | Individuelle Anwendungen, Datenbanken, Schnittstellen | Exchange, Teams, SharePoint, OneDrive |
| Wichtige Kontrollen | Ressourcen, Netzwerke, Identitäten und Verbrauch | Benutzer, Geräte, Datenzugriffe und Richtlinien |
Die Lizenzlogik verdient besondere Aufmerksamkeit. Azure-Kosten entstehen durch Ressourcen und Nutzung. Microsoft 365-Kosten entstehen überwiegend durch Benutzerpläne und Zusatzdienste. Nicht jeder Mitarbeiter braucht dieselbe Lizenz, aber eine zu aggressive Vereinfachung kann Sicherheits- oder Funktionslücken erzeugen. Eine sachliche Einordnung der Microsoft-Azure-Kosten für KMU gehört deshalb vor jede Migration.
Übergreifend müssen Identität, Backup und Kostenberichte zusammenpassen. Microsoft 365-Daten sind nicht automatisch vollständig durch die Standardfunktionen geschützt. Azure-Ressourcen brauchen eigene Recovery-Konzepte, getrennte Konten für Produktion und Backup sowie nachvollziehbare Berechtigungen. Wer diese Ebenen getrennt einkauft, aber nicht gemeinsam steuert, baut eine neue Schatten-IT.
Sicherheit, NIS2 und Datenresidenz 2026
Cloud-Sicherheit entsteht nicht durch den Namen des Anbieters. Sie entsteht durch Architektur, Identitäten, Prozesse und überprüfbare Verantwortlichkeiten. Der Provider schützt Rechenzentrum, Hardware und grundlegende Plattform. Das Unternehmen bleibt für Daten, Benutzer, Berechtigungen, Konfigurationen und viele Sicherheitsentscheidungen verantwortlich.
NIS2 verschärft diese Anforderungen für betroffene Sektoren wie Gesundheitswesen, Produktion und digitale Infrastruktur. Der Destatis-Beitrag zur Cloud-Nutzung und zu NIS2-relevanten Anforderungen zeigt, warum die Cloud-Entscheidung nicht bei Office und E-Mail enden darf. Gerade anspruchsvollere Kernanwendungen wie ERP und CRM werden deutlich zurückhaltender in der Cloud eingesetzt. Die offene Frage lautet daher: Welche Workloads brauchen Cloud-Funktionen, und welche Risiken entstehen durch ihre Verlagerung?
Aus Regulierung werden konkrete Architekturregeln
Für ein belastbares Setup gehören mindestens folgende Entscheidungen auf den Tisch:
- Identität absichern: Multi-Faktor-Authentifizierung, Conditional Access und getrennte Administrationskonten müssen Standard sein.
- Netze segmentieren: Produktionssysteme, Büro-IT, Backup und externe Dienste dürfen nicht unkontrolliert miteinander verbunden sein.
- Datenresidenz festlegen: Regionen, Speicherorte, Supportzugriffe und Protokolldaten müssen zum Schutzbedarf und zu vertraglichen Vorgaben passen.
- Lieferanten bewerten: Der Cloud-Anbieter und eingesetzte Managed-Service-Partner gehören in die Lieferketten- und Risikoanalyse.
- Recovery nachweisen: Backups brauchen getrennte Konten, definierte Aufbewahrung und regelmässig getestete Wiederherstellung.
- Logs auswerten: Protokollierung allein genügt nicht. Verantwortliche müssen Alarme, Abweichungen und Eskalationen bearbeiten.
ISO 27001, BSI C5 und DSGVO-Auftragsverarbeitung sind dabei Auswahl- und Prüfunterlagen. Sie ersetzen keine eigene Risikoanalyse. Ein zertifizierter Anbieter kann eine gute Grundlage liefern, aber keine unklare Rollenverteilung zwischen Geschäftsführung, IT und Dienstleister lösen.
Für eine visuelle Einführung in das Thema eignet sich das folgende Video:
Wann sich Cloud für ein KMU wirklich lohnt
Cloud lohnt sich, wenn sie ein konkretes Betriebsproblem löst. Das gilt für schwankende Lasten, verteilte Standorte, schnelle Expansion, fehlende Spezialisten und Anwendungen, die laufend aktualisiert werden. Auch hohe Verfügbarkeitsanforderungen sprechen für Cloud, wenn ein eigenes Rechenzentrum diese Anforderungen personell oder wirtschaftlich nicht abbilden kann.
Cloud ist dagegen keine gute Antwort auf jede alte Serverlandschaft. Ein stabiler Workload mit planbarer Auslastung kann lokal sinnvoller bleiben. Dasselbe gilt, wenn eine Anwendung zwingend an Maschinen, Produktionsnetze oder spezielle lokale Schnittstellen gebunden ist. Eine instabile Internetanbindung ist ebenfalls ein Architekturproblem, das kein Lizenzmodell wegkauft.
Die Entscheidung gehört auf Workload-Ebene
Geschäftsführung und IT sollten jede Anwendung anhand derselben Fragen bewerten:
- Schwankt die Last? Wenn ja, bietet elastische Infrastruktur einen nachvollziehbaren Vorteil.
- Wie kritisch ist der Betrieb? Verfügbarkeit, Wiederanlaufzeit und Abhängigkeit von Netzwerken müssen dokumentiert werden.
- Wie sensibel sind die Daten? Personenbezug, Produktionsgeheimnisse, Gesundheitsdaten und regulatorische Vorgaben beeinflussen die Platzierung.
- Wer betreibt die Anwendung? Fehlen intern Zeit oder Fachkenntnis, kann ein Managed Service sinnvoll sein. Die Verantwortung darf trotzdem nicht verschwimmen.
- Wie sieht die Gesamtrechnung aus? Cloud verschiebt Ausgaben typischerweise in laufende Betriebskosten. Das wirkt sich auf Cashflow, Budgetierung und Bilanzplanung aus.
- Wie leicht ist der Ausstieg? Datenexport, alternative Plattformen, Dokumentation und Wiederanlauf ausserhalb des Anbieters müssen realistisch geprüft werden.
Hybrid Cloud ist dabei nicht nur ein Übergang. Für viele KMU bleibt sie dauerhaft sinnvoll, weil Bürokommunikation, zentrale Plattformdienste, Produktion und Spezialsoftware unterschiedliche Anforderungen haben. Die beste Architektur ist nicht die modernste, sondern diejenige, deren Risiken und Kosten das Unternehmen dauerhaft beherrschen kann.
Häufige Fehler bei Cloud-Projekten im Mittelstand
Die meisten Cloud-Probleme entstehen nicht beim technischen Start, sondern durch fehlende Entscheidungen davor. Unternehmen übertragen alte Serverstrukturen in virtuelle Maschinen, ohne Abhängigkeiten, Berechtigungen oder Betriebsziele zu prüfen. Danach läuft die Infrastruktur zwar in der Cloud, aber sie ist weder einfacher noch transparenter.
Fehler in der Migration
Fehlende Zielarchitektur führt zu nachträglichen Umbauten. Vor dem ersten Umzug braucht es eine Entscheidung über Identität, Netzwerk, Backup, Logging, Datenresidenz und Ausstiegsszenario.
Ungeklärte Abhängigkeiten bremsen ERP, Produktion und Fachverfahren. Ein Anwendungskatalog mit Datenflüssen, Schnittstellen, Eigentümern und Wiederanlaufprioritäten gehört vor die technische Migration.
Lift-and-Shift ohne Prüfung übernimmt alte Schwächen. Nicht jede virtuelle Maschine braucht dieselbe Grösse, dieselbe Betriebszeit oder denselben Speicher. In den ersten 90 Tagen sollte das Unternehmen mindestens die Zielarchitektur bestätigen, Abhängigkeiten dokumentieren und einen begrenzten Pilot abschliessen.
Fehler im Betrieb
Nach der Migration fehlt häufig die klare Antwort auf die Frage, wer handelt. Der Fachbereich besitzt den Prozess, die IT verwaltet Plattform und Zugriffe, der Managed-Service-Partner übernimmt vereinbarte Betriebsaufgaben. Diese Rollen müssen schriftlich feststehen.
Monitoring ist ebenfalls kein Häkchen in einem Projektplan. Alarme brauchen Schwellenwerte, Bereitschaftsregeln und eine Eskalation. Updates dürfen nicht dauerhaft verschoben werden, nur weil niemand den Wartungstermin verantwortet.
Sicherheit verschlechtert sich nicht nur durch Angriffe. Sie verschlechtert sich auch durch unklare Zuständigkeiten und nicht bearbeitete Warnungen.
Fehler bei der Kostenkontrolle
Cloud-Sprawl entsteht durch ungenutzte Ressourcen, fehlende Tags und zu viele Ausnahmen. Gegenmassnahmen sind eine verbindliche Namens- und Tagging-Logik, Kostenstellen pro Workload, regelmässige Rightsizing-Prüfungen und definierte Abschaltzeiten für nicht produktive Systeme.
Auch Microsoft-Lizenzen, Datenschutz und Backup werden oft getrennt betrachtet. Das führt zu doppelten Kosten oder gefährlichen Lücken. Ein monatlicher Betriebsbericht sollte Verbrauch, Sicherheitsereignisse, Backup-Status, offene Risiken und geplante Änderungen gemeinsam ausweisen.
Klarer nächster Schritt für Ihre Cloud-Strategie
Eine belastbare Cloud-Strategie braucht kein mehrjähriges Grossprogramm. Sie braucht eine Reihenfolge, die Geschäftsführung und IT gemeinsam tragen. Beginnen Sie mit dem tatsächlichen Bestand, nicht mit einer Produktpräsentation.
Die richtige Reihenfolge
Erstens, Workloads erfassen. Listen Sie Anwendungen, Daten, Abhängigkeiten, Eigentümer, Schutzbedarf und Wiederanlaufanforderungen auf. Markieren Sie, welche Systeme konstant laufen, welche schwanken und welche an lokale Produktionsprozesse gebunden sind.
Zweitens, Zielarchitektur entwerfen. Entscheiden Sie pro Workload zwischen Public, Private und Hybrid Cloud. Legen Sie Identität, Netzwerksegmentierung, Backup, Logging, Datenresidenz und Exit-Fähigkeit fest. NIS2-Anforderungen gehören in diese Architektur, nicht in eine spätere Dokumentationsrunde.
Drittens, FinOps-Verantwortung benennen. Eine Person oder ein kleines Team muss Kostenentwicklung, Ressourcenverbrauch, Lizenzen und Abweichungen regelmässig prüfen. IT und Finanzbereich sollten dieselbe Sicht auf den Wert und die Kosten eines Workloads erhalten.
Viertens, einen Pilot wählen. Geeignet ist ein abgegrenzter Bereich mit klarer Messung, beispielsweise eine Zusammenarbeitssuite, eine Entwicklungsumgebung oder ein nicht produktionskritischer Datenservice. Der Pilot sollte innerhalb eines überschaubaren Zeitraums belastbare Erkenntnisse zu Sicherheit, Betrieb, Kosten und Nutzerakzeptanz liefern.
Fünftens, erst danach skalieren. Anwendungen mit ungeklärten Abhängigkeiten oder hohem Schutzbedarf bleiben zunächst in der Prüfung. Bei NIS2-Risikoanalysen, komplexen Azure-Lizenzmodellen oder hybriden Backup-Konzepten ist externe Unterstützung sinnvoll, wenn intern die Zeit oder Erfahrung fehlt.
GSL Groß GmbH verbindet für KMU Beratung, Microsoft-365- und Azure-Lösungen, Sicherheitsprüfungen, NIS2-Beratung, Backup, Monitoring sowie Remote- und Vor-Ort-Support. Das kann besonders dann passen, wenn ein Unternehmen nicht nur migrieren, sondern Cloud-Umgebungen dauerhaft mit klaren Zuständigkeiten und planbaren Betriebsprozessen führen will.
Der konkrete nächste Schritt ist ein gemeinsamer Workload-Termin mit Geschäftsführung und IT. Bringen Sie Ihre Anwendungs- und Vertragsliste mit, markieren Sie kritische Systeme und verlangen Sie für jeden Kandidaten eine Entscheidung mit Begründung, Kostenmodell, Sicherheitsanforderungen und Rückfallplan.
Wenn Sie Ihre Cloud-Strategie mit einer belastbaren Workload-Bewertung, NIS2-Anforderungen und einem realistischen FinOps-Modell verbinden möchten, unterstützt GSL Groß GmbH bei Analyse, Architektur, Umsetzung und laufendem Betrieb. Besuchen Sie GSL Groß GmbH, um den nächsten Schritt für Ihre Unternehmens-IT zu planen.