Atlassian Cloud Migration: Wir bringen dein Data Center sicher in die Cloud.

Das reguläre End of Life der betroffenen Atlassian-Data-Center-Produkte ist am 28. März 2029 um 23:59 Uhr PST. Danach laufen die betroffenen Subscriptions aus und die Umgebungen werden im Wesentlichen read-only. Den vollständigen Zeitplan findest du auf der Data-Center-End-of-Life-Seite.

Für die meisten Unternehmen sind vor allem Jira Software Data Center, Jira Service Management Data Center und Confluence Data Center relevant. Ebenfalls betroffen sind unter anderem Bamboo Data Center, Crowd Data Center sowie die dazugehörigen Data-Center- und Marketplace-Apps. Bitbucket Data Center gehört ausdrücklich nicht zu diesem End of Life.

Unser Rat ist deshalb klar: Warte mit der Planung nicht bis 2029. Eine gute Migration beginnt mit Analyse, Bereinigung, Tests und einem realistischen Zielbild. Der Cloud Migration Guide ist dafür ein guter technischer Einstieg. Wenn du wissen möchtest, wie viel Vorlauf deine konkrete Instanz braucht, können wir gemeinsam einen ersten Blick darauf werfen.

Wenn keine besondere Vereinbarung greift, endet die reguläre Data-Center-Nutzung am 28. März 2029. Ab diesem Zeitpunkt ist ein normaler produktiver Weiterbetrieb der betroffenen Produkte nicht mehr vorgesehen. Die genauen Übergangsregeln und Ausnahmen stehen auf der EOL-Seite.

Für einzelne Kunden kann eine Extended Maintenance als Ausnahme infrage kommen. Darauf würden wir eine Migrationsstrategie aber nicht aufbauen. Gerade bei einer gewachsenen Instanz brauchst du vorher genug Zeit für Cleanup, Testmigrationen und die Anpassung von Apps, Makros, Identity und Schnittstellen.

Wenn noch keine Roadmap steht, solltest du jetzt zuerst Umfang, Risiken und Zielbild festziehen. Bei komplexeren Setups lohnt es sich, schon in dieser Phase erfahrene Unterstützung dazuzunehmen. Welche Fälle typischerweise zusätzliche Migrationsexpertise brauchen, kannst du in der Übersicht zu Migrationsmethoden und Support nachlesen. Oder wir prüfen direkt gemeinsam, wie anspruchsvoll dein Setup wirklich ist.

Für Jira gibt es den kostenlosen Jira Cloud Migration Assistant (JCMA). Er hilft dir bei Projekten und Vorgängen, Benutzern und Gruppen, Boards und Sprints, Workflows, Filtern, Advanced Roadmaps, Jira Service Management Assets und vielen weiteren Jira-Daten. Dazu kommen App Assessments, Nutzerprüfungen, Pre-Migration Checks, Reports und Fehlerprotokolle.

Für Confluence übernimmt der Confluence Cloud Migration Assistant (CCMA) Spaces, Seiten, Anhänge, Nutzer und Gruppen sowie App-Daten, wenn dafür ein unterstützter Migrationspfad existiert. Globale Einstellungen, bestimmte Berechtigungen, Makros und Application Links brauchen trotzdem oft Nacharbeit. Die Detailübersichten für Jira und Confluence solltest du deshalb vor der ersten Testmigration einmal vollständig durchgehen.

Dazu kommen das App Assessment, die Pre-Migration Checklists und technische Migration Utility APIs. Diese Werkzeuge nehmen dir viel Arbeit ab. Sie entscheiden aber nicht für dich, welche Altlasten weg können, welche App ersetzt werden sollte oder welche Integration in Cloud neu gebaut werden muss.

Der JCMA deckt einen großen Teil der Jira-Kerndaten ab: Projekte, Issues, Benutzer und Gruppen, Boards, Sprints, Workflows, Filter, viele Schemes, Advanced Roadmaps und Assets. Die genaue Matrix findest du unter What gets migrated with JCMA.

Der CCMA kann Spaces, Seiten inklusive Historie, Kommentare, Attachments, Nutzer, Gruppen, globale Templates und viele weitere Inhalte übertragen. Trotzdem gilt: Nicht alles landet 1:1 in Cloud. Gerade globale Berechtigungen, Sonderkonfigurationen und Marketplace-Makros musst du separat betrachten.

Für uns sind die Assistenten deshalb Transport- und Prüfwerkzeuge – nicht die komplette Migration. Vor dem Produktivlauf gehören ein sauberes Cleanup, mindestens eine Testmigration und echte User Acceptance Tests dazu. Erst wenn typische Arbeitsabläufe wirklich funktionieren, ist der Cutover bereit.

Lift & Shift bedeutet: Du bereitest deine bestehende Instanz sauber vor und ziehst sie in einem geplanten Downtime-Fenster möglichst geschlossen um. Das passt gut, wenn Jira oder Confluence bereits aufgeräumt sind und du die vorhandene Struktur weitgehend behalten möchtest. Der Lift-&-Shift-Leitfaden zeigt dir den technischen Ablauf.

Bei einer phasenweisen Migration ziehst du Projekte, Spaces, Teams oder Produkte Schritt für Schritt um. Das kann bei großen Organisationen sinnvoller sein, macht aber die Übergangsphase anspruchsvoller, weil Data Center und Cloud zeitweise parallel laufen. Die möglichen Varianten unterscheiden sich zwischen Jira und Confluence.

Beim Greenfield-Ansatz nutzt du die Migration bewusst als Neustart: Die Cloud wird sauber aufgebaut und nur das übernommen, was du künftig noch brauchst. Das ist besonders interessant, wenn deine Instanz über Jahre gewachsen ist und viele Workflows, Felder, Apps oder Spaces inzwischen eher Ballast als Mehrwert sind. Genau dafür ist eine gründliche Bestandsbereinigung so wertvoll.

JCMA und CCMA selbst sind kostenlos. Für Tests kannst du – wenn dein Vertrag dafür qualifiziert – eine Cloud Migration Trial nutzen. Die eigentlichen Lizenzkosten entstehen für deine Cloud-Produkte, also zum Beispiel Jira, Confluence, Jira Service Management und die Marketplace-Apps, die du danach weiter einsetzen möchtest. Die aktuellen Cloud-Modelle findest du in der Cloud-Lizenzübersicht.

Der größere variable Kostenblock steckt meist in der Arbeit rund um die Migration: Analyse, Cleanup, Testmigrationen, UAT, App-Migrationen, Makro-Ersatz, Identity, Schnittstellen, Neuentwicklung, Dokumentation, Schulungen, Cutover und Hypercare. Wenn eine wichtige Data-Center-App keine passende Cloud-Lösung hat, können zusätzliche Lizenzkosten, ein Produktwechsel oder eine individuelle Cloud-App beziehungsweise Schnittstelle dazukommen.

Deshalb lässt sich ein seriöser Preis erst nennen, wenn wir deine Instanz gesehen haben. Nutzerzahl allein reicht dafür nicht: Eine kleinere, stark individualisierte Umgebung kann mehr Aufwand verursachen als eine deutlich größere, aber sauber standardisierte Instanz. Im ersten gemeinsamen Blick auf dein Setup können wir Aufwand, Lizenzthemen und mögliche Folgekosten deutlich realistischer einordnen.

Nicht zwingend. Für die Übergangsphase gibt es mehrere Modelle, mit denen sich doppelte Lizenzkosten vermeiden oder zumindest deutlich reduzieren lassen. Dazu gehören die Cloud Migration Trial, Step-up Credits und Dual Licensing.

Beim Dual Licensing kannst du bei qualifizierten jährlichen Cloud-Subscriptions deine bestehende Server- oder Data-Center-Lizenz für denselben Zeitraum ohne zusätzliche Lizenzkosten weiterverwenden. Die Details dazu findest du in der Übersicht zu Trials, Step-up Credits und Dual Licensing sowie in der Purchasing & Licensing FAQ.

Wichtig ist, Lizenzplanung und Migrationsplanung nicht getrennt voneinander zu behandeln. User-Tiers, Cloud-Plan, App-Lizenzen und Cutover-Zeitpunkt beeinflussen sich gegenseitig. Wenn du diese Seite sauber aufsetzen willst, können wir Lizenzbedarf und Migrationszeitraum zusammen durchrechnen.

Ja. Wenn deine Instanz klein, sauber und wenig individualisiert ist, du nur wenige Apps nutzt und keine kritischen Schnittstellen oder komplizierte Identity-Struktur hast, kannst du eine Migration mit einem erfahrenen internen Admin-Team durchaus selbst angehen. Der Cloud Migration Guide, JCMA und CCMA geben dir dafür eine gute technische Grundlage.

Was wir dir trotzdem dringend raten: Nie mit der Produktivmigration anfangen. Erst Pre-Migration Checks durchführen, dann in einer Testumgebung migrieren und typische Arbeitsabläufe mit echten Nutzern durchspielen. Die Pre-Migration Checklists, der Leitfaden zur Testmigration und die UAT-Anleitung sind dafür besonders hilfreich.

Sobald Apps, Makros, AD/SSO, viele Nutzer, große Confluence-Strukturen oder individuelle Integrationen dazukommen, wird aus dem Datentransfer schnell ein Architekturprojekt. Dann würden wir uns zumindest vor dem Start professionellen Rat holen. Bei sehr komplexen Setups ist es meist sinnvoller, Planung und Durchführung gemeinsam mit einem erfahrenen Solution Partner aufzusetzen – damit Testmigration, Cutover und Nachbereitung nicht erst unterwegs erfunden werden müssen.

Rechne bei einer ernsthaften Cloud Migration in Monaten, nicht in Wochen. Die Nutzerzahl ist dabei nur ein Faktor. Viel entscheidender sind die gewachsenen Strukturen: Wie viele Apps gibt es? Wie viele Makros? Wie komplex sind Workflows und Berechtigungen? Welche Schnittstellen hängen am System? Wie wird Identity verwaltet? Was muss neu gebaut werden?

Für eine saubere Migration musst du die bestehende Instanz erst wirklich verstehen, dann bereinigen, Apps und Integrationen bewerten, einen Zielzustand festlegen und mehrere Tests einplanen. Der Lift-&-Shift-Leitfaden hilft dir beim technischen Ablauf; die Testmigration und UAT kommen zusätzlich dazu.

Unsere Planung ist deshalb bewusst konservativer: Mindestens sechs Monate Vorlauf sind auch bei kleineren Unternehmen sinnvoll, wenn die Instanz schon länger genutzt wird. Bei komplexen Setups planen wir lieber 9 bis 12 Monate oder mehr. Mit Blick auf das Data-Center-EOL 2029 sollte spätestens im Frühjahr 2028 eine belastbare Migrationsplanung stehen. Je früher du anfängst, desto mehr Spielraum hast du für App-Ersatz, Neuentwicklung, Cleanup und echte Testläufe.

Das musst du App für App prüfen. Im App Assessment von JCMA und CCMA siehst du, welche Apps installiert sind, ob eine Cloud-Version existiert und ob ein automatisierter, install-only oder herstellerspezifischer Migrationspfad verfügbar ist. Noch hilfreicher ist ein echter App Audit: Dort schaust du nicht nur auf technische Kompatibilität, sondern auch darauf, ob die App überhaupt noch gebraucht wird.

Typische Beispiele, die in größeren Instanzen häufig auftauchen, sind in Confluence etwa KARMA, MANTRA, AURA, Comala Document Management oder ScriptRunner; in Jira begegnen uns oft ScriptRunner, Xray, Zephyr, Tempo oder BigPicture. Eine vorhandene Cloud-Version bedeutet aber noch nicht, dass deine Konfiguration und alle App-Daten automatisch 1:1 mitkommen. Bei jeder geschäftskritischen App müssen Migrationspfad, Feature-Parität, Datenübernahme und Tests separat geklärt werden.

Für einige verbreitete Apps gibt es zusätzlich app-spezifische Migrationshinweise. Wenn eine App in Cloud nicht mehr sinnvoll passt, gibt es drei gute Optionen: native Cloud-Funktionen nutzen, eine bessere Marketplace-Alternative wählen oder eine Funktion individuell neu bauen. Für Jira können wir deine App-Landschaft gemeinsam durchgehen, für Confluence entsprechend die eingesetzten Confluence-Apps und Makros prüfen.

Makros sind einer der Bereiche, die wir bei einer Confluence-Migration besonders früh anschauen. Viele Standardmakros lassen sich übernehmen, funktionieren in Cloud aber teilweise anders. Bei Marketplace-Makros hängt die Datenmigration vom jeweiligen App-Hersteller und dessen Migrationspfad ab. Die Übersicht What migrates with CCMA zeigt dir, was grundsätzlich unterstützt wird.

Entscheidend ist aber nicht nur, ob eine Seite nach dem Import „da“ ist. Nach einer Testmigration musst du prüfen, ob Makros korrekt rendern, Datenquellen stimmen, Berechtigungen greifen und die Seite für den Nutzer noch genauso funktioniert. Das Confluence App Assessment hilft dir dabei, genutzte App-Makros sichtbar zu machen.

Wenn wichtige Makros nicht sinnvoll mitkommen, ersetzen wir sie lieber sauber, statt alte Abhängigkeiten künstlich mitzuschleppen: durch Cloud-Standardfunktionen, eine passende App oder – wenn nötig – eine individuelle Forge-Lösung. Gerade bei stark formatierten Intranets oder Wissensbereichen lohnt sich außerdem ein Blick darauf, wie die Confluence-Struktur in Cloud künftig aussehen soll.

Benutzer und Gruppen können mit den Migration Assistants übertragen werden. Das Identity-Setup selbst wird aber nicht einfach aus Data Center kopiert. Vorher müssen E-Mail-Adressen, Domains, Gruppen und bestehende Verzeichnisanbindungen sauber geprüft werden. Der Guide zur User Migration ist dafür eine gute technische Referenz.

Bei einem klassischen Active Directory ist außerdem wichtig, dass deine aktiven Nutzer und Gruppen vor der Migration korrekt mit Jira beziehungsweise Confluence synchronisiert sind. Die Pre-Migration Checks decken typische Probleme wie doppelte E-Mail-Adressen, Gruppen-Konflikte oder nicht sauber synchronisierte Verzeichnisse ab. In Cloud läuft zentrale Identitätsverwaltung anschließend typischerweise über einen Identity Provider, SAML SSO und – wenn benötigt – SCIM-Provisioning mit Atlassian Guard.

Genau deshalb planen wir Identity lieber bewusst neu, statt die alte Struktur nur nachzubauen. Wenn du Organization, Gruppen, App-Zugriffe und SSO dabei gleich sauber aufsetzen möchtest, können wir dein künftiges Atlassian-Setup gemeinsam strukturieren.

Bestehende Data-Center-Schnittstellen solltest du immer als eigenes Migrationspaket behandeln. Authentifizierung, REST-Endpunkte, Webhooks, Application Links, IDs und teilweise Datenmodelle ändern sich. Besonders wichtig sind die neuen Cloud-IDs; dafür gibt es einen ID-Mapping-Leitfaden.

Für Link-Fixing und ID-Zuordnungen kannst du die Migration Utility APIs nutzen. Danach müssen die Integrationen trotzdem gegen die Cloud-APIs getestet werden – inklusive Authentifizierung, Fehlerverhalten und Rate Limits. Für Application Links und Verbindungen nach dem Umzug ist außerdem die Anleitung Integrate your Atlassian cloud apps after the migration sehr hilfreich.

Unser Rat: Keine geschäftskritische Integration darf erst am Cutover-Tag zum ersten Mal getestet werden. Wenn eine bestehende Schnittstelle nicht sinnvoll portiert werden kann, können wir die passende Cloud-Integration neu aufsetzen und direkt in die Testmigration einbeziehen.

Eine Backend-Bereinigung heißt nicht: möglichst viel löschen. Es geht darum, deine Instanz vor dem Umzug kleiner, klarer und wartbarer zu machen. Alles, was du nicht mehr brauchst, kostet später nur Zeit bei Migration, Tests und Betrieb. Eine gute Checkliste dafür bietet Clean up your instance before migration.

In Jira schauen wir zum Beispiel auf alte Projekte, inaktive Nutzer, Custom Fields, Workflows, Screens, Issue Types, Schemes, Gruppen, Berechtigungen, Boards, Filter und Apps. In Confluence gehören ungenutzte Spaces, veraltete Seiten, Attachments, Makros und Apps dazu. Bei Usern kommen doppelte E-Mail-Adressen, alte Accounts und Gruppen-Konflikte hinzu.

Wichtig ist die Reihenfolge: erst bereinigen, dann testen, dann migrieren. Für Jira kannst du im JCMA gezielt auswählen, was mitkommen soll; in Confluence arbeitest du entsprechend mit Migrationsplänen im CCMA. Danach gehört mindestens eine Testmigration dazu, bevor irgendetwas produktiv umzieht.

Der größte Vorteil ist Erfahrung: Du musst nicht jedes Problem deiner Migration zum ersten Mal selbst entdecken. Ein guter Partner verbindet Analyse, Zielarchitektur, Cleanup, Apps, Identity, Schnittstellen, Testmigrationen, UAT, Cutover, Dokumentation, Schulung und Hypercare zu einem belastbaren Gesamtplan. Eine Übersicht, wann zusätzliche Migrationsexpertise besonders sinnvoll ist, findest du unter Choose a Cloud migration method.

Bei Techanics kommt noch etwas Wichtiges dazu: Unsere Berater planen nicht nur – sie setzen auch um. Als Atlassian Gold Solution Partner können wir bestehende Systeme analysieren, Apps und Makros bewerten, Berechtigungen und Identity neu aufbauen, Schnittstellen anpassen und bei Bedarf eigene Forge-Apps, Makros oder Integrationen entwickeln.

Und wir bleiben bis zum Ende dabei: mit Testmigrationen, Runbook, Cutover-Begleitung, sauberer Dokumentation, Schulungsmaterialien, projektspezifischen Trainings und Hypercare. Das spart dir nicht nur Arbeit – es gibt dir vor allem die Sicherheit, dass Planung und technische Umsetzung aus einer Hand kommen.

Im kostenlosen Erstgespräch wollen wir vor allem deine tatsächliche Ausgangslage verstehen. Dafür schauen wir uns Produkte und User-Zahlen, Jira-Projekte, Confluence-Spaces, Apps und Makros, Benutzerverwaltung, Schnittstellen, Automatisierungen und individuelle Entwicklungen an.

Wenn wir einen Blick in die Instanz bekommen, können wir meist schnell unterscheiden: Was lässt sich relativ sauber migrieren? Wo steckt echter Aufwand? Welche App oder Integration könnte zum Problem werden? Und wo lohnt sich ein Cleanup oder ein Greenfield-Ansatz? Daraus bekommst du einen ersten Zeit-, Risiko- und Aufwandsrahmen. Der Cloud Migration Guide und die Pre-Migration Checklists liefern dafür den technischen Rahmen; wir übersetzen ihn auf deine konkrete Umgebung.

Auch Lizenzfragen können wir direkt mitdenken: Cloud-Plan, User-Tier, App-Lizenzen, Trial, Dual Licensing und mögliche Folgekosten. Und wenn die Zusammenarbeit für beide Seiten passt, musst du nach der Analyse nicht wieder bei null anfangen: Wir können die Migration anschließend gemeinsam mit dir vorbereiten, testen, durchführen und bis in die Hypercare begleiten. Hier kannst du den ersten Termin vereinbaren.