Jira Data Center endet am 28. März 2029

Für viele Unternehmen in Deutschland und Europa ist die Jira-Cloud-Frage gerade keine normale Modernisierungsentscheidung mehr. Sie wird zu einer Fristentscheidung. Atlassian schreibt auf seiner Cloud-Transformationsseite, worauf es hinausläuft: Wer Atlassian-Produkte weiter nutzen will, soll in die Cloud gehen. Mehrjährige Data-Center-Verlängerungen über den 28. März 2029 hinaus sind nur noch by exception vorgesehen.

Genau damit kippt die Debatte. Es geht nicht mehr nur um Funktionsvergleich, Komfort oder Lizenzlogik. Für viele Organisationen entsteht ein echter Migrationsdruck in ein Betriebsmodell, das aus deutscher und europäischer Sicht heikle Fragen zusammenzieht: US-Anbieterstruktur, nur teilweise wirksame Data Residency, App-Daten außerhalb des eigentlichen Atlassian-Kerns, begrenzte Exportpfade und ein nativer Backup- und Restore-Ansatz, der eher nach kurzfristiger Wiederherstellung als nach einem echten, kundenkontrollierten Backup aussieht.

Das Problem ist deshalb nicht, dass Jira Cloud technisch unbrauchbar wäre. Das Problem ist, dass viele Unternehmen bis März 2029 in ein Modell gedrückt werden, das sie aus Compliance-, Betriebs- und Notfallperspektive erst sauber neu bewerten müssen. Für deutsche und europäische Kunden ist das keine Randfrage, sondern eine Architekturentscheidung mit Rechtsraum-, Souveränitäts- und Wiederanlauf-Folgen.

Der Termin 28. März 2029 macht aus einer Cloud-Option einen strategischen Zwang

Solange Data Center als dauerhaft tragfähiger Zielzustand galt, konnten Unternehmen nüchtern entscheiden, ob sie ihre Jira-Landschaft lieber selbst betreiben oder als SaaS konsumieren wollen. Mit der jetzt offen kommunizierten Richtung verändert sich diese Lage. Atlassian empfiehlt die Cloud als Zukunftspfad. Wer nicht rechtzeitig vorbereitet ist, läuft Gefahr, später nicht in Ruhe zu migrieren, sondern unter Zeitdruck.

Gerade in Deutschland und Europa ist das brisant, weil Jira in vielen Unternehmen nicht bloß ein Ticketsystem ist. In der Praxis hängen daran Serviceprozesse, Incident-Kommunikation, Audit-Spuren, Berechtigungslogiken, Governance-Dokumentation, Dienstleistersteuerung, interne Sicherheitsbewertung und oft auch regulatorisch relevante Abstimmungs- und Nachweiswege. Dazu kommen Marketplace-Apps, Spezialfelder, Assets-Bezüge, Genehmigungslogiken und Integrationen, die über Jahre gewachsen sind und sich nicht einfach per Knopfdruck in ein neues Modell übertragen lassen.

Wer in so einer Landschaft bis März 2029 migrieren muss, braucht deshalb viel mehr als einen technischen Umzugsplan. Er braucht eine belastbare Antwort auf drei Fragen gleichzeitig. Erstens: Welche Daten und Prozesse dürfen überhaupt in das Zielmodell? Zweitens: Welche Kontrollverluste entstehen beim Wechsel in eine US-geprägte SaaS-Struktur? Drittens: Wie sieht ein realistischer Rückfallpfad aus, wenn etwas schiefgeht oder wenn später regulatorische, sicherheitstechnische oder vertragliche Gründe gegen den gewählten Kurs sprechen?

Genau hier beginnt das eigentliche Problem für europäische Kunden. Die Migrationsfrist drückt nicht in ein neutrales Zielsystem, sondern in ein Modell, das man erst politisch, rechtlich, organisatorisch und technisch sauber entwirren muss.

Data Residency hilft, aber sie löst das Deutschland- und Europa-Problem nicht

An dieser Stelle wird in Projekten oft zu schnell argumentiert: Die Daten liegen doch künftig in Deutschland oder wenigstens in der EU, also sei das Problem im Wesentlichen gelöst. Das ist zu kurz. Atlassian bietet Data Residency an, und das ist für viele Datenklassen zweifellos besser als ein völlig ortsblinder Betrieb. Aber Data Residency beantwortet eben nur einen Teil der Frage, nämlich wo bestimmte In-Scope-Daten gehostet werden. Sie beantwortet nicht automatisch, welchem Anbieter- und Rechtsraum das Gesamtmodell unterliegt, welche Daten außerhalb dieses Scopes verarbeitet werden und wie Drittanbieter-Apps tatsächlich arbeiten.

Gerade für deutsche und europäische Kunden ist diese Differenz entscheidend. Denn in der Realität geht es selten nur um Standard-Issues. Es geht um Anhänge, Kommentare, Suchdaten, Konfigurationsdaten, Automationen, Service-Management-Objekte, App-Daten, DevOps-Anbindungen, Analytics- oder KI-nahe Zusatzpfade und um alles, was in einer gewachsenen Atlassian-Umgebung sonst noch mitschwingt. Atlassian selbst unterscheidet an mehreren Stellen zwischen dem Kern der eigenen Plattform und Daten oder Funktionen, die bei Drittanbietern oder in anderen Produktpfaden liegen.

Damit wird aus dem Satz „unsere Daten liegen in Frankfurt“ schnell eine Scheinsicherheit. Die saubere Frage lautet nicht, ob es irgendeine EU-Region gibt. Die saubere Frage lautet: Welche konkreten Daten liegen wo, unter wessen Betriebsverantwortung, mit welchen Exportrechten, mit welchen Löschpfaden und mit welcher Prüfbarkeit? Solange diese Matrix nicht sauber auf dem Tisch liegt, ist die Data-Residency-Aussage für viele europäische Compliance- und Sicherheitsanforderungen nur ein Teilargument.

Hinzu kommt der US-Rechtsraum. Der CLOUD Act wird oft entweder alarmistisch überhöht oder verharmlosend wegmoderiert. Beides hilft Unternehmen nicht. AWS erklärt selbst, dass der CLOUD Act für Anbieter mit US-Präsenz grundsätzlich relevant sein kann, auch wenn Daten außerhalb der USA gespeichert sind. Für viele deutsche und europäische Organisationen ist deshalb nicht die plakative Frage entscheidend, ob morgen jemand massenhaft Daten abzieht. Entscheidend ist, ob sie fremde Zugriffe technisch ausschließen, verlässlich erkennen oder gegenüber Prüfern belastbar begrenzen können. Genau dort bleibt im normalen SaaS-Modell eine strukturelle Unsicherheit bestehen.

Gleichzeitig muss man fair ergänzen, dass es derzeit mit dem EU-U.S. Data Privacy Framework einen geltenden Angemessenheitsbeschluss für die USA gibt. Das entlastet die aktuelle Rechtslage gegenüber früheren Phasen ohne tragfähigen Rahmen. Für strategische Entscheidungen taugt das aber nur begrenzt als Ruheanker. Denn aus europäischer Sicht muss realistisch einkalkuliert werden, dass auch dieser Beschluss mit der nächsten erfolgreichen Schrems-Klage wieder kippen kann. Genau deshalb löst ein momentaner Angemessenheitsbeschluss die grundlegende Souveränitäts- und Providerfrage nicht dauerhaft.

Was Atlassian real anbietet: Jira Cloud mit Customer Managed Keys

Hier lohnt sich eine saubere Trennung zwischen echter Risikoreduktion und überzogenen Erwartungen. Atlassian bietet für Jira Cloud inzwischen eine stärkere Variante des Standardbetriebs an, in der Customer Managed Keys (CMK) mit EU-Datenresidenz kombiniert werden können. Dabei werden ruhende Daten mit Schlüsseln geschützt, die im kundeneigenen AWS KMS liegen.

Leisten kann dieses Modell eine spürbare Verbesserung im Bereich data at rest. Der Kunde erhält praktisch Einfluss darauf, ob ruhende Daten entschlüsselt werden können. Für Compliance, Risikomanagement und interne Schutzbewertungen ist das deutlich besser als ein Standard-SaaS-Modell, in dem auch die Schlüssel vollständig in der Anbieterlogik hängen. Gerade die Möglichkeit der Key-Revocation stärkt die eigene Kontrollposition und verbessert die Argumentation gegenüber Prüfern.

Nicht leisten kann dieses Modell aber den Ausschluss des CLOUD Act. Denn die Anwendung verarbeitet Daten weiterhin an mehreren Stellen im Klartext, etwa für Suche, Indexierung, Exporte, Support-Fälle oder API-bezogene Funktionen. Atlassian bleibt technisch in der Lage, Klartext zu erzeugen. Gleichzeitig bleibt Atlassian rechtlich ein adressierbarer Service Provider. Hinzu kommt, dass die Schlüssel zwar kundenseitig definiert sind, aber weiterhin innerhalb der AWS-Trust-Domäne liegen. Das ist sicherheitstechnisch besser, aber kein vollständiger Souveränitätsbruch mit dem bestehenden Modell.

Die faire Gesamtbewertung lautet deshalb: Jira Cloud mit CMK ist eine starke Option zur Risikominimierung und zur Verbesserung der Compliance-Position. Sie ist aber keine Lösung für Unternehmen, die einen CLOUD-Act-Zugriff vollständig ausschließen wollen. Genau dieser Unterschied muss in deutschen und europäischen Entscheidungsrunden klar benannt werden.

Warum selbst ein hypothetisches AWS-TEE-Modell den CLOUD Act nicht sauber ausschließt

Viele Sicherheitsverantwortliche denken an dieser Stelle einen Schritt weiter. Wenn schon normales SaaS mit CMK nicht reicht, könnte dann ein stark gehärtetes Modell helfen, etwa auf dediziertem Blech, containerisiert, mit Trusted Execution Environments, zusätzlichen Isolationsschichten und kundenseitigen Schlüsseln? Theoretisch ja, praktisch nur sehr begrenzt.

Ein solches Modell könnte technisch viel leisten. Wenn Jira in einer dedizierten AWS-Umgebung mit Enclave- oder TEE-artiger Architektur betrieben würde, wäre der Schutz gegenüber AWS, dem Rechenzentrum und klassischen Infrastruktur-Operatoren deutlich höher. Der Klartext wäre außerhalb der isolierten Ausführungsumgebung wesentlich schwerer oder gar nicht sichtbar. Zusammen mit CMK entstünde daraus ein klar stärkeres Modell als der normale SaaS-Betrieb.

Trotzdem würde auch dieses Szenario den CLOUD Act nicht sauber ausschließen. Der entscheidende Punkt ist nicht AWS, sondern Atlassian als Service Provider. Eine Anordnung würde sich rechtlich an Atlassian richten. Atlassian behält in einem SaaS-Modell die Kontrolle über den Software-Stack, über Updates und über die Definition der Attestation-Messwerte. Wenn Atlassian per legitimen Software-Update innerhalb der Enclave Klartext erzeugen und exportieren kann, dann wird der technische Schutz nicht gebrochen, sondern durch die Betreiberhoheit umgangen.

Genau deshalb ist ein solcher Ansatz in der Gesamtbewertung nur ein theoretisch starker, praktisch aber unvollständiger Weg. Er reduziert technische Risiken, vor allem gegenüber Infrastruktur und klassischen Operatorpfaden. Er löst aber nicht das Grundproblem, dass Atlassian selbst im Entscheidungs- und Kontrollpfad bleibt. Für ein wirtschaftlich tragfähiges Standard-SaaS-Modell ist dieses Szenario außerdem organisatorisch und kommerziell nur schwer realistisch.

Das native Backup in Jira Cloud bleibt trotzdem ein eigenes Enterprise-Problem

Selbst wenn man CMK oder hypothetische Härtungen positiv bewertet, bleibt noch eine zweite Schwachstelle bestehen: Backup, Export und Restore. Genau hier liegt einer der Punkte, die in vielen Migrationsprojekten zu spät ernst genommen werden. Auf dem Papier gibt es in Jira Cloud natürlich Backup- und Exportfunktionen. In der Praxis zeigen die Atlassian-Dokumente aber selbst, warum viele Teams das nicht als vollständiges Backup-Modell akzeptieren.

Die erste Schwäche ist der Inhalt. Atlassian nennt beim Jira-Cloud-Export ausdrücklich Daten und Funktionen, die nicht mit exportiert werden. Dazu gehören unter anderem Automation-Regeln, Third-party apps und App-Daten, Assets für Jira Service Management sowie Opsgenie-bezogene Inhalte in Jira Service Management. Schon dieser Punkt ist für viele europäische Unternehmen kritisch. Denn gerade in regulierten oder komplexen Umgebungen stecken wesentliche Betriebslogiken nicht nur im Jira-Kern, sondern in Automationen, Zusatz-Apps und Service-Management-Erweiterungen. Wenn genau diese Teile im nativen Export fehlen, dann entsteht kein vollständiges Sicherungsbild, sondern nur ein Teilabbild der Plattform.

Die zweite Schwäche ist die Betriebslogik. Wer Anhänge, Avatare oder Logos in das Backup aufnimmt, muss laut Atlassian 48 Stunden zwischen zwei Backups warten. Für kleine Umgebungen mag das verkraftbar sein. Für produktive Service- und Betriebsplattformen ist das aber bereits ein klarer Hinweis darauf, dass hier kein frei taktbarer, granularer Enterprise-Backup-Pfad vorliegt.

Die dritte Schwäche ist der Restore-Horizont. Atlassian dokumentiert ausdrücklich, dass der Backup Manager seit dem 22. Januar 2026 Restores nur noch aus Backups zulässt, die höchstens 30 Tage alt sind. Genau an dieser Stelle trifft der Einwand vieler Kunden ins Schwarze: Das ist nicht das, was viele Unternehmen unter einem echten Backup verstehen. Ein echtes Backup-Modell schafft kontrollierte, langfristig verfügbare, nachvollziehbare Wiederherstellungspunkte in einem Sicherungssystem, das nicht bloß an einen kurzen operativen Rückblick gekoppelt ist. Die native Atlassian-Logik wirkt dagegen deutlich stärker wie eine begrenzte Wiederherstellungs- oder Rollback-Funktion für frische Zustände.

Und genau deshalb ist auch der oft gehörte Satz richtig, dass Atlassians natives Backup aus Kundensicht eher wie ein Rollback-Mechanismus aussieht. Wenn der Export nicht alles enthält, wenn App-Daten und zentrale Betriebslogiken fehlen, wenn Restore nur für frische Backups möglich ist und wenn die Plattform kein kundenkontrolliertes Langzeit-Sicherungsmodell mit vollständiger Tiefenabdeckung mitliefert, dann bleibt eben kein klassisches Vollbackup übrig. Dann bleibt eine nützliche, aber begrenzte Wiederherstellungshilfe.

Kein Wunder also, dass sich die Community-Fragen seit Jahren wiederholen. Schon auf Reddit wird nicht nur über Features gesprochen, sondern sehr grundlegend gefragt, wie Teams überhaupt automatisierte Backups für Jira Cloud aufbauen sollen. Genau das ist das Signal. Wo Kunden zuerst nach eigener Backup-Automatisierung und nach Wiederherstellbarkeit gelöschter Inhalte fragen, ist das native Sicherungsmodell offenbar nicht überzeugend genug.

Was für deutsche und europäische Kunden realistisch übrig bleibt

Die Debatte wird erst dann belastbar, wenn sie nicht in Wunschbildern endet. Ein vollständiger Ausschluss des CLOUD Act ist im normalen Jira-Cloud-Modell auch mit CMK nicht erreichbar. Ein hypothetisch gehärtetes AWS-TEE-Modell wäre technisch stärker, würde aber an der Rolle Atlassians als adressierbarem Service Provider nichts Grundsätzliches ändern. Gleichzeitig wäre ein solches Modell als Standard-SaaS kaum realistisch.

Darum ist der interessanteste Perspektivpfad eher ein Intermediär-Modell, falls Atlassian selbst daran mitwirken würde. Denkbar wäre ein vertrauenswürdiger europäischer Betreiber mit klarer Rolle bei Schlüssel-, Betriebs- oder Schutzlogik, also nicht bloß als Hosting-Standort, sondern als echter Kontroll- und Vertrauensknoten. Das wäre kein einfacher Umbau, aber perspektivisch deutlich näher an einer tragfähigen europäischen Souveränitätslösung als reine Marketingformeln rund um Datenstandorte.

Parallel dazu gibt es pragmatische Wege, Jira weiter zu nutzen, ohne in die kritischsten Bereiche zu laufen. Unternehmen können hochsensible Inhalte aus Jira heraushalten, Datenklassen strikt trennen, besonders heikle Vorgänge in separaten Systemen fahren, App-Landschaften entschlacken und Jira bewusst nur für solche Prozesse einsetzen, deren Restrisiko auch im Cloud-Modell vertretbar bleibt. Das ist nicht so elegant wie ein vollständig souveränes Zielbild, aber oft realistischer als ein Alles-oder-nichts-Ansatz.

Genau deshalb sollte der europäische Blick auf Jira Cloud deutlich härter sein als viele Standard-Migrationsfolien vermuten lassen. Die Frage ist nicht, ob Atlassian Cloud moderne Funktionen, Skalierung und Innovationsgeschwindigkeit bietet. Das tut sie. Die entscheidende Frage ist, ob ein Unternehmen bis zum 28. März 2029 verantwortbar in dieses Modell migrieren kann, ohne dabei Souveränität, Nachweisbarkeit, Wiederanlauffähigkeit und Exit-Fähigkeit nur noch mit Zusatzkonstruktionen außerhalb des Standardprodukts absichern zu müssen.

Wer diese Diskussion in Deutschland und Europa sauber führen will, sollte deshalb mindestens diese Punkte vor einer Freigabe verbindlich festziehen:

• Welche Datenklassen und Prozessarten dürfen tatsächlich in Jira Cloud landen?
• Welche geschäftskritischen Logiken stecken heute in Automationen, Marketplace-Apps und JSM-Erweiterungen, die im nativen Export nicht sauber mitkommen?
• Reicht CMK für den eigenen Schutzbedarf aus, oder bleibt trotz ruhender Verschlüsselung eine unakzeptable Klartext- und Betreiberabhängigkeit bestehen?
• Wie sieht ein echter, getesteter Wiederanlaufpfad aus, der mehr kann als nur einen frischen 30-Tage-Restore?
• Gibt es für hochkritische Daten ein Scope-Modell außerhalb von Jira Cloud?
• Und falls Atlassian irgendwann kooperiert: Welche Form eines europäischen Intermediär-Modells wäre technisch, vertraglich und regulatorisch überhaupt tragfähig?

Das ist der Punkt, an dem die Debatte ehrlich wird. Für Kunden in Deutschland und Europa ist Jira Cloud bis 2029 nicht einfach das nächste Betriebsmodell. Es ist ein potenziell erzwungener Wechsel in ein System, bei dem Data Residency allein nicht reicht, CMK vor allem ruhende Risiken reduziert, hypothetische Enclave-Modelle den Providerzugriff nicht sauber neutralisieren und das native Backup-Modell nicht die Tiefe, Dauer und Vollständigkeit liefert, die viele Enterprise- und Regulierungsumgebungen erwarten.

Wer das Problem kleinredet, migriert womöglich rechtzeitig, aber nicht belastbar. Wer es sauber bewertet, gewinnt vielleicht keine einfache Story, dafür aber eine tragfähige Entscheidung.

Quellen

• Atlassian, Cloud transformation options
• Atlassian Support, Export data from Jira Cloud
• Atlassian Support, Understand data residency
• Atlassian Support, Data managed with encryption
• Atlassian, Customer-managed keys (CMK)
• AWS, Clarifying Lawful Overseas Use of Data (CLOUD) Act
• Reddit r/jira, Has anyone automated their backups for Jira Cloud?