Bevor Sie Atlassian-Organisationen zusammenführen: Die Checkliste für Identität, Zugriffe und Lizenzen

Atlassian-Cloud-Organisationen entstehen häufig aus nachvollziehbaren lokalen Gründen: Eine Akquisition bringt eine eigene Umgebung mit, ein Geschäftsbereich startet unabhängig oder Teams entwickeln über die Zeit getrennte Administrationsmodelle. Irgendwann kann daraus eine Enterprise-Landschaft mit doppelter Nutzerverwaltung, fragmentierten Sicherheitskontrollen, überlappenden Gruppen und unklaren Zugriffsrechten werden.

Die Zusammenführung von Organisationen kann diese Landschaft vereinfachen. Sie ist jedoch eine erhebliche und nicht umkehrbare administrative Veränderung. Laut aktueller Atlassian-Dokumentation werden dabei Produkte, Sites und Nutzer von einer Quellorganisation in eine Zielorganisation überführt; anschließend wird die Quellorganisation deaktiviert. Neue Consolidation-Workflows mit teilweise Self-Service-basierten Optionen für geeignete Organisationen werden ab dem 19. Oktober schrittweise bereitgestellt.

Das macht den jetzigen Zeitpunkt gut für die Vorbereitung. Doch diese Vorbereitung sollte mit Identität und Betriebsmodell beginnen, nicht mit einer Support-Anfrage.

Was eine Atlassian Organization Consolidation ist und was nicht

Eine Atlassian-Organisation ist die unternehmensweite Administrationsebene für Atlassian Cloud. Bei einer Consolidation wird die Quellorganisation mit einer Zielorganisation zusammengeführt. Sites, Produkte und Nutzer werden unter einem gemeinsamen Administrationsmodell gebündelt.

Das ist nicht gleichbedeutend mit einer Content-Migration von einer Jira- oder Confluence-Site zu einer anderen. Atlassian erklärt, dass bestehende Site-URLs und Apps der Quellorganisation während der Consolidation nicht verändert werden. Stattdessen werden Sites und Apps aus der Quellorganisation gelöst und unverändert mit der Zielorganisation verknüpft.

Dieser Unterschied ist wichtig. Wenn Sie Projekte zusammenführen, Confluence Spaces bündeln oder die Zahl der Sites reduzieren möchten, reicht eine Organization Consolidation allein möglicherweise nicht aus. Klären Sie zuerst, ob Sie eine Consolidation, einen Produkttransfer, eine Site-Migration oder eine Kombination dieser Maßnahmen benötigen.

Warum dieses Vorhaben einen bereichsübergreifenden Owner braucht

Der Prozess betrifft weit mehr als das Atlassian-Administrationsteam. Er kann Gruppennamen, Nutzerstatus, das Verhalten von Identity Providern, Lizenzverbrauch und die spätere Zugriffsverwaltung verändern.

Atlassian weist ausdrücklich darauf hin, dass der Prozess nicht rückgängig gemacht werden kann. Behandeln Sie ihn deshalb als Enterprise Change mit klarer Verantwortung über Identity and Access Management, Security, bei Bedarf Legal oder Privacy, Procurement oder Lizenzmanagement sowie die Teams, die Jira, Confluence und Marketplace Apps administrieren.

Eine technische Checkliste ist unverzichtbar. Ebenso wichtig ist die strategische Frage: Wie soll das zukünftige Zugriffsmodell der Zielorganisation aussehen?

1. Prüfen Sie die Eignung beider Organisationen

Für eine Atlassian Consolidation müssen beide Organisationen Centralized User Management verwenden. Organisationen mit Original User Management benötigen einen anderen Transferweg.

Atlassian nennt weitere Voraussetzungen vor der Zusammenführung. Dazu gehören ein gemeinsamer Organization Admin, keine Atlassian Support Accounts in einer der Organisationen, keine siteless Products in der Quellorganisation, zurückgesetzte User Access Settings in der Quelle und keine widersprüchlichen Nutzerstatus zwischen beiden Organisationen.

Betrachten Sie diese Punkte nicht als Details, die sich später lösen lassen. Es handelt sich um Preflight-Blocker. Erfassen Sie den Ist-Zustand früh und ordnen Sie jedem Hindernis eine verantwortliche Person zu.

2. Klären Sie widersprüchliche Nutzerstatus vor dem Merge

Ein Nutzer kann in einer Organisation aktiv und in der anderen inaktiv sein. In diesem Fall wird der Nutzer laut Atlassian in der zusammengeführten Organisation als inaktiv behandelt. Dadurch kann der Zugriff auf Produkte verloren gehen.

Das ist relevant, weil das Problem sonst erst auffällt, wenn Mitarbeitende keinen Zugriff mehr auf Jira, Confluence oder eine benötigte App haben. Erstellen Sie deshalb vor dem Dry Run eine Abstimmungsliste:

• identifizieren Sie Accounts, die in beiden Organisationen vorkommen;
• bestätigen Sie, welche Personen nach der Zusammenführung aktiv sein sollen;
• entfernen Sie nicht benötigte Produktzugriffe, wenn eine Person bewusst inaktiv bleibt;
• dokumentieren Sie den gewünschten Zugriffsstatus in der Zielorganisation.

„Aktiv“ ist nicht nur ein technisches Kennzeichen. Es ist eine Zugriffsentscheidung, die zur Rolle einer Person und zum Kontext ihrer rechtlichen Einheit passen muss.

3. Prüfen Sie Ihr Identity-Provider- und SCIM-Design

Die Konfiguration von Identity Provider und SCIM gehört zu den wichtigsten Prüfpunkten. Nach der Zusammenführung werden Identity Provider in der Zielorganisation verwaltet und können Nutzer über alle Sites hinweg provisionieren, einschließlich der zuvor zur Quellorganisation gehörenden Sites.

Für Unternehmensgruppen mit getrennten rechtlichen Einheiten, regulierten Daten oder regionalen Einschränkungen kann das zu unbeabsichtigten Zugriffsrechten führen. Atlassian nennt mögliche Risiken für Data Residency, DSGVO- oder Privacy-Verpflichtungen und Zugriffskontrollen, wenn synchronisierte Gruppen Nutzer enthalten, die nicht auf jede Site zugreifen dürfen.

Klären Sie vor der Consolidation insbesondere diese Fragen:

• Welche Gruppen des Identity Providers werden in die Zielorganisation synchronisiert?
• Passt die Gruppenmitgliedschaft sauber zu Produkt- und Site-Zugriffen?
• Sollen alle durch den Identity Provider verwalteten Nutzer für jede Site berechtigt sein?
• Müssen Grenzen zwischen rechtlichen Einheiten, Regionen oder Vertraulichkeitsstufen erhalten bleiben?
• Wer überprüft die Zugriffe nach dem ersten SCIM-Provisioning-Zyklus?

Ziel ist nicht, Automatisierung zu bremsen. Ziel ist, sicherzustellen, dass automatisiertes Provisioning Ihr zukünftiges Zugriffsmodell abbildet und nicht nur historische Organisationsstrukturen fortschreibt.

4. Bereiten Sie sich auf Gruppenumbennennungen und veränderte Admin-Rechte vor

Gruppen mit demselben Namen bleiben nach der Consolidation nicht unverändert gleich. Atlassian erklärt, dass Gruppen aus der Quellorganisation mit dem Namen der Quellorganisation ergänzt werden, um Konflikte zu vermeiden. Auch die Admin-Gruppe der Quelle wird umbenannt und verleiht danach keine administrativen Berechtigungen mehr.

Das kann Automatisierungsregeln, Lizenzzuweisungen, Access Reviews und interne Dokumentation beeinflussen. Es kann auch eine falsche Kontinuität suggerieren, wenn ein Gruppenname vertraut wirkt, aber nicht mehr dieselben Mitglieder oder Berechtigungen hat.

Erstellen Sie deshalb ein Inventar der folgenden Elemente:

• Gruppen der Quell- und Zielorganisation;
• doppelte und ähnlich benannte Gruppen;
• Gruppen für Jira-, Confluence- und App-Berechtigungen;
• Gruppen, die durch SCIM oder einen Identity Provider verwaltet werden;
• Gruppen, die administrative Rollen verleihen;
• Automatisierungen, Skripte oder Integrationen mit Bezug auf Gruppennamen.

Definieren Sie anschließend die Zielstruktur der Gruppen vor der Consolidation. Verlassen Sie sich nicht dauerhaft auf umbenannte Legacy-Gruppen als Zugriffsmodell.

5. Planen Sie Lizenzen und Marketplace Apps separat

Eine Organization Consolidation ist keine Billing Consolidation. Atlassian stellt klar, dass Billing und Licensing für übertragene Sites nicht automatisch aktualisiert werden. Administratoren der Quellorganisation können in der Zielorganisation zu Organization Admins werden. Das kann Produktzugriffe verändern und den Lizenzverbrauch erhöhen.

Auch Marketplace Apps bleiben pro Site und Host Product lizenziert. Eine Consolidation führt Marketplace-Abonnements nicht zusammen, reduziert sie nicht und verändert sie nicht. Wenn dieselbe App auf mehreren Sites vorhanden ist, bleiben diese Instanzen getrennt.

Bitten Sie Finance und Procurement, vor der Änderung Folgendes zu prüfen:

• Plan Tier jeder Site und jedes Produkts;
• aktuelle und erwartete lizenzierte Nutzerzahlen;
• Mitgliedschaften in Administratorgruppen;
• einzelne Marketplace-Abonnements und ihre Verlängerungsdaten;
• das Zielmodell für Billing nach der Consolidation.

So wird die Lizenzarbeit nicht zu einem unerwarteten Problem nach dem Merge.

6. Planen Sie Betriebsfenster und Change Freeze

Während der Consolidation sind die Admin Hubs beider Organisationen schreibgeschützt. Atlassian weist außerdem darauf hin, dass Änderungen an Sites und Produkten während des Zeitfensters blockiert sind.

Der Merge der Nutzerbasis dauert typischerweise ein bis vier Stunden. Die anschließende Zusammenführung des Teamwork Graph benötigt gewöhnlich etwa eine weitere Stunde. Bei großen Organisationen kann das gesamte Zeitfenster vier bis sechs Stunden oder länger dauern.

Bereiten Sie einen konkreten Change-Plan vor:

• benennen Sie eine verantwortliche Person für Incident Handling und Kommunikation im Zeitfenster;
• pausieren Sie nicht notwendige Änderungen an Nutzern, Gruppen, Sites und Subscriptions;
• informieren Sie Support-Teams, Site Admins und Identity Teams;
• definieren Sie, wie Zugriffsprobleme nach dem Zeitfenster priorisiert und bearbeitet werden;
• vermeiden Sie Abhängigkeiten von neuen Rovo Agents während des Userbase Merge, da Atlassian erklärt, dass sie bei gesperrter Nutzerbasis nicht erstellt werden können.

Die Produkt-Sites laufen weiter, die Administration ist jedoch eingeschränkt. Planen Sie entsprechend.

7. Behandeln Sie den Dry Run als Freigabe-Gate, nicht als Formalität

Der Atlassian-Prozess enthält Preflight Checks und einen Dry-Run-Report, der erwartete Änderungen wie Gruppenumbennennungen zeigt. Ohne schriftliche Freigabe dieses Reports kann die Consolidation nicht fortgesetzt werden.

Nutzen Sie den Dry Run, um Ihre Annahmen zu überprüfen, nicht nur um das Projekt formal weiterzuführen. Prüfen Sie Nutzerstatus-Konflikte, Gruppenänderungen, administrative Rollen, Sites, Auswirkungen auf Identität und das gewünschte Betriebsmodell nach der Zusammenführung.

Wenn das Ergebnis etwas Unerwartetes zeigt, lösen Sie es vor der Freigabe. Die Consolidation ist kein geeigneter Zeitpunkt, um ein Problem im Zugriffsdesign zu entdecken.

Ihre Checkliste nach der Consolidation

Prüfen Sie nach Abschluss die Zugriffe und operativen Ergebnisse, bevor Sie den Merge als erfolgreich bewerten.

1. Bestätigen Sie Zugriffe auf die richtigen Produkte, Sites und Rollen.
2. Überprüfen Sie umbenannte Gruppen und vergeben Sie nachhaltige Ownership in der Zielorganisation.
3. Validieren Sie SSO und SCIM Provisioning in der Zielorganisation.
4. Prüfen Sie Admin-Berechtigungen und Gruppen mit privilegierten Zugriffsrechten.
5. Stimmen Sie Produktlizenzen, Plan Tiers, Billing Ownership und Marketplace-Abonnements ab.
6. Bestätigen Sie Domain Verification und Security Controls, einschließlich Atlassian Guard, soweit relevant.
7. Dokumentieren Sie Learnings, bevor Sie eine weitere Organisation zusammenführen.

Eine Consolidation sollte das Zugriffsmodell vereinfachen, nicht nur das Organigramm

Die neuen Workflows können den Prozess für geeignete Cloud-Organisationen zugänglicher machen. Sie reduzieren jedoch nicht die Bedeutung einer gründlichen Vorbereitung.

Eine erfolgreiche Consolidation erkennen Sie nicht daran, dass die Quellorganisation aus dem Admin Screen verschwindet. Entscheidend ist, ob die Zielorganisation danach klarere Ownership, Least-Privilege-Zugriffe, vorhersehbares Provisioning, kontrollierte Kosten und weniger administrative Ausnahmen hat.

Wenn Ihre Organisation eine Consolidation bewertet, ein Atlassian-Cloud-Betriebsmodell entwickelt oder die Identitäts- und Zugriffsarbeit rund um eine größere Transformation vorbereitet, unterstützt Sie Lupus Consulting gern dabei, die Readiness strukturiert zu bewerten und Plattformänderungen in einen umsetzbaren Enterprise-Plan zu überführen.