Blog
Cloud & Infrastruktur

Cloud, eigener Server oder Hybrid? Welche IT-Infrastruktur passt zu einem KMU?

Nicht jede Anwendung gehört automatisch in die Cloud – und nicht jeder lokale Server ist veraltet. Wir vergleichen Cloud, On-Premises und Hybrid ohne Ideologie und zeigen, welche Fragen wirklich entscheiden.

10.08.202612 Min. LesezeitCloud & Infrastruktursystel solutions ag

Cloud oder Server ist keine Glaubensfrage

In IT-Diskussionen werden Cloud und lokale Infrastruktur gern als Gegensätze dargestellt. In der Realität nutzen viele Unternehmen längst Mischformen: Microsoft 365 für E-Mail und Zusammenarbeit, lokale Netzwerk- und Speicherkomponenten, Cloud-Backup und vielleicht eine lokal betriebene Fachanwendung.

Microsoft unterscheidet Cloud-Dienste unter anderem in SaaS, PaaS und IaaS und beschreibt zusätzlich Hybrid-Architekturen, die Cloud- und lokale Ressourcen verbinden. Damit ist „Cloud“ kein einzelnes technisches Modell.

Für ein KMU sollte die Entscheidung pro Anwendung und Geschäftsprozess getroffen werden. Nicht jede Workload hat dieselben Anforderungen an Latenz, Verfügbarkeit, Datenstandort, Integration oder Administration.

Eigener Server: Kontrolle und lokale Nähe – aber auch eigene Verantwortung

Bei On-Premises-Infrastruktur betreibt das Unternehmen beziehungsweise sein IT-Partner Server und Dienste auf eigener oder dedizierter lokaler Infrastruktur. Das kann Vorteile bieten, wenn Anwendungen lokale Abhängigkeiten haben, sehr grosse Datenmengen intern verarbeitet werden oder eine besonders direkte Kontrolle über die Umgebung gewünscht ist.

Diese Kontrolle bringt Verantwortung mit sich: Hardware, Virtualisierung, Betriebssystem, Updates, Backup, Stromversorgung, Kühlung, Monitoring und Ersatzplanung müssen organisiert werden.

Ein eigener Server ist deshalb weder automatisch günstiger noch automatisch sicherer. Seine Wirtschaftlichkeit hängt davon ab, wie lange er genutzt wird, welche Ressourcen benötigt werden und wie Betrieb und Ausfallsicherheit organisiert sind.

Cloud: Infrastrukturaufwand verschiebt sich, Verantwortung verschwindet nicht

Bei Cloud-Diensten übernimmt der Anbieter je nach Servicemodell einen grösseren Teil der zugrunde liegenden Infrastruktur. Bei SaaS wie Microsoft 365 nutzt das Unternehmen einen fertigen Dienst; bei IaaS verwaltet der Kunde weiterhin virtuelle Maschinen, Betriebssysteme und Anwendungen.

Microsoft beschreibt dieses Prinzip als Shared Responsibility. Je weiter eine Workload Richtung SaaS verschoben wird, desto mehr Infrastrukturaufgaben übernimmt der Provider. Der Kunde bleibt jedoch insbesondere für Daten, Identitäten, Zugriffe, Endgeräte und Konfiguration mitverantwortlich.

Cloud reduziert also bestimmte Betriebsaufgaben, beseitigt aber nicht die Notwendigkeit von IT-Management und Security.

Hybrid: Oft die pragmatischste Realität für bestehende KMU

Hybrid bedeutet, dass lokale und cloudbasierte Systeme bewusst zusammenarbeiten. Ein typisches Beispiel ist Microsoft 365 für E-Mail und Zusammenarbeit, während eine branchenspezifische Anwendung oder ein grosser lokaler Datenspeicher weiterhin im Unternehmen betrieben wird.

Dieser Ansatz kann Migrationen schrittweise ermöglichen. Nicht jede Anwendung muss gleichzeitig ersetzt werden, und vorhandene Investitionen können weiter genutzt werden.

Hybrid kann allerdings komplexer werden, wenn Identitäten, Netzwerk, Backup und Berechtigungen zwischen mehreren Umgebungen nicht sauber geplant sind. Die Kombination zweier Welten braucht klare Architektur.

Die Cloud macht die Internetverbindung geschäftskritischer

Je mehr zentrale Dienste über das Internet genutzt werden, desto wichtiger wird die Konnektivität. Fällt der Internetzugang aus, können Cloud-Anwendungen trotz vollständig funktionierender Endgeräte nicht erreichbar sein.

Das bedeutet nicht, dass Cloud deshalb ungeeignet ist. Es bedeutet, dass Internetanbindung, Firewall, lokales Netzwerk und bei kritischen Betrieben ein möglicher zweiter Zugang Teil der Architektur werden.

Auch lokale Infrastruktur hat Abhängigkeiten – beispielsweise Stromversorgung, Hardware und Gebäude. Jede Betriebsform verschiebt Risiken, statt sie vollständig zu eliminieren.

Kosten vergleichen: Nicht Kaufpreis gegen Monatslizenz, sondern Gesamtbetrieb gegen Gesamtbetrieb

Ein häufiger Vergleich stellt den einmaligen Serverpreis einer monatlichen Cloud-Lizenz gegenüber. Das ist unvollständig. Beim eigenen Server gehören Hardware, Garantie, Strom, Backup, Wartung, Administration, Monitoring und spätere Erneuerung zur Gesamtrechnung.

Bei Cloud-Diensten entstehen laufende Gebühren, dafür sind bestimmte Infrastruktur- und Plattformaufgaben bereits im Dienst enthalten. Je nach Produkt kommen Zusatzkosten für Backup, Security, Datenübertragung oder erweiterte Funktionen hinzu.

Ein sinnvoller Vergleich betrachtet deshalb Total Cost of Ownership über mehrere Jahre und berücksichtigt auch internen Zeitaufwand und gewünschte Verfügbarkeit.

Sicherheit hängt stärker von Architektur und Betrieb ab als vom Standort des Servers

Weder Cloud noch On-Premises ist per Definition sicher. Ein schlecht konfigurierter Cloud-Tenant kann riskant sein; ein ungepatchter lokaler Server ebenfalls.

Wichtiger sind Identitätsmanagement, MFA, Patch-Prozesse, Netzwerksegmentierung, Endpoint-Schutz, Backup, Logging und klare Verantwortlichkeiten. Im Cloud-Modell muss zusätzlich verstanden werden, welche Sicherheitsaufgaben beim Anbieter und welche beim Kunden liegen.

Das Shared-Responsibility-Modell hilft genau bei dieser Abgrenzung.

Welche Fragen helfen bei der Entscheidung?

Statt mit einer Produktliste zu beginnen, sollten KMU pro Anwendung einige grundlegende Fragen beantworten.

  • Braucht die Anwendung lokale Geräte oder sehr geringe Latenz?
  • Wie kritisch ist der Dienst für den Geschäftsbetrieb?
  • Wie viel Ausfallzeit ist akzeptabel?
  • Welche Datenmengen werden verarbeitet und übertragen?
  • Gibt es regulatorische oder vertragliche Anforderungen?
  • Welche internen IT-Ressourcen stehen für Betrieb und Updates zur Verfügung?
  • Wie schnell ändern sich Benutzerzahl und Leistungsbedarf?
  • Welche Backup- und Disaster-Recovery-Ziele gelten?
  • Welche anderen Systeme müssen integriert werden?

Auch Cloud-Dienste brauchen ein Recovery-Konzept

Der Umzug eines Dienstes in die Cloud beseitigt nicht automatisch jedes Datenverlustszenario. Je nach Dienst stehen Versionierung, Papierkörbe, Retention und Backup-Funktionen zur Verfügung, aber deren Umfang und Aufbewahrungszeiten unterscheiden sich.

Im Shared-Responsibility-Modell bleibt der Kunde für seine Informationen und deren sinnvolle Nutzung beziehungsweise Schutzstrategie mitverantwortlich. Deshalb sollten Recovery-Ziele auch bei SaaS und IaaS dokumentiert werden.

Für Microsoft 365 existiert beispielsweise inzwischen ein eigenes Microsoft-365-Backup-Angebot. Für andere Cloud-Anwendungen muss jeweils geprüft werden, welche nativen Recovery-Möglichkeiten und Exportfunktionen vorhanden sind.

Datenportabilität und Exit-Strategie gehören zur Cloud-Planung

Bei der Einführung eines Cloud-Dienstes sollte nicht nur der Einstieg, sondern auch ein möglicher späterer Wechsel betrachtet werden. Können Daten in einem brauchbaren Format exportiert werden? Wie lange dauert ein Export? Welche Abhängigkeiten bestehen zu Identitäten, APIs oder anderen Diensten?

Das bedeutet nicht, Cloud-Anbieter grundsätzlich zu vermeiden. Es verhindert lediglich, dass wichtige technische und vertragliche Abhängigkeiten erst dann entdeckt werden, wenn ein Produkt ersetzt werden soll.

Dasselbe Prinzip gilt übrigens für lokale proprietäre Systeme. Lock-in ist kein ausschliessliches Cloud-Problem.

Fazit: Die beste Infrastruktur ist meist eine bewusste Mischung

Für viele KMU ist die sinnvollste Architektur weder vollständig lokal noch vollständig cloudbasiert. Sie besteht aus Diensten, die dort betrieben werden, wo technische, wirtschaftliche und organisatorische Anforderungen am besten erfüllt werden.

Cloud, On-Premises und Hybrid sind Werkzeuge. Gute IT-Architektur entscheidet für jede Workload bewusst und dokumentiert gleichzeitig, wer Betrieb, Security, Backup und Wiederherstellung verantwortet.

Quellen & Stand

Fach- und Produktinformationen wurden anhand der unten verlinkten Primärquellen geprüft. Stand: 10. August 2026.

Weiterlesen

Diese Website verwendet Cookies, um grundlegende Funktionen sicherzustellen und das Nutzererlebnis zu verbessern. Weitere Informationen finden Sie in unserer Datenschutzerklärung .