Vendor Lock-in bei Work-Management-Software und der Data Act

Vendor Lock-in in Work-Management-Tools: was der EU Data Act beim Anbieterwechsel sichert, was offen bleibt und was Sie vor dem Vertrag fragen sollten.

Daniela Brönner, Marketing-Spezialistin bei rready

Daniela Brönner

Daniela Brönner

Daniela Brönner

Marketing Specialist

Marketing Specialist

Marketing Specialist

Wenn ein Work-Management-Tool über Jahre im Einsatz ist, prägt es die Organisation. Abläufe, Berechtigungen und Routinen richten sich danach aus. Neue Kolleg:innen lernen den Umgang damit schon in ihrer ersten Woche. So wird es zu einem selbstverständlichen Teil des Arbeitsalltags. Solange die Bedingungen stimmen, denkt kaum jemand über einen Wechsel nach.

Bis sich die Bedingungen ändern. Der Anbieter wird übernommen und stellt das Lizenzmodell um. Bei der nächsten Verlängerung steigt der Preis deutlich. Oder die Version, die Sie selbst betreiben, wird eingestellt. Erst dann stellt sich die Frage, wie realistisch ein Wechsel überhaupt wäre. Die Antwort ist oft ernüchternd: Er würde Monate dauern, Budget für andere Projekte aufbrauchen und den laufenden Betrieb beeinträchtigen. Damit fehlt in der Verhandlung mit dem Anbieter das stärkste Argument. Die glaubwürdige Möglichkeit, zu gehen.

Genau diese Abhängigkeit nennt man Vendor Lock-in, und sie ist keine Ausnahme. Laut dieser Umfrage, nennen 59 Prozent der Unternehmen Lock-in-Effekte als größtes Hindernis für einen Anbieterwechsel.

Der EU Data Act soll solche Abhängigkeiten verringern. Seit dem 12. September 2025 gelten dessen Vorgaben zu Wechselfristen, Datenexport und Unterstützung beim Umzug. Ab dem 12. Januar 2027 dürfen Anbieter zusätzlich keine Wechselgebühren mehr erheben.

Für IT-Verantwortliche kann daraus ein falsches Sicherheits-Gefühl entstehen. Denn ein geregelter Ausstieg bedeutet noch keinen einfachen Wechsel. Entscheidend ist, welche Daten, Einstellungen und Abläufe sich übertragen lassen – und was das Team im neuen Tool neu aufbauen muss. Das prüfen die wenigsten, bevor sie kündigen.

Für Unternehmen, die zum Beispiel Jira oder Confluence Data Center nutzen, wird sie besonders konkret, denn beide Produkte erreichen am 28. März 2029 ihr angekündigtes Lebensende. Damit steht die Entscheidung an, wohin die Reise geht, und was sich mitnehmen lässt.

Ob in die Atlassian Cloud, zu einem anderen Anbieter oder zu einer anderen Lösung auf eigenen Servern: Jeder dieser Wege bringt eigene Herausforderungen mit sich. Was den Wechsel bei Work-Management-Tools aufwendig macht, wo der Data Act hilft und mit welchen sieben Fragen Sie den Aufwand vor Vertragsabschluss abschätzen können, lesen Sie im Folgenden.

Key takeaways

  1. Der eigentliche Lock-in in Work-Management-Tools steckt in Abläufen, Berechtigungen und Integrationen

    Tickets und Seiten lassen sich meist exportieren. Schwer mitzunehmen sind Workflows, Automationen, Berechtigungen, Apps und das Wissen Ihres Teams.


  2. Der EU Data Act gilt für SaaS und sichert den Export von Daten und Konfiguration

    Seit September 2025 gelten höchstens zwei Monate Kündigungsfrist und 30 Tage Übergang, ab Januar 2027 fallen die Wechselgebühren weg. Dazu können auch Einstellungen und Zugriffsrechte gehören.


  3. Ein selbst betriebenes Data Center schützt der Data Act nicht

    Der Schutz beginnt erst mit dem Wechsel in eine SaaS, und auch dann nicht vollständig. Klären Sie schon vor Vertragsabschluss, wie ein späterer Wechsel zu einem anderen Anbieter möglich ist.


  4. Ihre Konfiguration muss im neuen Tool nicht automatisch funktionieren

    Bei Infrastruktur-Diensten verlangt der Data Act Massnahmen, die eine vergleichbare Funktionalität nach dem Wechsel ermöglichen sollen. Für SaaS gibt es diese Vorgabe nicht. Den nötigen Wiederaufbau im neuen Tool müssen Sie deshalb selbst einplanen.


  5. Wichtig ist, vorher zu wissen, was ein Ausstieg kostet

    Sieben Fragen machen den Aufwand vor dem Vertragsabschluss sichtbar.

Was ist Vendor Lock-in?

Vendor Lock-in (auch Anbieterbindung oder Lock-in-Effekt) ist eine Abhängigkeit von einem Anbieter, die einen Wechsel so teuer, riskant oder aufwendig macht, dass er kaum noch infrage kommt. Die Ursachen können technisch, vertraglich oder wirtschaftlich sein: proprietäre Formate und Schnittstellen, lange Vertragslaufzeiten oder Investitionen, die bei einem Wechsel verloren gehen.

Wie teuer eingeschränkte Wechselmöglichkeiten werden können, zeigt eine Studie von Asterès im Auftrag des französischen IT-Anwenderverbands Cigref. Die 54 befragten IT-Verantwortlichen berichteten von durchschnittlichen Preissteigerungen für Cloud- und Softwaredienste von 8,7 Prozent pro Jahr in den vergangenen drei Jahren. Für die kommenden fünf Jahre erwarten sie jährlich 12 Prozent. Die Studie nennt hohe Wechselkosten und fehlende Alternativen als wesentliche Gründe dafür, dass Anbieter solche Erhöhungen durchsetzen können.

Auf europäische Unternehmen und Verwaltungen hochgerechnet, könnten diese Preissteigerungen im Zeitraum 2026 bis 2030 durchschnittlich 140 Milliarden Euro Mehrkosten pro Jahr verursachen. Das ist eine Modellrechnung unter bestimmten Annahmen, keine bereits feststehende Entwicklung. Sie verdeutlicht aber, was auf dem Spiel steht: Wer kaum wechseln kann, hat wenig Spielraum, höhere Preise abzuwehren.

Bei Cloud-Infrastruktur betrifft der Lock-in etwa die Frage, ob sich Server und Anwendungen zu einem anderen Anbieter übertragen lassen. Hier setzt der Data Act mit Vorgaben zur Funktionsäquivalenz an. Bei Work-Management-Software wie Jira, Confluence, monday.com oder Asana geht die Abhängigkeit weiter: Sie steckt auch in den Workflows, Berechtigungen und Integrationen, auf denen die tägliche Zusammenarbeit aufbaut.

Wo der Lock-in bei Work-Management-Tools wirklich steckt

Wer ein Tool für Projekt- und Wissensmanagement über Jahre nutzt, baut darin weit mehr auf als einen Datenbestand. Es entstehen Strukturen, Regeln und Arbeitsweisen, die sich nicht ohne Weiteres in ein anderes System übertragen lassen.

Dabei lassen sich fünf Ebenen unterscheiden. Je stärker sie an das Tool gebunden sind, desto mehr Aufwand verursacht ein Wechsel.


Ebene

Beispiel

Was beim Export passiert

1. Daten

Tickets, Seiten, Kommentare, Anhänge

Grundsätzlich oft exportierbar. Umfang, Vollständigkeit und Mengengrenzen müssen geprüft werden.

2. Struktur und Metadaten

Verlinkungen, Änderungshistorie, Autor:innen, Seitenberechtigungen

Ein Export kann diese Informationen enthalten. Ob das Zielsystem sie richtig zuordnet, ist eine andere Frage.

3. Konfiguration

Workflows, Automationen, Custom Fields, Berechtigungsschemata

Selbst exportierbare Einstellungen lassen sich im neuen Tool häufig nicht direkt ausführen.

4. Ökosystem

Marketplace-Apps, Integrationen, Webhooks

Die Übertragung hängt zusätzlich von Drittanbietern, Schnittstellen und verfügbaren Migrationswegen ab.

5. Wissen im Team

Abfragesprachen, Admin-Routinen, eingespielte Abläufe

Erfahrungswissen lässt sich nicht per Datei übertragen. Es muss dokumentiert und an das neue Tool angepasst werden.

Wie unterschiedlich diese Hürden aussehen können, zeigen Atlassian und Slack.

Atlassian: Jira Cloud unterstützt den CSV-Export von bis zu 10.000 Vorgängen auf einmal. Das erleichtert die Übertragung von Ticketdaten, ersetzt aber keine vollständige Migration. Schon beim Wechsel von Jira Server oder Data Center in die eigene Cloud bleiben Lücken: Der Jira Cloud Migration Assistant übernimmt beispielsweise keine globalen Berechtigungen und bestimmte Workflow-Eigenschaften und Trigger. Für viele App-Daten muss der jeweilige Hersteller einen eigenen Migrationsweg bereitstellen. Dashboards und projektübergreifende Filter werden dagegen inzwischen unterstützt. Wie viel Konfiguration in einer gewachsenen Instanz stecken kann, zeigt unser Beitrag über Jira als Betriebssystem.

Slack: Bei Slack hat Salesforce 2025 die API-Bedingungen verschärft. Drittanbieter dürfen Daten seitdem weder in großen Mengen exportieren noch dauerhaft speichern oder für Sprachmodelle verwenden. Das Beispiel zeigt eine weitere Abhängigkeit: Welche Funktionen angebundene Tools anbieten können, hängt auch von den Zugriffs- und Nutzungsregeln der Plattform ab.

Beide Beispiele verdeutlichen: Ein Datenexport allein sichert noch keinen funktionierenden Wechsel. Eine Datei kann die Tickets enthalten, ohne die Freigaberegeln mitzuliefern, nach denen sie bearbeitet werden. Und selbst eine exportierte Automation erklärt nicht, warum sie an einem bestimmten Feld hängt oder welche Ausnahme sie abbildet. Dieses Wissen steckt oft bei den Mitarbeitenden, die täglich mit dem Tool arbeiten. Es muss deshalb ebenso Teil der Migrationsplanung sein wie Daten und Konfiguration.

Was der EU Data Act beim Anbieterwechsel regelt

Seit dem 12. September 2025 regelt der EU Data Act, wie Kund:innen in der EU zwischen erfassten Cloud-Diensten wechseln oder ihre Daten auf eigene Server übertragen können. Dazu zählt auch Software, die Sie als Dienst beziehen und etwa im Browser nutzen: Software as a Service, kurz SaaS. Die Regeln gelten unabhängig von der Unternehmensgrösse und auch für bestehende Verträge.

Für den Anbieterwechsel sind vor allem vier Vorgaben wichtig:

  • Kündigungsfrist: Zwischen Ihrer Mitteilung, dass Sie wechseln möchten, und dem Beginn des Wechselprozesses dürfen höchstens zwei Monate liegen. Das ist nicht gleichbedeutend mit einem kostenlosen Ausstieg aus jedem laufenden Vertrag.

  • Übergangszeitraum: Der eigentliche Wechsel soll grundsätzlich innerhalb von 30 Kalendertagen erfolgen. Ist das technisch nicht möglich, muss der Anbieter dies innerhalb von 14 Arbeitstagen nach Ihrer Wechselmitteilung begründen. Er kann dann einen alternativen Übergangszeitraum von höchstens sieben Monaten vorsehen. Sie selbst dürfen den Zeitraum einmal verlängern.

  • Datenabruf: Nach dem Übergangszeitraum müssen Ihre Daten noch mindestens 30 Kalendertage abrufbar sein.

  • Vertragsinhalt: Der Vertrag muss aufführen, welche Daten und digitalen Vermögenswerte übertragbar sind und welche Kategorien interner Daten zum Schutz von Geschäftsgeheimnissen ausgenommen werden. Solche Ausnahmen dürfen den Wechsel nicht behindern oder verzögern.

Hinzu kommen die Gebühren: Bis zum 11. Januar 2027 dürfen Anbieter für den Wechsel höchstens die unmittelbar damit verbundenen Kosten berechnen. Ab dem 12. Januar 2027 entfallen diese Wechselentgelte grundsätzlich. Normale Nutzungsgebühren und mögliche Entschädigungen bei vorzeitiger Vertragsbeendigung sind davon zu unterscheiden.

Leicht übersehen wird, dass der Data Act mehr abdeckt als Tickets und Seiten. Auch Metadaten zu Einstellungen, Sicherheit und Zugriffsrechten können dazugehören. Damit ist ein Teil Ihrer Konfiguration grundsätzlich berücksichtigt. Welche digitalen Vermögenswerte Sie mitnehmen dürfen, hängt allerdings auch von Ihren Nutzungsrechten ab. Geschützte Technologie des Anbieters wird dadurch nicht zu Ihrem Eigentum.

Am Beispiel Atlassian: Für Data Center gilt das alles noch nicht.

Data Center ist die Variante von Jira und Confluence, die Unternehmen selbst betreiben. Wer eine Softwarelizenz erwirbt und die Installation selbst betreibt, bezieht damit allein noch keinen Datenverarbeitungsdienst im Sinne des Data Act. Entscheidend ist das tatsächliche Bereitstellungsmodell. Bei einer durch einen Dienstleister betriebenen Installation muss deshalb im Einzelfall geprüft werden, ob sie unter die Definition fällt.

Für die Wahl des Nachfolgesystems ist das besonders relevant: Jira und Confluence Data Center erreichen am 28. März 2029 ihr angekündigtes Lebensende. Wer deshalb einen Cloud-Dienst in Betracht zieht, sollte dessen spätere Ausstiegsmöglichkeiten schon vor Vertragsabschluss prüfen. Die Wechselregeln können bei diesem neuen Dienst greifen, lösen aber nicht automatisch die Migration aus der bisherigen Installation.

Schweizer Kund:innen können sich nicht auf den Data Act berufen.

Wechselregeln richten sich an Anbieter, die entsprechende Dienste für Kund:innen in der EU erbringen – unabhängig davon, wo der Anbieter sitzt. Eine rein schweizerische Vertrags- und Nutzungssituation wird davon nicht automatisch erfasst. Umgekehrt kann auch ein Schweizer Anbieter gegenüber Kund:innen in der EU verpflichtet sein. Bei Unternehmensgruppen mit Gesellschaften in beiden Rechtsräumen sollten deshalb Vertragspartner, Leistungsbezug und vertraglich zugesicherte Ausstiegsrechte gemeinsam geprüft werden.

Was der Data Act nicht löst

der Hauptplattform abgedeckt. Prüfen Sie für jede geschäftskritische Erweiterung, wer den Export ermöglicht und welcher Ersatz im Zielsystem nötig ist.

Wissen im Team: Erfahrung lässt sich nicht per Datei übertragen

Abfragesprachen, Admin-Routinen und eingespielte Abläufe sind Teil des Arbeitsalltags. Auch wenn ein Export die technische Konfiguration enthält, erklärt er nicht unbedingt, warum eine Regel existiert oder welche Ausnahme sie abbildet. Dieses Wissen muss dokumentiert und an das neue Tool angepasst werden.

Auch beim Vertrag bleiben wichtige Fragen offen.

Ein vorzeitiger Ausstieg kann weiterhin kosten.

Verträge mit fester Laufzeit dürfen verhältnismäßige Entschädigungen für eine vorzeitige Beendung weiterhin vorsehen. Auch die Lizenzpreise bei einer Verlängerung werden durch die Wechselregeln nicht gedeckelt

Für individuell entwickelte Dienste gelten Ausnahmen.

Die Befreiung betrifft Dienste, deren wesentliche Funktionen überwiegend für einzelne Kund:innen entwickelt wurden und die nicht in grossem Massstab über einen Servicekatalog angeboten werden. Eine übliche Anpassung der Standardsoftware reicht dafür nicht ohne Weiteres aus. Unter anderem, können Wechselentgelte auch nach Januar 2027 zulässig bleiben. Der Anbieter muss vor Vertragsabschluss über die einschlägigen Ausnahmen informieren.

Weitere Änderungen an den Wechselregeln sind Gegenstand des Digital-Omnibus-Vorschlags der EU-Kommission. Ein Vorschlag ersetzt jedoch keine geltende Regelung. Für Ihren Vertrag ist die jeweils gültige Rechtslage entscheidend.

Ein gewisser Lock-in ist allerdings nicht automatisch ein Nachteil. Ein Tool, in dem Tickets, Dokumentation und Automationen gut zusammenarbeiten, spart Schnittstellen und Wartung. Ein passend eingerichtetes System bleibt auch deshalb attraktiv, weil es Ihre Prozesse unterstützt. Entscheidend ist, dass Sie diese Bindung bewusst eingehen und den Aufwand eines späteren Wechsels kennen.

Für Finanzunternehmen im Anwendungsbereich der DORA-Verordnung kommen weitere Pflichten hinzu. Bei IKT-Diensten, die kritische oder wichtige Funktionen unterstützen, müssen Ausstiegspläne dokumentiert, ausreichend getestet und regelmässig überprüft werden. Alternative Lösungen und Übergangspläne sollen eine sichere und vollständige Übertragung zu anderen Anbietern oder zurück in eigene Systeme ermöglichen. Für eine solche Cloud-Exit-Strategie können die sieben Fragen unten als Grundlage dienen.

Exit-Check: Was Sie vor Vertragsabschluss fragen sollten

Wo der Data Act greift, muss der Vertrag die übertragbaren Daten und digitalen Vermögenswerte benennen. Auch ausserhalb seines Anwendungsbereichs lohnt es sich, diese Angaben vertraglich einzufordern.

Mit den folgenden sieben Fragen erkennen Sie, wo Aufwand und Kosten eines späteren Ausstiegs entstehen. Stellen Sie sie Ihrem heutigen Anbieter ebenso wie dem künftigen.

  1. Welche Daten, Metadaten und Historien enthält der Export, und in welchem Format? Lassen Sie sich die Liste zeigen. Achten Sie neben den Tickets auf Änderungshistorien, Verlinkungen, Anhänge und Berechtigungen.

  2. Welche Grenzen gelten für Exporte und APIs? Mengenlimits, Tageskontingente und Drosselungen bestimmen mit, wie lange eine vollständige Übertragung dauert. Fragen Sie auch, ob der Anbieter für eine Migration höhere Kontingente bereitstellt.

  3. Lassen sich Workflows, Automationen und Berechtigungen exportieren? Fragen Sie anschliessend, ob das Zielsystem diese Konfiguration importieren kann oder ob sie nur als Dokumentation für einen Neuaufbau dient.

  4. Welche Prozesse hängen von Drittanbieter-Apps ab? Klären Sie für jede wichtige Erweiterung den Vertrag, den Datenexport und den Ersatz im neuen Tool.

  5. Gibt es einen Source Code Escrow, und was löst ihn aus? Er sichert Sie für den Fall ab, dass der Anbieter verkauft wird oder den Betrieb einstellt.

  6. Welche Laufzeiten, Fristen und Kosten gelten beim Ausstieg und bei der Verlängerung? Unterscheiden Sie Wechselentgelte, laufende Nutzungsgebühren und mögliche Entschädigungen bei vorzeitiger Beendigung. Prüfen Sie ausserdem Preisänderungsklauseln und die Dauer einer Preisgarantie.

  7. Wann wurde der gesamte Wechsel zuletzt getestet? Ein Probeexport zeigt, was Sie herausbekommen. Erst ein anschliessender Import in eine Testumgebung des Zielsystems zeigt, was dort ankommt und funktioniert. Prüfen Sie zusätzlich Konfiguration, Integrationen und die wichtigsten Arbeitsabläufe.

So schätzen Sie den Aufwand ab

Erstellen Sie zunächst eine Liste aller Workflows, Automationen, Apps und Integrationen, die das neue System übernehmen oder ersetzen muss. Ordnen Sie jeden Punkt einer von drei Möglichkeiten zu: direkt übertragbar, anzupassen oder neu aufzubauen. Schätzen Sie gemeinsam mit dem Admin- und Projektteam den Aufwand in Personentagen. Ergänzen Sie Datenbereinigung, Tests, Schulungen und die nötige Projektkoordination.

Multiplizieren Sie die Personentage mit den jeweiligen internen oder externen Tagessätzen. Dazu kommen mögliche Kosten für Migrationstools, Beratung und den Parallelbetrieb beider Systeme. So erhalten Sie eine erste Bandbreite für den Wechselaufwand und können Annahmen mit einem Testlauf überprüfen.

Vergleichen Sie diese Schätzung mit den Kosten eines Verbleibs und den anstehenden Veränderungen. Bei Jira und Confluence Data Center gehört dazu das angekündigte Lebensende am 28. März 2029, nach dem die betroffenen Produkte grundsätzlich nur noch im Lesemodus verfügbar sind. Auch der Wechsel in die Atlassian Cloud ist ein Migrationsprojekt, dessen Konfiguration und Apps gesondert geprüft werden müssen. Mehr dazu erfahren Sie in unserem Beitrag zum Ende von Atlassian Data Center.

Wo sovara steht

Offene Formate, dokumentierte Schnittstellen und nachvollziehbare Vertragsbedingungen erleichtern die Prüfung eines späteren Ausstiegs. An diesen Kriterien muss sich auch sovara messen lassen, unsere europäische Plattform für Projekt- und Wissensarbeit als Alternative zu Jira und Confluence. Wer einen Exit-Check empfiehlt, sollte die Fragen auch selbst beantworten.

  1. Export: Inhalte lassen sich über die REST-API als JSON und Seiten als Markdown exportieren. Verlinkungen zwischen Tickets sind enthalten.

  2. Grenzen: Der gesamte Workspace lässt sich über die REST-API oder die Kommandozeile exportieren. Für CSV-Massenexporte sind bis zu 10.000 Zeilen und 20 Exporte pro Tag vorgesehen.

  3. Konfiguration: Workflows, Felder und Automationen lassen sich als JSON exportieren und in eine andere sovara-Instanz importieren. Die lesbare Konfiguration kann als Grundlage für den Neuaufbau in einem anderen Tool dienen. Direkt ausführen kann ein anderes System sie dadurch noch nicht.

  4. Apps: Funktionen wie skriptbasierte Automationen und Zeiterfassung sind in sovara integriert. Je nach Einsatzfall reduziert das die Zahl zusätzlicher Apps und Verträge. Weitere Systeme lassen sich über REST-API und Webhooks anbinden.

  5. Escrow: Der Quellcode wird bei einem unabhängigen Dritten hinterlegt. Wann Kund:innen Zugriff erhalten und welche Nutzungsrechte damit verbunden sind, regelt die Escrow-Vereinbarung.

  6. Vertrag: Die Vorlage sieht eine unternehmensweite Lizenz unabhängig von der Zahl der Nutzer:innen und eine dreijährige Preisgarantie vor. Für erfasste Dienste gegenüber Kund:innen in der EU gelten die gesetzlichen Wechselregeln auch bei einem Schweizer Anbieter. Welche Ausstiegsrechte darüber hinaus vertraglich zugesichert sind, muss das jeweilige Angebot ausweisen.

  7. Test: Kund:innen können den Export selbst anstossen. Dabei gelten die bestätigten Kontingente und technischen Grenzen aus Antwort 2. Für einen vollständigen Exit-Test muss zusätzlich der Import in das gewünschte Zielsystem geprüft werden.

Offene Formate und zugängliche Konfigurationen machen einen späteren Wechsel besser nachvollziehbar. Eine API allein beseitigt die Bindung an ein System aber ebenso wenig wie ein Escrow. Entscheidend ist, welche Bestandteile tatsächlich übertragbar sind und wie viel Wiederaufbau im Zielsystem bleibt. Die bestätigten Antworten sollen genau das sichtbar machen.

Auch für den Weg zu sovara sollte der Leistungsumfang vor Projektbeginn klar sein. Unsere Migrationsgarantie sieht vor, ein Standard-Jira-Setup mit Tickets, Workflows und Automationen zu übernehmen.

Für Plugins und eigenen Code ist eine gesonderte Prüfung vorgesehen. Dabei wird je App geklärt, ob sovara die Funktion bereits abdeckt, ob eine Anpassung nötig ist oder ob sie entfallen kann. ScriptRunner-Automationen und Felder aus Apps können Gegenstand begleiteter Projektarbeit sein. Einen Marketplace im Umfang von Atlassian bietet sovara nicht. Besonders spezialisierte Erweiterungen müssen deshalb einzeln bewertet werden.

Wie sich sovara im Detail von Jira und Confluence unterscheidet, zeigt unser Produktvergleich.

Fazit

Lock-in wird spürbar, wenn Preise steigen oder ein Wechsel ansteht. Der Data Act stärkt die Ausstiegsmöglichkeiten aus erfassten Cloud-Diensten. Er ersetzt jedoch weder die technische Prüfung des Zielsystems noch den Wiederaufbau Ihrer Arbeitsumgebung.

Für Unternehmen mit Jira oder Confluence Data Center macht das angekündigte Lebensende 2029 diese Prüfung besonders dringlich. Nutzen Sie die sieben Fragen, um beim bisherigen Anbieter ebenso wie beim künftigen zu klären, was sich übertragen lässt und welchen Aufwand der Rest verursacht. Je früher Sie das testen, desto belastbarer wird Ihre Entscheidung.

Wenn Sie den Wechsel bereits konkret planen, hilft unser Beitrag zur Migration auf eine souveräne Lösung. Wie rready Sitz, Hosting und Export einordnet, finden Sie im Sovereignty Trust Center.

FAQs

Was ist der Lock-in-Effekt?

Der Lock-in-Effekt beschreibt eine Abhängigkeit von einem Anbieter, bei der ein Wechsel so aufwendig, riskant oder teuer wird, dass er kaum noch infrage kommt. Bei Work-Management-Software entsteht diese Bindung auch durch Workflows, Automationen, Apps und eingespielte Arbeitsweisen.

Gilt der Data Act auch für SaaS-Tools?

Ja, sofern der Dienst die gesetzliche Definition erfüllt. SaaS gehört ausdrücklich zu den erfassten Bereitstellungsmodellen. Für zeitlich begrenzte Test- und Evaluierungsversionen bestehen Ausnahmen; bestimmte individuell entwickelte Dienste sind von einzelnen Pflichten ausgenommen (Art. 31).

Gilt der Data Act für Jira Data Center?

Eine reine Softwarelizenz für eine selbst betriebene Jira-Installation fällt grundsätzlich nicht unter die Wechselregeln für Datenverarbeitungsdienste. Bei betreuten oder gehosteten Installationen hängt die Einordnung vom tatsächlichen Dienst ab. Massgeblich ist Artikel 2 Nr. 8, nicht allein die Produktbezeichnung.

Ab wann sind Wechselgebühren verboten?

Für die erfassten Dienste grundsätzlich ab dem 12. Januar 2027 (Art. 29 Abs. 1). Bis dahin dürfen Anbieter nur unmittelbar mit dem Wechsel verbundene Kosten berechnen. Normale Nutzungsgebühren und mögliche verhältnismässige Entschädigungen für eine vorzeitige Vertragsbeendigung sind davon zu unterscheiden. Für bestimmte individuell entwickelte Dienste gelten Ausnahmen.

Gilt der Data Act in der Schweiz?

Die Wechselregeln gelten für Anbieter, die erfasste Dienste für Kund:innen in der EU erbringen – auch wenn der Anbieter in der Schweiz sitzt. Eine rein schweizerische Vertrags- und Nutzungssituation wird nicht automatisch erfasst. Vergleichbare Ausstiegsrechte können aber vertraglich vereinbart werden.

Kann ich meine Jira-Daten vollständig exportieren?

Das hängt von Exportweg, Datenart und verwendeten Apps ab. Ein Jira Export als CSV umfasst in Jira Cloud bis zu 10.000 Vorgänge auf einmal. APIs und weitere Exportmöglichkeiten können zusätzliche Anforderungen abdecken. Eine vollständige Übertragung in ein anderes Tool ergibt sich daraus noch nicht: Historien, Verknüpfungen, Konfiguration und App-Daten müssen gesondert geprüft werden. Für Confluence finden Sie Hinweise in unserem Beitrag zur Confluence-Alternative.

Was bringt ein Source Code Escrow?

Bei einem Source Code Escrow hinterlegt der Anbieter den Quellcode seiner Software bei einem unabhängigen Treuhänder. Tritt ein vertraglich vereinbarter Fall ein, können Kund:innen Zugriff und die vereinbarten Nutzungsrechte erhalten. Ob damit ein Weiterbetrieb möglich ist, hängt unter anderem von Vollständigkeit, Aktualität, Dokumentation und benötigten Drittlizenzen ab. Ein Escrow ersetzt keinen Datenexport und keine Migrationsplanung.

Ist Open-Source-Software automatisch frei von Lock-in?

Nein. Eine offene Lizenz und zugänglicher Quellcode können die Abhängigkeit vom Fortbestehen eines einzelnen Herstellers verringern. Workflows, Erweiterungen, Datenmodelle und das Wissen im Team bleiben dennoch an die jeweilige Lösung gebunden. Auch bei Open Source muss ein Wechsel geplant und getestet werden.