HR-Software-API und Exit-Strategie: Datenhoheit von Anfang an sichern
Wer 2025 oder 2026 eine neue HR-Software für Payroll, Personalakte, Recruiting oder Talent Management einführt, unterschreibt in aller Regel einen Vertrag für drei bis fünf Jahre und denkt dabei fast nie an den Tag, an dem dieser Vertrag wieder endet. Genau das ist der teuerste Fehler bei der HR-Software-Auswahl in Deutschland: Die Exit-Strategie wird erst verhandelt, wenn der Wechsel bereits unausweichlich ist, und damit aus einer Position der Schwäche heraus.
Nach dem Cloud-Report 2025 von Bitkom Research fühlen sich 53 Prozent der cloud-nutzenden Unternehmen in Deutschland ihren Cloud-Anbietern bei Preisen und Vertragskonditionen „ausgeliefert". Gleichzeitig stufen bislang nur 41 Prozent der Unternehmen eine einfache Wechselmöglichkeit überhaupt als zwingendes Auswahlkriterium ein. Verschärft wird die Lage durch den EU Data Act (Verordnung (EU) 2023/2854), dessen Kapitel zu Cloud-Wechsel und Datenportabilität seit dem 12. September 2025 gilt und HR-Software als Software-as-a-Service explizit mit erfasst.
Warum eine Exit-Strategie zur Auswahl gehört, nicht erst zur Kündigung
Datenhoheit wird in den meisten Ausschreibungen erst zum Thema, wenn es bereits zu spät ist.
Drei Situationen, in denen Vendor-Lock-in teuer wird
In den meisten HR-Software-Ausschreibungen dominieren Funktionsumfang, User Experience und Preis pro Kopf die Entscheidung. API-Dokumentation, Exportformate und Exit-Konditionen tauchen, wenn überhaupt, als Fußnote im Pflichtenheft auf.
- Beim Anbieterwechsel: „offene API" erlaubt oft nur Lesezugriff auf Teildaten
- Bei Carve-outs: § 613a BGB setzt enge Fristen, die ein unvorbereiteter Export nicht hält
- Bei regulatorischem Zwang: kurzfristiger Exportweg statt 90-Tage-Kündigungsfrist nötig
Exit-by-Design als fester Bestandteil der Auswahl
Eine belastbare Exit-Strategie beginnt nicht mit der Kündigung, sondern mit dem Lastenheft. API-Vollständigkeit wird als eigenständiges, gewichtetes Bewertungskriterium geprüft, nicht als Nebensatz im Anbietergespräch.
- Exportformate werden vor Unterschrift per Testmigration verifiziert
- Data-Ownership-Klauseln stehen explizit im Vertrag, nicht in den AGB
- Exit-Fähigkeit wird über die Laufzeit regelmäßig erneut getestet
Verhandlungsposition vor Vertragsunterschrift nutzen
Diese Denkweise kostet in der Einführungsphase zusätzliche Zeit und verhandlungstechnisches Kapital. Sie zahlt sich aber genau dann aus, wenn ein Wechsel unausweichlich wird: durch Übernahme, Repricing oder ein besseres System am Markt.
- Mindestens die Dimensionen API, Vertrag und Übergangsfrist vertraglich zusichern lassen
- Mündliche Zusagen im Vertrieb ersetzen keinen technischen Test
- Mehr dazu in unserer HR-Systemarchitektur
Die Exit-Readiness-Bewertungsmatrix für HR-Software
Statt eines Anbietervergleichs, der bei einem Architektur- und Methodikthema wenig aussagekräftig wäre, braucht es ein Bewertungsraster, mit dem Fachbereich, IT und Einkauf jede HR-Software anhand derselben fünf Dimensionen und drei Reifegrade einstufen können.
| Dimension | Basis (Restrisiko hoch) | Fortgeschritten (Marktüblich) | Best Practice (Zielbild) |
|---|---|---|---|
API-VollständigkeitZugriff auf Entitäten |
Nur Lesezugriff auf Stammdaten; Bewegungsdaten, Dokumente und Freitextfelder gesperrt | Lese-/Schreibzugriff auf die meisten Objekte via REST/OData, aber mit Rate-Limits; Bulk-API oft nur im höheren Preistier | Vollständiger, dokumentierter Zugriff inkl. Anhängen, Audit-Trails, Bulk-Endpunkt, SCIM-Unterstützung, ohne Aufpreis im Standardvertrag |
ExportformateDatenstandards |
Ausschließlich proprietäre CSV-Exporte ohne Datenmodell oder Feldbeschreibung | Strukturierte JSON-/XML-Exporte mit rudimentärer Dokumentation der Feldsemantik | Maschinenlesbare Exporte orientiert an offenen Schemata (z. B. HR Open Standards Consortium) mit vollständigen Metadaten und referenzieller Integrität |
Vertragliche KlauselnData Ownership |
Vertrag verweist pauschal auf AGB; keine Aussage zu Eigentum, Export oder Löschung | Kündigungsfrist und allgemeiner Rückgabeanspruch, aber ohne Format, Frist oder Kostenregelung | Eigene Data-Ownership-Klausel mit Exportfrist, Format, Kostenobergrenze; bei kritischen Systemen ergänzt um Data-Escrow |
ÜbergangsfristenAnbieter-Mitwirkung |
Zugriff endet zum Vertragsende ohne Frist; Löschung oft kurzfristig und nicht fixiert | Fixierte Übergangsfrist von einigen Wochen mit Lesezugriff, aber ohne aktive Migrationsunterstützung | Mind. 30 Kalendertage mit aktiver Mitwirkungspflicht (Ansprechperson, Support, Exportwerkzeuge), orientiert am EU Data Act |
TestbarkeitSandbox |
Kein Testzugang vor Vertragsabschluss; API-Verhalten erst nach Unterschrift sichtbar | Demo-/Trial-Zugang vorhanden, aber ohne repräsentative Datenmenge oder Exportsimulation | Dedizierte Sandbox mit synthetischen, strukturell realistischen Testdaten für vollständige Testmigration vor Unterschrift |
Nach unserer Einschätzung sollte kein Fachbereich einen mehrjährigen HR-Software-Vertrag unterschreiben, ohne mindestens die Dimensionen API-Vollständigkeit, Vertragsklauseln und Übergangsfristen im „Fortgeschritten"-Niveau vertraglich zugesichert zu bekommen. Eine detaillierte Prüf-Checkliste bietet unsere HR-Software-Checkliste.
Sieben Aspekte, die im Detail entscheiden
Eine „offene API" ist ein Marketingbegriff, kein technisches Kriterium. Diese Aspekte sollten vor jeder Vertragsunterschrift konkret geprüft werden.
API-Vollständigkeit richtig prüfen
Entscheidend ist, ob eine echte Entity-API vorliegt oder nur „Report as a Service", und ob Bulk-/Async-Muster sowie Cursor-Pagination für Vollexporte bei großen Belegschaften unterstützt werden. Details siehe unser Beitrag zu API-Integrationen Best Practices.
Zugriffsvoraussetzungen klären
Authentifizierungsverfahren (marktüblich OAuth2 Client-Credentials), Scopes für Bulk-Lesezugriffe, IP-Allowlisting und Rotationspflichten für API-Keys entscheiden, ob ein Export im Ernstfall praktisch durchführbar ist, nicht erst das Datenmodell.
Exportformate: strukturiert statt proprietär
Art. 20 DSGVO verlangt, soweit anwendbar, ein „strukturiertes, gängiges und maschinenlesbares Format". Ohne Datenwörterbuch wird selbst ein technisch sauberer Export im Zielsystem zur Blackbox.
Vendor-Lock-in systematisch erfassen
Lock-in entsteht nicht nur durch fehlende APIs, sondern auch prozessual: individuelle Freigabe-Workflows, unternehmensspezifische Reportings oder Schnittstellen zu Payroll-Dienstleistern wie DATEV, die im neuen System nachgebaut werden müssen.
Data-Ownership vertraglich verankern
Ohne explizite Regelung greift ersatzweise § 675 BGB mit Verweis auf den Herausgabeanspruch nach § 667 BGB, der im Streitfall deutlich schwerer durchzusetzen ist als eine klare Exit-Klausel im Vertrag selbst.
Übergangsfristen realistisch bemessen
Der EU Data Act setzt ein zweistufiges Fristenmodell: erst eine Mitteilungsfrist von max. zwei Monaten, danach eine technische Übergangsfrist von i. d. R. 30 Tagen, verlängerbar auf bis zu sieben Monate bei begründeter Komplexität.
Dokumentation und Versionierung der Schnittstellen
APIs ändern sich über eine mehrjährige Vertragslaufzeit. Ohne versionierte, öffentlich einsehbare Dokumentation mit Changelog drohen Breaking Changes, die bestehende Integrationen und geplante Exportroutinen unbemerkt außer Kraft setzen. Best Practice ist eine API mit expliziter Versionsnummer, angekündigter Deprecation-Frist und öffentlich zugänglichem Changelog.
Rechtliche Rahmenbedingungen bei Anbieterwechsel und Datenhoheit
DSGVO, EU Data Act, Aufbewahrungsfristen und Mitbestimmung greifen ineinander. Wer sie erst beim Exit prüft, verliert wertvolle Zeit.
Art. 20: Recht auf Datenübertragbarkeit
Gilt nur für Daten, die auf Einwilligung oder Vertrag beruhen und selbst „bereitgestellt" wurden. Beschäftigtendaten stützen sich überwiegend auf § 26 BDSG. Die Anwendbarkeit auf Personalakten- und Payroll-Daten ist in der Fachliteratur umstritten. Die vertragliche Exit-Klausel darf sich darauf nicht verlassen.
Cloud-Switching-Pflichten seit 09/2025
Verordnung (EU) 2023/2854 verpflichtet Anbieter zu kostenfreien, dokumentierten APIs, einer Übergangsfrist und schrittweiser Abschaffung von Wechselentgelten bis zum vollständigen Verbot am 12. Januar 2027. Aufsicht in Deutschland: Bundesnetzagentur (DADG).
Fristen laufen nach Vertragsende weiter
Lohnkonten sechs Jahre (§ 41 EStG), Buchungsbelege acht Jahre (§ 147 AO). Für bAV-Unterlagen empfiehlt sich bis zu 30 Jahre Aufbewahrung, da Ansprüche nach § 18a BetrAVG erst dann verjähren. Ohne Nachweis sind sie sonst nicht belegbar.
Auftragsverarbeitung
Der AVV sollte explizit regeln, was bei Beendigung der Verarbeitung geschieht: Rückgabe oder Löschung, Format, Frist. Fehlt dies, fallen datenschutzrechtlicher und zivilrechtlicher Rahmen im Exit-Fall auseinander.
§ 87 Abs. 1 Nr. 6 BetrVG
Ein Systemwechsel berührt in der Regel Mitbestimmungsrechte, da HR-Systeme Verhaltens- oder Leistungsüberwachung ermöglichen können. Ohne rechtzeitige Abstimmung mit dem Betriebsrat verzögert sich der gesamte Migrationszeitplan.
Haftung bei Datenverlust
Datenmigrationsprojekte überschreiten häufig Budget oder Zeitrahmen, wenn Datenmodell und Exportformat vorab nicht getestet wurden. Bei HR-Daten ist Datenverlust nicht nur ein IT-, sondern ein arbeits- und aufsichtsrechtliches Risiko.
In sechs Schritten zur belastbaren Exit-Strategie
Von der Aufnahme ins Lastenheft bis zum strukturiert durchgeführten Wechsel im Bedarfsfall.
Exit-Kriterien ins Lastenheft aufnehmen
API-Vollständigkeit, Exportformate und Data-Ownership werden als eigenständige, gewichtete Kriterien definiert, mit denselben Punktzahlen wie Kernfunktionen.
API-Audit im Auswahlprozess
Öffentliche API-Dokumentation prüfen und, wo möglich, Testzugang nutzen: Entitäten, Rate-Limits, Bulk-/Async-Muster, Authentifizierung und Aktualität der Dokumentation.
Exit-Klauseln fixieren
Data-Ownership, Exportformat, Übergangsfrist, Mitwirkungspflichten und Kostenobergrenze werden als eigene Vertragsanlage verhandelt, nicht dem AGB-Text überlassen.
Testmigration vor Go-Live
Vollständiger Exportlauf mit repräsentativen (ggf. anonymisierten) Testdaten, überführt ins Zielformat, um zugesicherte Exportfähigkeit tatsächlich zu verifizieren.
Exit-Fähigkeit regelmäßig prüfen
Die Exit-Readiness-Matrix wird in festem Turnus, jährlich oder bei größeren Releases, erneut durchlaufen, da sich API-Umfang und Recht ändern können.
Exit strukturiert durchführen
Kündigung, Aktivierung der Übergangsfrist, vollständiger Export, Betriebsrats-Abstimmung und Verifikation aller aufbewahrungspflichtigen Daten vor Zugriffsende.
Häufig gestellte Fragen
Antworten auf die wichtigsten Fragen zu API-Vollständigkeit, Exportformaten und Datenhoheit bei HR-Software.
Was bedeutet Datenhoheit bei HR-Software konkret?
Datenhoheit bedeutet, dass ein Unternehmen jederzeit die faktische und rechtliche Kontrolle über seine im HR-System gespeicherten Daten behält, unabhängig davon, bei welchem Anbieter die Daten technisch gehostet werden. Das umfasst das Recht auf vollständigen, unbeschränkten Export in einem nutzbaren Format, die Gewissheit, dass keine versteckten technischen oder vertraglichen Hürden den Zugriff einschränken, sowie die Klarheit, wem die Daten rechtlich zugeordnet sind. In der Praxis zeigt sich Datenhoheit weniger an Marketingaussagen des Anbieters als an konkreten Vertragsklauseln und tatsächlich getesteten Exportwegen.
Welche Daten muss ein HR-Software-Anbieter beim Wechsel herausgeben?
Grundsätzlich alle Daten, die das Unternehmen eingegeben oder die im System für das Unternehmen generiert wurden: Stammdaten, Bewegungsdaten, Dokumentenanhänge, Genehmigungs- und Änderungshistorien sowie, je nach vertraglicher Vereinbarung, auch Konfigurationsdaten wie Workflow-Regeln. Der genaue Umfang hängt vom Vertrag ab; ohne explizite Data-Ownership-Klausel besteht das Risiko, dass sich der Anbieter auf einen eingeschränkten „Standardexport" beschränkt. Für personenbezogene Daten greift ergänzend das Recht auf Datenübertragbarkeit nach Art. 20 DSGVO, dessen Anwendbarkeit auf klassische Personalakten- und Payroll-Daten aber rechtlich nicht unumstritten ist, weil diese meist auf § 26 BDSG statt auf Vertrag oder Einwilligung gestützt werden. Verlässlicher als das gesetzliche Individualrecht ist deshalb eine eigene, unternehmensweite Vertragsklausel.
Gilt der EU Data Act auch für HR-Software als SaaS-Lösung?
Ja. Der EU Data Act (Verordnung (EU) 2023/2854) definiert „Datenverarbeitungsdienste" breit und erfasst damit ausdrücklich auch Software-as-a-Service-Angebote wie Cloud-basierte HR-Software, nicht nur reine Infrastrukturdienste (IaaS). Die Cloud-Switching-Vorschriften in Kapitel VI der Verordnung gelten seit dem 12. September 2025 und damit auch für bereits bestehende Verträge. Allerdings garantiert der Data Act primär technische Datenportabilität und offene Schnittstellen, nicht aber inhaltliche Funktionsgleichheit zwischen Alt- und Neusystem.
Wie lange dauert ein Anbieterwechsel bei HR-Software laut Data Act?
Der EU Data Act sieht ein zweistufiges Fristenmodell vor: zunächst eine Mitteilungsfrist von maximal zwei Monaten, in der der Kunde den Wechsel gegenüber dem Anbieter ankündigt, danach eine technische Übergangsfrist von im Regelfall 30 Kalendertagen für die eigentliche Datenübertragung. Kann der Anbieter innerhalb von 14 Werktagen technisch begründen, dass dieser Zeitrahmen bei komplexen Systemen nicht ausreicht, kann sich die Übergangsfrist auf bis zu sieben Monate verlängern. Zusätzlich hat der Kunde nach Ablauf der Übergangsfrist noch mindestens 30 weitere Kalendertage Zeit, um Daten abzurufen, bevor der Anbieter sie löschen darf.
Was kostet der Datenexport beim Anbieterwechsel?
Nach dem EU Data Act dürfen Anbieter im Zeitraum vom 11. Januar 2024 bis zum 12. Januar 2027 nur noch „direkte, kostenbezogene" Wechselentgelte verlangen. Pauschale Straf- oder Abschreckungsgebühren sind bereits jetzt unzulässig. Ab dem 12. Januar 2027 entfallen Switching-Fees vollständig. Bis dahin sollten Unternehmen die konkrete Kostenstruktur für Exportunterstützung vor Vertragsunterschrift verhandeln, statt sich erst im Kündigungsfall mit den Preisen des Anbieters auseinanderzusetzen.
Welche Exportformate sollte eine HR-Software mindestens unterstützen?
Mindeststandard sind strukturierte, dokumentierte Formate wie CSV mit begleitendem Datenwörterbuch oder JSON/XML mit klar definiertem Schema. Reine PDF-Ausdrucke oder proprietäre Binärformate ohne Dokumentation gelten nicht als ausreichend im Sinne von Art. 20 DSGVO. Best Practice orientiert sich, wo verfügbar, an offenen, herstellerneutralen Schemata wie denen des HR Open Standards Consortium; in der Breite des deutschen Marktes ist die native Unterstützung solcher Schemata für Kern-HR-Daten aber noch die Ausnahme, weshalb ein sauberes eigenes Datenwörterbuch häufig der realistischere Maßstab ist. Für Identitäts- und Zugriffsdaten hat sich zusätzlich der SCIM-Standard etabliert.
Was passiert mit Gehaltsabrechnungen und Personalakten nach Vertragsende?
Gesetzliche Aufbewahrungspflichten bestehen unabhängig vom Softwarewechsel fort: Lohnkonten sind nach § 41 EStG sechs Jahre und steuerlich relevante Belege nach § 147 AO seit 2025 acht Jahre aufzubewahren. Für Unterlagen zur betrieblichen Altersvorsorge gibt es keine eigene gesetzliche Aufbewahrungsfrist; in der Praxis werden sie dennoch bis zu 30 Jahre vorgehalten, weil Leistungsansprüche nach § 18a BetrAVG erst nach 30 Jahren verjähren und ohne Nachweisunterlagen sonst nicht mehr belegbar sind. Diese Daten müssen entweder im neuen System oder in einem separaten, GoBD-konformen Archivsystem revisionssicher vorgehalten werden.
Muss der Betriebsrat bei einem Wechsel der HR-Software beteiligt werden?
In den meisten Fällen ja: HR-Software, die Verhaltens- oder Leistungsdaten von Beschäftigten erfasst oder auswerten kann, fällt unter das Mitbestimmungsrecht nach § 87 Abs. 1 Nr. 6 BetrVG. Ein Systemwechsel, auch wenn er primär als IT- oder Migrationsprojekt verstanden wird, sollte daher frühzeitig mit dem Betriebsrat abgestimmt werden, um Verzögerungen im Migrationszeitplan zu vermeiden. Die konkrete Ausgestaltung hängt vom Funktionsumfang des neuen Systems ab und sollte im Zweifel arbeitsrechtlich geprüft werden.
Wie teste ich die Exit-Fähigkeit eines HR-Software-Anbieters vor Vertragsunterschrift?
Der zuverlässigste Weg ist eine Testmigration mit repräsentativen, idealerweise anonymisierten Testdaten in einer Sandbox-Umgebung: Ein vollständiger Exportlauf über die angebotene API wird durchgeführt und geprüft, ob alle im Lastenheft geforderten Datenobjekte, Anhänge und Beziehungen tatsächlich abrufbar sind, inklusive eines Blicks auf Authentifizierungsverfahren und die Geschwindigkeit, mit der neue API-Zugänge im Bedarfsfall bereitgestellt werden. Eine mündliche Zusage im Vertriebsgespräch ersetzt diesen technischen Test nicht.
Was tun, wenn ein bestehender Vertrag keine Exit-Klausel enthält?
Auch ohne explizite Exit-Klausel bestehen gesetzliche Mindestrechte: das Recht auf Datenübertragbarkeit nach Art. 20 DSGVO für personenbezogene Daten, wobei seine Anwendbarkeit auf Beschäftigtendaten rechtlich diskutiert wird, sowie seit September 2025 die Cloud-Switching-Pflichten des EU Data Act, sofern der Anbieter als Datenverarbeitungsdienst im Sinne der Verordnung gilt. Unternehmen sollten in diesem Fall frühzeitig, spätestens mit der nächsten ordentlichen Kündigungsfrist, schriftlich auf diese gesetzlichen Ansprüche verweisen und eine Nachverhandlung der Exit-Konditionen anstoßen, statt bis zum Vertragsende zu warten.
Exit-Strategie von Anfang an mitdenken, bevor der Vertrag unterschrieben ist
Eine belastbare Exit-Strategie lässt sich nicht nachträglich in einen laufenden HR-Software-Vertrag hineinverhandeln. Sie muss Teil des Auswahlprozesses sein, mit denselben Bewertungskriterien wie Funktionsumfang und Preis. Find-Your-HR unterstützt Unternehmen dabei, API-Vollständigkeit, Exportformate und Data-Ownership-Klauseln systematisch in die HR-Software-Auswahl zu integrieren.