Wer einen SaaS-Anbieter wechseln möchte, sollte vor der Kündigung einen nutzbaren Datenexport nachweisen. SaaS bedeutet, Software als Onlinedienst zu nutzen. Ein erfolgreicher Download reicht für den Ausstieg nicht: Die benötigten Geschäftsvorgänge müssen mit ihren Beziehungen, Anhängen und relevanten Informationen im vorgesehenen Ziel weiterverwendbar sein. Genau das lässt sich mit einer begrenzten Exportprobe prüfen.
Für Geschäftsführung, IT und Einkauf im Mittelstand ist diese Prüfung auch vor einer Vertragsverlängerung sinnvoll. Sie zeigt, welche Abhängigkeiten bestehen und welche Arbeiten ein späterer Wechsel benötigt. Der folgende Leitfaden hilft, Exportzusagen in überprüfbare Anforderungen zu übersetzen, ohne bereits ein vollständiges Migrationsprojekt zu planen.
Was sich durch den Data Act ab 2027 ändert
Ein konkreter Anlass ist der 12. Januar 2027: Ab diesem Datum dürfen Anbieter von Datenverarbeitungsdiensten für den Anbieterwechsel keine Wechselentgelte mehr erheben. Das regelt Artikel 29 Absatz 1 der EU-Datenverordnung, des Data Act. Die Europäische Kommission erläutert die Wechselregeln ausdrücklich auch für Cloud-Dienste und beschreibt Anforderungen an Schnittstellen und maschinenlesbare Exporte bei Software as a Service.
Daraus folgt keine kostenlose Gesamtmigration. Wechselentgelte sind nach Artikel 2 Nummer 36 von Standarddienstentgelten und Sanktionen bei vorzeitiger Kündigung zu unterscheiden. Auch eigene Projektarbeit und die Einrichtung des Zielsystems verschwinden nicht. Artikel 31 sieht zudem Ausnahmen für bestimmte individuell zugeschnittene Dienste und befristete Testangebote vor. Ob und welche Regeln auf Ihren Dienst und Vertrag anwendbar sind, sollte bei Bedarf rechtlich geprüft werden. Dieser Beitrag behandelt die technische Vorbereitung, keine rechtliche Einzelfallberatung.
Zuerst festlegen, was weiterarbeiten muss
Beginnen Sie nicht mit „alle Daten exportieren“, sondern mit einem Geschäftsvorgang. Bei einer Projektanwendung kann das ein laufendes Projekt mit Aufgaben, Kommentaren, Dokumenten und verantwortlichen Personen sein. Bei einer Serviceanwendung wären es offene Fälle einschließlich Bearbeitungsverlauf und Anlagen. Entscheidend ist, welche Informationen für die weitere Arbeit und gegebenenfalls für Nachweise benötigt werden.
Trennen Sie drei Ziele: Daten im neuen System bearbeiten, ältere Vorgänge nur nachlesen oder bestimmte Unterlagen getrennt aufbewahren. Nicht jede Historie muss dieselbe Bedienoberfläche erhalten. Eine lesbare Archivlösung kann für abgeschlossene Vorgänge genügen, während offene Aufgaben im Ziel aktiv bearbeitbar bleiben müssen. Fachbereich und IT sollten diese Entscheidung gemeinsam dokumentieren.
Erfassen Sie außerdem Informationen außerhalb der Hauptansicht. Benutzerdefinierte Felder, Verknüpfungen, Dateien und Zeitstempel können für den Zusammenhang entscheidend sein. Automatisierungsregeln, Rollen und Vorlagen sind gesondert zu betrachten: Ihr Export bedeutet nicht automatisch, dass ein anderes Produkt sie ausführen kann.
Ein offenes Format ist noch kein passender Import
CSV oder JSON können maschinenlesbar sein, beantworten aber nicht allein, wie Informationen zusammengehören. Eine Datei mit Aufgaben hilft wenig, wenn die zugehörige Projektkennung fehlt. Prüfen Sie deshalb neben den Werten auch eindeutige Kennungen, Beziehungen und die Beschreibung der Felder.
Verlangen Sie eine Erklärung zu Datumsformaten, Zeitzonen, Auswahlwerten und Dateireferenzen. Ein Link auf einen Anhang im bisherigen Kundenkonto ist kein unabhängig nutzbarer Anhang. Lassen Sie zeigen, ob die eigentliche Datei mitgeliefert wird und wie sie dem richtigen Vorgang zugeordnet bleibt.
Ein Export über eine Programmierschnittstelle kann zusätzliche Abrufe benötigen. Die Grundlagen erläutert Schnittstellen und APIs einfach erklärt. Für den Ausstieg zählt jedoch nicht die bloße API-Verfügbarkeit, sondern ein vollständiger, dokumentierter Abruf des vereinbarten Umfangs. Das Zielsystem muss diese Struktur anschließend übernehmen oder nachvollziehbar umwandeln können.
Das Prüfraster für Ihren SaaS-Datenexport
Übernehmen Sie dieses Raster in die Abstimmung mit bisherigem Anbieter und möglichem Zielanbieter. Ergänzen Sie je Zeile einen Verantwortlichen, den beobachteten Nachweis und den Status „erfüllt“, „offen“ oder „nicht erfüllt“.
| Prüfbereich | Konkreter Nachweis |
|---|---|
| Umfang | Benötigte Vorgänge, eigene Felder und historische Angaben sind benannt. |
| Beziehungen | Aufgaben, Kommentare und Anlagen bleiben dem richtigen Vorgang zugeordnet. |
| Dateien | Originaldateien sind ohne das bisherige Kundenkonto zugänglich. |
| Format | Feldbeschreibung, Kennungen und Datumsangaben sind dokumentiert. |
| Übernahme | Ein vereinbarter Testvorgang lässt sich im Ziel vollständig verwenden. |
| Abschluss | Letzte Änderungen, Zugriff auf Altbestände und Abschaltung sind geregelt. |
Ein offener Muss-Punkt bleibt ein Wechselhindernis. Viele exportierte Zeilen gleichen fehlende Anlagen oder verlorene Zuordnungen nicht aus. Halten Sie Ausschlüsse ausdrücklich fest, statt aus einer allgemeinen Exportfunktion auf einen vollständigen Umzug zu schließen.
Eine Exportprobe mit klarer Abnahme durchführen
Nutzen Sie folgendes vorgeschlagene Testszenario, keinen echten Kundenfall: Ein Testprojekt enthält eine offene Aufgabe, einen Kommentar, ein eigenes Auswahlfeld und einen Dateianhang. Arbeiten Sie in getrennten Testumgebungen mit freigegebenen Beispieldaten. Benachrichtigungen und externe Schreibzugriffe bleiben deaktiviert.
- Dokumentieren Sie den erwarteten Inhalt und die Beziehungen des Testprojekts.
- Exportieren Sie den vereinbarten Umfang einschließlich Datei und Feldbeschreibung.
- Übernehmen Sie die Daten in das vorgesehene Testziel oder eine unabhängige Leseansicht.
- Lassen Sie eine Fachperson Aufgabe, Kommentar, Auswahlwert und Anhang wiederfinden und prüfen.
- Ändern Sie anschließend eine Testangabe in der Quelle und prüfen Sie, wie diese letzte Änderung übernommen wird.
Vergleichen Sie Erwartung und Ergebnis, nicht nur Dateigrößen. Dokumentieren Sie fehlende Elemente, notwendige Umwandlungen und manuelle Nacharbeit. Eine Stichprobe zeigt konkrete Probleme, garantiert aber noch keine vollständige Übernahme des gesamten Bestands.
Erst nach dem Nachweis die Abschaltung freigeben
Für den tatsächlichen Wechsel braucht es einen festgelegten letzten Datenstand. Klären Sie, wann Änderungen im Altsystem enden, wer die Schlussübernahme bestätigt und wie Mitarbeitende während der Umstellung arbeiten. Eine Rückkehrmöglichkeit muss auch neue Vorgänge berücksichtigen. Wie Workflow-Wartung für KMU erläutert, macht ein technischer Versionswechsel bereits ausgeführte Geschäftsschritte nicht rückgängig.
Löschen oder schließen Sie den Altbestand nicht allein deshalb, weil ein Import ohne Fehlermeldung durchlief. Fachliche Abnahme, erforderliche Aufbewahrung und geregelter Zugriff müssen vorher geklärt sein. Exportkopien enthalten möglicherweise vertrauliche Informationen und benötigen begrenzte Zugriffe sowie eine festgelegte Aufbewahrung.
Wenn beim Wechsel eine konkrete Systemübergabe offenbleibt, bietet die Leistungsseite Schnittstellen und API-Integration den passenden technischen Rahmen. Bringen Sie die betroffene Anwendung, den benötigten Geschäftsvorgang und Ihre wichtigste Übergabehürde in den kostenfreien Digital-Check ein. Im kurzen, unverbindlichen Erstgespräch besprechen wir das Automatisierungspotenzial und nächste Schritte. Eine Vertragsprüfung, vollständige Migrationsplanung oder ein ausgearbeitetes kostenloses Lösungskonzept ist nicht enthalten.