Wann sind lokale Softwareinstallationen auf eigenen Servern noch sinnvoll?

Eine Unternehmenssoftware kann seit Jahren zuverlässig auf dem eigenen Server laufen und trotzdem zunehmend zum Betriebsrisiko werden. Solange Rechnungen erstellt, Kundendaten verarbeitet und Maschinen angesteuert werden, erscheint ein Wechsel unnötig. Doch die sichtbare Funktionsfähigkeit sagt wenig darüber aus, wie sicher, wartbar und langfristig tragfähig das Gesamtsystem ist.

Lokale Softwareinstallationen bleiben sinnvoll, wenn Unternehmen ihre Infrastruktur kontrollieren müssen, spezielle Hardware oder individuelle Schnittstellen nutzen und die technische Betreuung dauerhaft gewährleisten können. Für Schweizer KMU mit begrenzten IT-Ressourcen kann eine Cloud-Lösung dagegen die verlässlichere Wahl sein. Entscheidend sind nicht allein Lizenzpreise oder Serverstandorte, sondern auch Wiederherstellbarkeit, Sicherheitsupdates, Personalabhängigkeiten und spätere Wechselmöglichkeiten.

Eine fundierte Entscheidung betrachtet deshalb den gesamten Lebenszyklus der Software. Dazu gehören die Kosten der nächsten fünf Jahre ebenso wie mögliche Ausfälle, regulatorische Anforderungen und die Frage, ob sich Daten und Prozesse später ohne unverhältnismässigen Aufwand übertragen lassen.

Warum lokale Softwareinstallationen trotz stabiler Nutzung zunehmend aufwendig werden

Lokale Softwareinstallationen können trotz unveränderter Nutzung immer mehr Aufwand verursachen, weil ihre technische Umgebung altert. Betriebssysteme, Sicherheitszertifikate, Schnittstellen und Hardware müssen weiterhin gepflegt werden. Selbst wenn eine Anwendung funktional zuverlässig arbeitet, können auslaufender Herstellersupport und neue technische Anforderungen ihren sicheren Betrieb erschweren.

Der entscheidende Unterschied liegt zwischen funktionaler Stabilität und operativer Stabilität. Eine Software ist funktional stabil, wenn sie die erwarteten Aufgaben korrekt erledigt. Operativ stabil ist sie erst dann, wenn Updates, Datensicherungen, Wiederherstellungen und notwendige Anpassungen auch künftig zuverlässig möglich bleiben.

Besonders deutlich wird diese Unterscheidung bei externen Schnittstellen. Eine lokal installierte Buchhaltungssoftware kann unverändert funktionieren, während Banken ihre unterstützten Nachrichtenformate weiterentwickeln. Im Schweizer Zahlungsverkehr betreffen solche Änderungen beispielsweise ISO 20022 und die Swiss Payment Standards. Die ISO-20022-Dokumentation von SIX beschreibt unter anderem pain.001 für Zahlungsaufträge sowie camt.052, camt.053 und camt.054 für elektronische Kontoinformationen und Buchungsanzeigen.

Ob eine Anpassung tatsächlich nötig wird, hängt von der verwendeten Softwareversion, der Bankverbindung und den unterstützten Schnittstellen ab. Für den Betrieb bedeutet das: Eine unveränderte Anwendung kann trotzdem technische Wartung benötigen.

Weitere Abhängigkeiten entstehen durch Druckertreiber, Zertifikate, Fernwartungssoftware, Backup-Systeme und Ersatzhardware. Je älter die Installation, desto schwieriger kann es werden, kompatible Komponenten und Personen mit entsprechendem Fachwissen zu finden.

Ein weiteres Problem ist aufgeschobene Wartung. Werden mehrere Aktualisierungszyklen ausgelassen, kann ein späterer Betriebssystemwechsel zusätzliche Anpassungen an Datenbanken, Treibern und Schnittstellen erfordern. Der zuvor eingesparte Aufwand tritt dann möglicherweise gebündelt auf.

Warnsignale sind insbesondere:

• Das Betriebssystem erhält keine regulären Sicherheitsupdates mehr.
• Der Softwarehersteller bietet keinen verlässlichen Support mehr an.
• Die Anwendung funktioniert nur auf bestimmter älterer Hardware.
• Eine einzelne interne Person oder ein einzelner Dienstleister verfügt über das notwendige Betriebswissen.
• Wichtige technische Änderungen lassen sich nicht mehr unabhängig testen.

Eine ältere Anwendung muss deshalb nicht sofort ersetzt werden. Solange Unterstützung, Sicherheit und Wiederherstellbarkeit gewährleistet sind, kann ihr Weiterbetrieb wirtschaftlich sinnvoll bleiben. Entscheidend ist, ob das Unternehmen die dafür notwendigen Voraussetzungen nachweislich erfüllt.

Wie man geschäftskritische Software auf eigenen Servern zuverlässig betreibt

Geschäftskritische Software lässt sich auf eigenen Servern zuverlässig betreiben, wenn Datensicherung, Wiederherstellung, Updates und Zuständigkeiten verbindlich organisiert sind. Entscheidend ist nicht nur die technische Verfügbarkeit im Normalbetrieb, sondern auch die Fähigkeit, nach einem Ausfall innerhalb einer akzeptablen Zeit wieder arbeitsfähig zu werden. Diese Wiederanlaufzeit muss geplant und getestet werden.

Der zentrale Schwachpunkt vieler Betriebskonzepte ist die Verwechslung einer vorhandenen Datensicherung mit einer funktionierenden Wiederherstellung. Ein Backup kann vollständig erscheinen und dennoch unbrauchbar sein, etwa weil Datenbanken nicht konsistent gesichert wurden, Schlüssel fehlen oder die Wiederherstellungsumgebung nicht mehr kompatibel ist.

Das Bundesamt für Cybersicherheit empfiehlt ausdrücklich, das Backup-Konzept sowie den letzten erfolgreichen Wiederherstellungstest zu prüfen. Die Empfehlungen des Bundesamt für Cybersicherheit zur Zusammenarbeit mit IT-Dienstleistern behandeln ausserdem Zugangsschutz, Mehr-Faktor-Authentisierung und die organisatorische Absicherung von IT-Dienstleistungen.

Für Unternehmen ist besonders wichtig, zwischen zwei Kennzahlen zu unterscheiden: Das Recovery Time Objective (RTO) beschreibt die angestrebte maximale Wiederanlaufzeit. Das Recovery Point Objective (RPO) legt fest, wie weit der wiederhergestellte Datenstand höchstens zurückliegen darf. Beide Zielwerte müssen aus den betrieblichen Auswirkungen eines Ausfalls abgeleitet werden.

Ein Betriebskonzept sollte ausserdem eine getrennte Testumgebung vorsehen. Dort lassen sich Sicherheitsupdates, neue Versionen und veränderte Schnittstellen prüfen, bevor sie produktive Abläufe beeinflussen. Dokumentierte Wartungsfenster schaffen Planungssicherheit für die Fachabteilungen.

Die technische Umsetzung ist allerdings nur ein Teil der Aufgabe. Bei einem Ausfall muss eindeutig feststehen, wer Entscheidungen trifft, wer Zugriff auf Sicherungen besitzt, wer den Dienstleister kontaktiert und wer die erfolgreiche Wiederaufnahme des Betriebs bestätigt.

Eigene Infrastruktur bietet nur dann einen praktischen Kontrollvorteil, wenn das Unternehmen sie auch im Störungsfall beherrscht. Diese Voraussetzung ist bei sensiblen Anwendungen besonders wichtig, aber nicht automatisch ein Argument gegen Cloud-Dienste.

Eigener Server oder Cloud: Welche Bereitstellung zu sensiblen Anwendungen passt?

Für sensible Anwendungen eignet sich weder ein eigener Server noch eine Cloud pauschal besser. Ausschlaggebend sind Datenkategorien, gesetzliche Anforderungen, technische Schnittstellen, Zugriffskontrollen und die betrieblichen Fähigkeiten des Unternehmens. Eine Cloud-Lösung kann auch sensible Personendaten verarbeiten, sofern die einschlägigen Datenschutzvorgaben eingehalten und geeignete Sicherheitsmassnahmen umgesetzt werden.

In der Schweiz ist insbesondere das Datenschutzgesetz (DSG) zu berücksichtigen. Bei einer Auftragsbearbeitung bleibt das Unternehmen als Verantwortlicher grundsätzlich für die datenschutzkonforme Bearbeitung zuständig. Die Anforderungen an Auftragsbearbeiter, vertragliche Vereinbarungen und mögliche Bekanntgaben ins Ausland müssen daher vor dem Einsatz einer Cloud geprüft werden.

Die datenschutzrechtlichen Erläuterungen des EDÖB zum Cloud-Computing behandeln diese Verantwortlichkeiten sowie die Bedeutung von Unterauftragsbearbeitern und geeigneten technischen und organisatorischen Massnahmen. Ein Rechenzentrum in der Schweiz allein gewährleistet noch keine vollständige Datenschutzkonformität.

Die passende Bereitstellung lässt sich anhand konkreter Anforderungen beurteilen:

Auch der Begriff Cloud muss differenziert werden. Eine standardisierte SaaS-Anwendung bei einem internationalen Public-Cloud-Anbieter unterscheidet sich erheblich von einer individuell betriebenen virtuellen Maschine in einem Schweizer Rechenzentrum. Beim Schweizer Hosting kann das Unternehmen weiterhin selbst für Betriebssystem, Datenbank und Anwendungsupdates verantwortlich sein.

Die Wahl des Rechenzentrums beantwortet deshalb nicht die Frage nach der Verteilung der Betriebs- und Sicherheitsverantwortung. Ebenso wenig bedeutet die Auslagerung, dass das Unternehmen keine eigenen Schutzmassnahmen mehr benötigt. Benutzerkonten, Endgeräte, Berechtigungen und interne Prozesse bleiben relevant.

Besondere Anforderungen können sich aus Branchenvorschriften, vertraglichen Geheimhaltungspflichten oder technischen Echtzeitbedingungen ergeben. Sie sind anhand der konkreten Anwendung und nicht allein anhand der allgemeinen Bezeichnung «sensible Daten» zu bewerten.

Wer diese Kriterien dokumentiert, kann lokale Infrastruktur und Cloud-Angebote sachlich vergleichen. Fehlt dagegen ein tragfähiges Sicherheits- und Wartungskonzept, schützt auch ein eigener Server nicht vor den Folgen veralteter Systeme.

Welche Risiken entstehen, wenn lokale Unternehmenssoftware zu lange ungepatcht bleibt?

Bleibt lokale Unternehmenssoftware über längere Zeit ungepatcht, können bekannte Sicherheitslücken bestehen bleiben, während technische Abhängigkeiten weiter altern. Dadurch steigen je nach Schwachstelle und Erreichbarkeit die Risiken für unbefugte Zugriffe, Datenverlust und Betriebsunterbrechungen. Spätere Aktualisierungen können zusätzlich aufwendiger werden, wenn unterstützte Zwischenversionen und kompatible Komponenten fehlen.

Besonders problematisch sind Systeme, deren Zustand niemand mehr vollständig überblickt. Neben der eigentlichen Fachanwendung können Betriebssysteme, Datenbanken, Fernwartungsdienste und Bibliotheken Schwachstellen enthalten. Angreifer können bekannte Sicherheitslücken in direkt erreichbaren Diensten ebenso ausnutzen wie unzureichend geschützte administrative Zugänge.

Eine Anwendung muss dafür nicht öffentlich im Internet angeboten werden. Bereits eine kompromittierte Fernwartungsverbindung oder ein unzureichend abgesicherter Zugang innerhalb des Unternehmensnetzwerks kann ein relevantes Risiko darstellen. Entscheidend ist, welche Komponenten erreichbar sind und welche Berechtigungen darüber erlangt werden können.

Systematisches Patch-Management erfasst deshalb nicht nur die Installation von Updates. Der NIST-Leitfaden zum Enterprise Patch Management beschreibt einen Prozess, der die Identifikation, Priorisierung, Beschaffung, Installation und Überprüfung von Patches und Upgrades umfasst. Die Publikation ist eine technische Orientierung und keine eigenständige schweizerische Rechtsvorschrift.

Eine längere Update-Pause kann ausserdem die technische Migration erschweren. Hersteller unterstützen unter Umständen keinen direkten Versionswechsel mehr. Dann müssen zusätzliche Zwischenschritte, Anpassungen von Datenbankstrukturen oder Ersatzlösungen eingeplant werden. Wie gross dieser Aufwand ist, lässt sich nur anhand des konkreten Produkts beurteilen.

Auch vertragliche und rechtliche Folgen verdienen Aufmerksamkeit. Bekannte, nicht behobene Sicherheitslücken können bei der Beurteilung angemessener Schutzmassnahmen relevant werden. Ob sich daraus Haftungsfolgen oder Einschränkungen einer Cyberversicherung ergeben, hängt jedoch vom Einzelfall, den Versicherungsbedingungen und den anwendbaren Pflichten ab. Ein automatischer Verlust des Versicherungsschutzes lässt sich daraus nicht ableiten.

Für eine erste Risikobeurteilung sollten IT-Verantwortliche drei Fragen beantworten:

• Welche Softwareversionen, Betriebssysteme und unterstützenden Komponenten sind tatsächlich installiert?
• Welche bekannten Schwachstellen und ausstehenden Sicherheitsupdates betreffen diese Komponenten?
• Welche externen oder internen Fernzugriffe existieren, und wer verwaltet deren Berechtigungen?

Die Antworten bilden die Grundlage für eine Priorisierung. Besonders kritisch sind bekannte ausnutzbare Schwachstellen auf erreichbaren Systemen, fehlende Sicherheitsupdates und administrative Zugänge ohne ausreichende Absicherung. Nicht jede Aktualisierung muss denselben Zeitplan erhalten; entscheidend ist eine nachvollziehbare Risikobewertung.

Wenn eine Anwendung nicht mehr sicher aktualisiert werden kann, sind zusätzliche Schutzmassnahmen möglicherweise nur eine Übergangslösung. Dann stellt sich die weiterführende Frage, ob der Austausch der Software oder ein anderes Betriebsmodell sinnvoller ist.

Wann sollte eine lokale Unternehmenssoftware ersetzt oder in die Cloud verlagert werden?

Eine lokale Unternehmenssoftware sollte ersetzt oder verlagert werden, wenn Sicherheit, Herstellersupport, technische Kompatibilität oder wirtschaftlicher Betrieb nicht mehr ausreichend gewährleistet sind. Dabei sind zwei Entscheidungen zu trennen: Benötigt das Unternehmen eine andere Software, und soll diese weiterhin lokal oder künftig in der Cloud betrieben werden? Nicht jeder erforderliche Versionswechsel rechtfertigt einen vollständigen Systemwechsel.

Ein häufiger Fehler besteht darin, die bestehende Anwendung ausschliesslich aufgrund ihres Alters zu beurteilen. Auch ältere Software kann weiterhin zweckmässig sein, wenn sie unterstützt wird, sicher betrieben werden kann und aktuelle Geschäftsprozesse zuverlässig abbildet.

Umgekehrt kann eine jüngere Installation bereits unpassend sein, wenn wesentliche Schnittstellen fehlen oder eine Weiterentwicklung durch den Hersteller ausgeschlossen ist. Entscheidende Auslöser für eine Neubewertung sind:

• Auslaufender Support oder fehlende Kompatibilität mit aktuellen Betriebssystemen.
• Notwendige Änderungen bei Zahlungsverkehr, Rechnungsverarbeitung oder anderen externen Schnittstellen.
• Neue Geschäftsprozesse, Standorte oder mobile Arbeitsformen, die sich nicht angemessen unterstützen lassen.
• Eine zunehmende Abhängigkeit von einzelnen Mitarbeitenden oder spezialisierten Dienstleistern.
• Hohe Kosten für die Aufrechterhaltung eines sicheren und wiederherstellbaren Betriebs.

Die Entscheidung «neue Software» betrifft Funktionen, Datenmodelle und Geschäftsprozesse. Die Entscheidung «Cloud oder eigener Server» betrifft dagegen Architektur, Verantwortlichkeiten und Betriebsanforderungen. Werden beide Veränderungen gleichzeitig vorgenommen, können zusätzliche Fehlerquellen entstehen.

Ein bewusst geplantes Migrationsprojekt trennt diese Fragen zumindest in der Analyse. Zunächst wird geprüft, ob ein technisch aktueller Nachfolger der bestehenden Software verfügbar ist. Danach wird beurteilt, welche Betriebsmodelle der Hersteller unterstützt und wie diese die Anforderungen des Unternehmens erfüllen.

Vor jeder Migration sollten Datenqualität und Abhängigkeiten geprüft werden. Doppelte Kundendatensätze, uneinheitliche Artikelnummern, nicht dokumentierte Exportformate und manuelle Sonderprozesse können die Übertragung erschweren. Eine Bereinigung vor dem Wechsel reduziert vermeidbare Komplexität.

Wer erst bei einem vollständigen Ausfall handelt, muss häufig unter Zeitdruck entscheiden. Ein frühzeitig geplanter Wechsel schafft dagegen Raum für Tests, Datenbereinigung und einen Vergleich der verfügbaren Lizenzmodelle.

SaaS oder Kauflizenz: Welches Modell passt bei langfristiger Nutzung besser?

Bei langfristiger Nutzung passt eine Kauflizenz besonders dann, wenn Unternehmen eine unterstützte Softwareversion gezielt kontrollieren und tief in bestehende Prozesse integrieren möchten. SaaS eignet sich eher, wenn laufende Weiterentwicklung, mobiler Zugriff und anbieterseitiger Betrieb wichtig sind. Entscheidend sind jedoch nicht nur Lizenzkosten, sondern auch Änderungsrisiken, Vertragsbedingungen und die Möglichkeit eines späteren Wechsels.

Eine Kauflizenz verschafft je nach Vertrag ein zeitlich unbefristetes Nutzungsrecht für bestimmte Softwareversionen. Daraus folgt jedoch nicht automatisch ein Anspruch auf künftige Updates, Support oder die dauerhafte Kompatibilität mit neuer Hardware. Auch die konkrete Nutzungserlaubnis ergibt sich aus den jeweiligen Lizenzbedingungen.

Bei SaaS erhält das Unternehmen gewöhnlich Zugang zu einer laufend betriebenen Anwendung. Updates, technische Wartung und Teile der Infrastrukturverwaltung liegen beim Anbieter. Der Kunde muss deshalb weniger selbst betreiben, akzeptiert aber auch die Weiterentwicklung des Produkts innerhalb des vereinbarten Dienstmodells.

Veränderungskontrolle ist ein wesentlicher Unterschied. Eine lokal betriebene Kauflizenz kann ermöglichen, eine bestimmte Version über einen längeren Zeitraum beizubehalten. Diese Stabilität wird allerdings mit wachsendem Wartungsbedarf erkauft. Bei SaaS können neue Oberflächen, veränderte Funktionen oder angepasste Prozesse eingeführt werden, ohne dass der einzelne Kunde den Veröffentlichungszeitpunkt vollständig bestimmt.

Der langfristige Vergleich sollte daher mehrere Dimensionen umfassen:

Die langfristig wichtigste Frage ist häufig die nach dem Exit-Aufwand. Können Daten in einem offenen, dokumentierten Format exportiert werden? Lassen sich Anhänge, Historien, Benutzerrechte und Verknüpfungen vollständig übertragen? Wie lange bleibt der Zugriff nach einer Kündigung erhalten?

Diese Fragen gelten für beide Lizenzmodelle. Eine lokal installierte Software kann ebenso stark an proprietäre Datenformate gebunden sein wie ein Cloud-Dienst.

Für Unternehmen mit stabilen, individuellen Abläufen kann eine Kauflizenz attraktiv bleiben. Wer dagegen regelmässige funktionale Anpassungen benötigt und keine eigene Betriebsorganisation aufbauen möchte, kann durch SaaS entlastet werden. Die wirtschaftliche Bewertung erfordert allerdings eine einheitliche Kostenrechnung.

Ein vermeintlich günstiges Lizenzmodell kann teuer werden, wenn Betriebsleistungen fehlen oder ein späterer Export grosse Zusatzprojekte auslöst. Deshalb sollten Kosten und Abhängigkeiten gemeinsam über mehrere Jahre betrachtet werden.

Wie man Server, Lizenzen, Wartung und Betrieb über 5 Jahre kalkuliert

Die Kosten einer Unternehmenssoftware über fünf Jahre lassen sich berechnen, indem einmalige Anschaffungen, wiederkehrende Betriebsausgaben und unregelmässige Erneuerungen vollständig erfasst werden. Bei lokalen Installationen gehören neben Servern und Lizenzen insbesondere Wartung, Backups, Sicherheitsupdates und interne Arbeitszeit dazu. Cloud-Angebote müssen mit vergleichbarem Funktionsumfang, Sicherheitsniveau und derselben betrieblichen Leistung gegenübergestellt werden.

Eine praxisgerechte Gesamtkostenrechnung, auch Total Cost of Ownership (TCO) genannt, beginnt mit drei Kostenblöcken. Sie sollten für jede betrachtete Lösung separat dokumentiert werden.

Eine häufig unterschätzte Position ist die interne Arbeitszeit. Dazu zählen nicht nur geplante Wartungen, sondern auch Benutzeranfragen, Fehleranalysen, Koordination mit Dienstleistern und die Dokumentation technischer Änderungen. Ohne nachvollziehbare Zeiterfassung bleiben diese Aufwände im Kostenvergleich oft unsichtbar.

Für beide Betriebsmodelle kann dieselbe Grundformel verwendet werden:

Gesamtkosten über fünf Jahre = einmalige Kosten + Summe der jährlichen Betriebskosten + geplante Erneuerungen + erwartete Zusatzaufwände.

Alle Positionen sollten in CHF und mit klar ausgewiesenen Annahmen erfasst werden. Nicht zuverlässig prognostizierbare Ereignisse gehören als Szenarien oder separat bezeichnete Reserven in die Rechnung und nicht als scheinbar exakte Zahlen.

Für den Vergleich sind insbesondere drei Szenarien nützlich: normaler Betrieb, höherer Wartungsbedarf und ein grösserer technischer Wechsel innerhalb des Betrachtungszeitraums. Das Unternehmen kann dann erkennen, welche Lösung empfindlicher auf zusätzliche Anforderungen reagiert.

Eine faire Bewertung verlangt ausserdem vergleichbare Leistungsniveaus. Eine lokale Installation ohne getestete Wiederherstellung darf nicht unmittelbar mit einem Cloud-Angebot verglichen werden, das vertraglich bestimmte Verfügbarkeits- und Wiederherstellungsleistungen enthält. Umgekehrt dürfen Leistungen nicht als enthalten angenommen werden, wenn sie im Cloud-Vertrag fehlen.

Die wirtschaftlich günstigste Lösung ergibt sich somit nicht zwingend aus dem niedrigsten Lizenzpreis. Besonders für Schweizer KMU ist entscheidend, ob das Unternehmen die benötigte IT-Kompetenz dauerhaft bereitstellen kann oder Betriebsleistungen besser extern beziehen sollte.

Wann lohnt sich Software as a Service für ein Schweizer Unternehmen?

Software as a Service lohnt sich für Schweizer Unternehmen besonders dann, wenn eigene IT-Ressourcen begrenzt sind und sich betriebliche Anforderungen regelmässig verändern. SaaS kann Infrastrukturverwaltung und Softwarewartung reduzieren, erleichtert häufig den mobilen Zugriff und stellt Aktualisierungen über den Anbieter bereit. Voraussetzung sind geeignete Datenschutzvereinbarungen, nachvollziehbare Sicherheitsleistungen und wirtschaftlich tragfähige Vertragsbedingungen.

Für kleine und mittlere Unternehmen ohne eigenes IT-Team kann die Betriebsentlastung wichtiger sein als der reine Abonnementpreis. Wenn Sicherheitsupdates, Datenbankpflege und die technische Verfügbarkeit nicht intern organisiert werden müssen, sinkt die Abhängigkeit von einzelnen spezialisierten Mitarbeitenden.

Dieser Vorteil ist allerdings vom konkreten SaaS-Angebot abhängig. Auch Cloud-Kunden müssen Benutzerkonten verwalten, Berechtigungen prüfen, Mitarbeitende schulen und ihre eigenen Geräte sowie Zugänge absichern.

Besonders attraktiv ist SaaS bei Anwendungen mit häufig veränderten Anforderungen. Dazu können mobile Zusammenarbeit, neue Schnittstellen, digitale Rechnungsverarbeitung und die Anpassung an veränderte gesetzliche Rahmenbedingungen zählen. Ob solche Anpassungen tatsächlich verfügbar sind und welche Kosten entstehen, muss anhand des jeweiligen Produkts geprüft werden.

Bei tief integrierter Produktionssoftware sieht die Situation anders aus. Maschinenanbindungen, lokale Kassensysteme, Spezialgeräte oder individuelle Steuerungsprozesse können einen lokalen Betrieb weiterhin begünstigen. Eine Cloud-Verlagerung wäre in solchen Fällen nur sinnvoll, wenn die erforderlichen technischen Verbindungen zuverlässig umgesetzt werden können.

In der Schweiz verdient die Datenbearbeitung besondere Aufmerksamkeit. Ein Schweizer Hosting-Standort kann für bestimmte Unternehmen ein wichtiges Auswahlkriterium sein. Es muss jedoch geprüft werden, wo Daten tatsächlich verarbeitet werden, ob Unterauftragnehmer beteiligt sind und welche Länder für Support, Sicherungen oder weitere Verarbeitungsvorgänge relevant sind.

Der EDÖB macht deutlich, dass eine Auslagerung die Verantwortung des Unternehmens für die datenschutzkonforme Bearbeitung nicht beseitigt. Deshalb müssen vertragliche Zusicherungen und tatsächliche technische Verhältnisse zusammenpassen. Je nach Branche und Datenkategorie können zusätzliche Anforderungen hinzukommen.

Vor der Vertragsunterzeichnung sollten insbesondere vier Punkte schriftlich geklärt werden:

• Datenexport: Welche Daten einschliesslich Historien und Anhängen lassen sich in dokumentierten Formaten übertragen?
• Kündigung: Welche Fristen, Mindestlaufzeiten und Bedingungen gelten für die Beendigung des Dienstes?
• Exit-Szenario: Wie werden Daten zurückgegeben oder gelöscht, und wie lange bleibt ein notwendiger Übergangszugriff möglich?
• Preisanpassungen: Wie können Abonnementpreise, Nutzerkosten und Gebühren für zusätzliche Leistungen verändert werden?

Zusätzlich sollten Verfügbarkeit, Supportleistungen, Verantwortlichkeiten bei Sicherheitsvorfällen und die tatsächlich enthaltenen Backup- und Wiederherstellungsleistungen geprüft werden. Eine allgemeine Werbeaussage über hohe Sicherheit ersetzt keine überprüfbare Leistungsbeschreibung.

Als nächster Schritt bietet sich eine Bestandsaufnahme der aktuellen Anwendung an: Betriebsaufwand dokumentieren, kritische Integrationen prüfen, die Fünfjahreskosten vergleichen und für geeignete SaaS-Angebote einen kontrollierten Datenexport testen. Erst wenn diese Ergebnisse vorliegen, lässt sich beurteilen, ob ein Wechsel einen tatsächlichen betrieblichen Vorteil bringt.