Cloud- und SaaS-Lösungen sind für viele Unternehmen heute selbstverständlich. Sie ermöglichen schnelle Implementierung, geringe Anfangsinvestitionen und kontinuierliche Updates. Auch im Umfeld von Ingenieur- und Architekturbüros sind browsergestützte Drittanwendungen weit verbreitet.

Parallel dazu gewinnt jedoch ein Thema an Bedeutung, das lange vernachlässigt wurde:
Wie bleibt ein Unternehmen handlungsfähig, wenn es einen SaaS-Anbieter wechseln möchte oder muss?

Preisanpassungen, strategische Neuausrichtungen des Anbieters, Unternehmensübernahmen, regulatorische Anforderungen oder Sicherheitsbedenken können einen Wechsel erforderlich machen. Spätestens dann stellt sich die Frage der Datenhoheit.

Datenhoheit ist nicht nur technisch – sondern rechtlich geregelt

Die Diskussion um SaaS-Abhängigkeit ist inzwischen nicht mehr nur eine strategische Überlegung. Sie ist auch gesetzlich adressiert.

1️⃣ EU Data Act (Verordnung (EU) 2023/2854)

Seit dem 12. September 2025 gilt der EU Data Act verbindlich. Er enthält klare Vorgaben für Cloud- und SaaS-Anbieter hinsichtlich:

• Anbieterwechsel („Cloud Switching“)
• Datenportabilität
• Interoperabilität
• Transparenzpflichten

Anbieter müssen sicherstellen, dass:

• Kundendaten in einem strukturierten, gängigen und maschinenlesbaren Format exportiert werden können
• technische Hindernisse für einen Wechsel nicht künstlich aufgebaut werden
• Wechselprozesse unterstützt werden
• Vertragsbedingungen den Exit nicht faktisch verhindern

Zudem werden sogenannte Wechselentgelte („Egress Fees“) schrittweise abgeschafft.

Das Ziel des Gesetzgebers ist eindeutig:
Vendor-Lock-in soll strukturell reduziert werden.

2️⃣ DSGVO – Recht auf Datenübertragbarkeit

Ergänzend dazu regelt die DSGVO das Recht auf Datenübertragbarkeit bei personenbezogenen Daten.

Betroffene Personen haben Anspruch darauf, ihre Daten in einem strukturierten, maschinenlesbaren Format zu erhalten. Für Unternehmen bedeutet das:

• personenbezogene Daten dürfen nicht technisch eingeschlossen werden
• Exportfunktionen müssen praktikabel sein
• Datenzugriff muss gewährleistet werden

Damit ist Datenhoheit nicht nur eine strategische, sondern auch eine regulatorische Anforderung.

Gesetzlicher Anspruch ersetzt keine technische Vorbereitung

Trotz klarer gesetzlicher Vorgaben bleibt ein praktisches Problem:
Ein Datenexport ist nicht automatisch eine funktionierende Migration.

Typische Herausforderungen:

• CSV-Dateien ohne Relationen
• fehlende Metadaten
• keine dokumentierte Geschäftslogik
• unklare Transformationsregeln
• fehlende Validierungsmechanismen

Das Gesetz schafft das Recht auf Portabilität –
aber nicht die operative Migrationsfähigkeit.
Hier beginnt die unternehmerische Verantwortung.

Die Rolle einer lokal installierten ERP-Lösung

Eine lokal installierte ERP-Software – auf eigener Infrastruktur betrieben und mit offener Datenbanktechnologie – kann in diesem Kontext Teil einer nachhaltigen Exit-Strategie sein.

Infrastrukturkontrolle

• Betrieb auf eigenen Servern
• physischer Zugriff auf Datenbank und Backups
• unabhängige Archivierung
• langfristige Verfügbarkeit

Gerade für Planungsbüros mit jahrzehntelanger Projekthistorie ist das ein relevanter Faktor.

Offene Datenbanktechnologie

Wenn eine ERP-Lösung auf einer offenen, dokumentierten Datenbank basiert (z. B. Firebird), entsteht zusätzliche Transparenz:

• Datenstrukturen sind nachvollziehbar
• keine proprietären Cloud-Container
• langfristige Lesbarkeit ohne Plattformbindung
• unabhängige Datensicherung

Open Source allein garantiert keine Freiheit –
aber es reduziert strukturelle Intransparenz.

Migrationsschnittstellen als strategisches Instrument

Entscheidend ist, ob eine ERP-Lösung Migration als strukturierten Prozess versteht.
Dazu gehören:

• dokumentierte Importmechanismen
• Feld- und Objektmappings
• Transformationslogik
• Validierungsregeln
• Prüfsummen- und Konsistenzkontrollen
• Protokollierte Migrationsläufe

Erst dadurch wird ein gesetzlich verankertes Wechselrecht praktisch nutzbar.

Single Source of Truth als Grundlage

Unabhängig vom Betriebsmodell ist die zentrale Frage:
Existiert eine konsistente, unter eigener Kontrolle stehende Datenbasis?

Eine Single Source of Truth bedeutet:

• vollständige Projekthistorien
• strukturierte Belegdaten
• dokumentierte Geschäftsregeln
• nachvollziehbare Migrationen
• revisionssichere Protokollierung

Wer diese Grundlage besitzt, ist nicht gegen SaaS –
sondern unabhängig von einzelnen Anbietern.

SaaS bleibt wirtschaftlich sinnvoll – mit Exit-Fähigkeit

Eine ausgewogene Betrachtung erkennt an:
SaaS bietet Vorteile in:

• Implementierungsgeschwindigkeit
• Wartungsaufwand
• Skalierung
• kurzfristiger Flexibilität

Doch unternehmerische Stabilität erfordert zusätzlich:

• Datenkontrolle
• Migrationsfähigkeit
• langfristige Lesbarkeit
• regulatorische Sicherheit

Der EU Data Act zeigt deutlich:
Auch der Gesetzgeber erkennt die Relevanz von Wechselrechten und Datenportabilität an.

Fazit

Eine lokal installierte ERP-Lösung mit offener Datenbanktechnologie und definierten Migrationsschnittstellen kann eine tragfähige SaaS-Exit-Strategie darstellen – insbesondere im Lichte der aktuellen Gesetzgebung.

Der EU Data Act schafft das Recht auf Wechsel.
Die DSGVO stärkt das Recht auf Datenübertragbarkeit.
Doch erst eine klare Systemarchitektur – mit Single Source of Truth und reproduzierbaren Migrationsprozessen – macht diese Rechte operativ nutzbar.

SaaS ist kein Risiko per se.
Ungeplante Abhängigkeit hingegen schon.

Unternehmerische Souveränität bedeutet heute:
Nicht nur nutzen zu können –
sondern auch jederzeit wechseln zu können.