Softwareauswahl heißt auch den Ausstieg planen
Bei der Auswahl neuer Software schauen wir auf Funktionen, Bedienbarkeit und Preis. Das ist verständlich. Schließlich soll die Anwendung ein Problem lösen und nicht schon beim Einstieg kompliziert werden.
Eine Frage würde ich trotzdem gleich zu Beginn stellen: Was passiert mit unserer Arbeit, wenn wir diese Software irgendwann nicht mehr verwenden möchten?
Nehmen wir eine Kundenverwaltung als Beispiel. Über mehrere Jahre entstehen Kontakte, Angebote, Aufträge und Gesprächsnotizen. Dokumente werden hochgeladen, Zuständigkeiten vergeben und Vorgänge miteinander verknüpft. Dann passt ein anderer Anbieter besser zum Betrieb.
Die bisherige Software bietet einen Export an. Heraus kommt eine Tabelle mit Namen und Adressen. Die Anhänge fehlen, die Bearbeitungsverläufe bleiben zurück und die Verbindung zwischen Kunde, Auftrag und Rechnung ist verloren.
Das Beispiel ist fiktiv. Es verdeutlicht aber den Unterschied zwischen zwei Versprechen: Daten irgendwie herauszugeben – und die weitere Arbeit damit tatsächlich zu ermöglichen.
Ein aktueller Anlass: Der Data Act verändert die Wechselbedingungen
Der europäische Data Act gilt seit dem 12. September 2025. Zu seinen Zielen gehört, den Wechsel zwischen erfassten Datenverarbeitungsdiensten zu erleichtern und Hindernisse auf dem Cloudmarkt abzubauen. Die Europäische Kommission erläutert dies in ihrer zuletzt am 2. Juli 2026 aktualisierten Übersicht. [1]
Besonders wichtig ist der nächste Termin: Ab dem 12. Januar 2027 dürfen Anbieter für die vom Gesetz erfassten Wechselvorgänge keine Wechselentgelte mehr verlangen. Dazu gehören auch erfasste Gebühren für den Datenabfluss im Zusammenhang mit dem Wechsel. Für erfasste Plattform- und Softwaredienste beschreibt die Kommission außerdem Anforderungen an offene Schnittstellen und gebräuchliche, maschinenlesbare Exportformate. [2]
Das bedeutet allerdings nicht, dass ein vollständiger Softwarewechsel ab Januar kostenlos erledigt wird. Datenbereinigung, Anpassungen an das neue System, eigene Projektarbeit und Schulungen verschwinden dadurch nicht. Diese Aufwände würde ich weiterhin einplanen.
Ebenso wenig ist jede beliebige Software automatisch von denselben Wechselregeln erfasst. Entscheidend sind der konkrete Dienst und der gesetzliche Anwendungsbereich. Geschützt sind zudem nicht uneingeschränkt sämtliche internen Informationen des Anbieters; beispielsweise bestehen Abgrenzungen für dessen Geschäftsgeheimnisse und geistiges Eigentum. [2]
Für die Auswahl einer Anwendung bleibt deshalb eine praktische Prüfung notwendig. Ein rechtlicher Anspruch hilft wenig, wenn erst unter Zeitdruck geklärt wird, welche Daten überhaupt benötigt werden.
Ein Exportknopf sagt wenig über die Qualität des Exports
Für mich beginnt ein brauchbarer Export bei der Frage, welche Informationen die Arbeit tatsächlich ausmachen.
In unserer beispielhaften Kundenverwaltung wären das nicht nur die sichtbaren Stammdaten:
Kunden und Ansprechpartner: Eindeutige Zuordnung, Kontaktinformationen und benötigte Zusatzfelder.
Angebote und Aufträge: Inhalte, Bearbeitungsstände und die Verbindung zum jeweiligen Kunden.
Dokumente und Anhänge: Dateien mit nachvollziehbarer Zuordnung zum richtigen Vorgang.
Bearbeitungsverläufe: Benötigte Zeitangaben und dokumentierte Änderungen.
Einstellungen und Berechtigungen: Eine Übersicht, anhand derer die neue Umgebung bewusst eingerichtet werden kann.
Diese Tabelle beschreibt einen möglichen Bedarf, keinen pauschalen gesetzlichen Anspruch auf jeden genannten Bestandteil.
Der Unterschied ist wichtig: Nicht alles lässt sich unverändert übertragen. Manche Funktionen existieren im neuen System anders oder überhaupt nicht. Dann braucht es eine Entscheidung darüber, wie die betreffende Information künftig genutzt oder archiviert wird.
Ein Wechsel ist nicht gelungen, wenn zwar Dateien vorhanden sind, aber niemand mehr erkennt, was zusammengehört.
CSV und JSON helfen – eine Dateiendung allein genügt nicht
Offene, dokumentierte Formate erleichtern die Weiterverarbeitung. Sie beantworten aber nicht automatisch jede inhaltliche Frage.
Die W3C-Handreichung „CSV on the Web: A Primer“ vom 25. Februar 2016 beschreibt eine grundlegende Einschränkung einfacher CSV-Dateien: Das Format legt für sich genommen beispielsweise nicht fest, welchen Datentyp eine Spalte enthält oder welche Werte eindeutig sein müssen. Ergänzende Metadaten können solche Informationen ausdrücken und Prüfungen ermöglichen. [3]
Bei einem Export würde ich deshalb auch die Beschreibung der Felder verlangen. Steht eine Zahl für einen Betrag, eine interne Kennung oder eine Postleitzahl? Welche Bedeutung hat ein leerer Eintrag? Welche Zeitzone gilt für gespeicherte Zeitangaben?
Ein einfaches Beispiel: Die Kundennummer „00127“ darf nicht versehentlich wie eine gewöhnliche Rechenzahl behandelt werden, wenn die führenden Nullen für die Zuordnung wichtig sind.
Auch Beziehungen müssen nachvollziehbar bleiben. Eine Auftragsliste sollte erkennen lassen, welcher Kundenkennung jeder Auftrag zugeordnet ist. Dateianhänge benötigen dieselbe Verlässlichkeit.
Für Entwickler ist das eine Aufgabe des Datenmodells. Ein sauber beschriebener Export entsteht nicht allein dadurch, dass der gesamte Datenbankinhalt in eine Datei geschrieben wird.
Eine Schnittstelle muss im Alltag nutzbar sein
Eine Programmierschnittstelle, meist API genannt, ermöglicht anderen Anwendungen den geregelten Zugriff auf bestimmte Funktionen und Daten.
Für die Beschreibung solcher Schnittstellen gibt es etablierte Verfahren. Die OpenAPI-Spezifikation 3.2.1 vom 10. September 2026 beschreibt HTTP-Schnittstellen in einer standardisierten, von der Programmiersprache unabhängigen Form. Dadurch können Menschen und Werkzeuge nachvollziehen, welche Möglichkeiten ein Dienst bereitstellt. [4]
Bei einer Softwarevorführung würde ich mich trotzdem nicht mit dem Satz „Eine API ist vorhanden“ zufriedengeben.
Ich möchte wissen, ob die benötigten Daten darüber erreichbar sind, welche Berechtigungen erforderlich sind und welche Grenzen für Abrufe gelten. Ebenso wichtig ist, wie Änderungen an der Schnittstelle angekündigt werden.
Eine Verbindung, die nur einen Teil der benötigten Daten liefert, ist für einen vollständigen Umzug möglicherweise nicht ausreichend. Für regelmäßige Übergaben an eine andere Anwendung kann sie dagegen genau richtig sein.
„Offen“ sollte außerdem nicht mit „ungeschützt“ verwechselt werden. Die Dokumentation einer Schnittstelle kann offen sein, während der Zugriff auf Kundendaten selbstverständlich eine passende Berechtigung erfordert.
Für Entwickler: Den Ausstieg als normale Funktion behandeln
Wenn ich eine Anwendung neu plane, würde ich Export und Import nicht erst dann ergänzen, wenn der erste Kunde kündigt.
Dazu gehören stabile Kennungen, dokumentierte Formate und klar abgegrenzte Übergaben an externe Dienste. Werden wichtige Informationen ausschließlich in undokumentierten Sonderfeldern abgelegt, muss beim späteren Wechsel jemand deren Bedeutung rekonstruieren.
Bei einer externen Dokumentenerstellung würde ich beispielsweise festhalten, welche Daten hineingehen und welche Ergebnisse zurückkommen. So lässt sich später prüfen, ob ein anderer Dienst dieselbe Aufgabe übernehmen kann.
Nicht jede Anbieterabhängigkeit ist automatisch ein Fehler. Eine besondere Funktion kann einen erheblichen Nutzen haben. Ich würde nur bewusst entscheiden, welchen Vorteil sie bringt und was ihr späterer Ersatz erfordern würde.
Vollständige Austauschbarkeit um jeden Preis wäre ebenfalls kein vernünftiges Ziel. Eine einfache Anwendung muss nicht vorsorglich jeden denkbaren Dienst unterstützen. Wichtig ist, dass wesentliche Abhängigkeiten bekannt sind und nicht zufällig entstehen.
Den Wechsel testen, solange noch kein Zeitdruck besteht
Vor einer größeren Einführung würde ich einen kleinen Probelauf vereinbaren.
Dafür werden einige geeignete Testvorgänge angelegt: ein Kunde mit mehreren Ansprechpartnern, ein Auftrag mit Anhängen und ein Vorgang mit nachträglichen Änderungen. Anschließend werden diese Daten exportiert und in eine getrennte Testumgebung übernommen.
Der Test sollte nicht beim Hinweis „Import erfolgreich“ enden. Lassen sich die Dokumente öffnen? Stimmen Beträge und Datumsangaben? Sind die Beziehungen zwischen den Vorgängen erhalten? Werden Sonderzeichen richtig dargestellt?
Die Anzahl der Datensätze ist ein erster Anhaltspunkt, aber kein vollständiger Nachweis. Gleich viele Einträge können trotzdem falsch zugeordnet sein.
Beim späteren Echtwechsel braucht es zusätzlich einen klaren Umschaltpunkt. Sonst werden möglicherweise alte Daten übernommen, während im ursprünglichen System bereits neue Änderungen entstehen.
Auch ein Rückweg gehört dazu: Welche Voraussetzungen müssen erfüllt sein, bevor der alte Dienst abgeschaltet wird? Was geschieht, wenn die neue Anwendung einen wichtigen Arbeitsablauf noch nicht beherrscht?
Der richtige Zeitpunkt für diese Fragen ist vor der Kündigung.
Datensicherheit gilt auch für die Umzugsdatei
Eine vollständig exportierte Kundenverwaltung kann besonders schutzbedürftig sein, weil viele Informationen an einer Stelle zusammenkommen.
Der Europäische Datenschutzausschuss beschreibt in seinem am 10. Oktober 2026 geprüften Leitfaden für kleinere Unternehmen, dass personenbezogene Daten durch risikogerechte technische und organisatorische Maßnahmen geschützt werden müssen. Dazu gehören je nach Risiko unter anderem Zugriffskontrollen, Verschlüsselung und nachvollziehbare Verfahren. [5]
Für einen Datenumzug würde ich deshalb festlegen, wer die Exportdatei erhalten darf, wo sie vorübergehend liegt und wie sie übertragen wird. Eine Datei auf dem privaten Desktop eines Mitarbeiters wäre kein geplanter Übergabeweg.
Nach Abschluss müssten nicht mehr benötigte Zwischenkopien kontrolliert entfernt werden. Erforderliche Archive und Sicherungen sollten dagegen bewusst eingerichtet bleiben. Was weiter aufbewahrt werden muss und was gelöscht werden darf, ist vorab zu klären.
Ein erfolgreicher Import beendet also nicht automatisch sämtliche Aufgaben rund um den Wechsel.
Was ich vor einem Softwareabo wissen möchte
Neben der Funktionsvorführung würde ich mir die Bedingungen für den späteren Ausstieg schriftlich erklären lassen.
Welche Inhalte können exportiert werden? Welche Formate sind verfügbar? Wer unterstützt bei Problemen? Wie lange bleibt nach Vertragsende ein Zugriff möglich? Welche Kostenpositionen werden für die geplante Umstellung angesetzt und auf welcher Grundlage?
Auch die Erreichbarkeit wichtiger Funktionen spielt eine Rolle. Lässt sich ein Export nur über den Anbieter anfordern oder durch berechtigte Nutzer selbst durchführen? Ist eine verständliche Dokumentation vorhanden?
Für die laufende Betreuung würde ich den Probelauf nach wesentlichen Änderungen wiederholen. Ein Export, der vor mehreren Jahren funktioniert hat, sagt noch nichts darüber aus, ob die heute zusätzlich verwendeten Funktionen ebenfalls berücksichtigt werden.
Mein Fazit: Gute Software muss den Wechsel aushalten
Ich halte nichts davon, einen passenden Anbieter allein aus Prinzip zu verlassen. Eine bewährte Zusammenarbeit kann viel wert sein.
Trotzdem möchte ich bleiben, weil die Leistung überzeugt – nicht, weil ein Wechsel praktisch unmöglich geworden ist.
Dazu braucht es mehr als einen freundlichen Satz über „die eigenen Daten“. Die Informationen müssen in einer Form verfügbar sein, mit der sich sinnvoll weiterarbeiten lässt. Dokumentation, Beziehungen zwischen den Daten und ein erprobter Übergabeweg gehören dazu.
Gute Software erleichtert den Einstieg. Vertrauenswürdige Software macht auch den Ausstieg nachvollziehbar.
Einordnung und Recherche
Recherchestand: 10. Oktober 2026. Allgemeine Orientierung, keine rechtliche Prüfung des konkreten Vertrags, Dienstes oder Migrationsvorhabens. Gesetzliche Wechselregeln gelten nur innerhalb ihres jeweiligen Anwendungsbereichs; eine vollständige Migration wird dadurch nicht automatisch kostenlos.
Quellen und weiterführende Informationen
Originalquellen geprüft am 10.10.2026. Veröffentlichungs- und Abrufdaten sind zu unterscheiden.
[1] Europäische Kommission: „Data Act“
Quelle lesen ↗
[2] Europäische Kommission: „Data Act explained“
Quelle lesen ↗
[3] W3C: „CSV on the Web: A Primer“
Quelle lesen ↗
[4] OpenAPI Initiative: „OpenAPI Specification 3.2.1“
Quelle lesen ↗
[5] Europäischer Datenschutzausschuss: „Secure personal data“
Quelle lesen ↗