PermissionSync
Permission Schemes sind der Bereich, in dem eine Migration am leisesten Schaden anrichtet: Ein zu viel entferntes Recht fällt oft erst Wochen später auf. PermissionSync ist genau darauf zugeschnitten.
- Berechtigungen Schema für Schema, Rolle für Rolle abgeglichen
- Unklares wird gemeldet, nie gelöscht
- Zwei Not-Aus vor jedem echten Löschvorgang
- Dry-Run vor jedem Schreiben
- Nach jeder Stufe gegen Data Center geprüft
- Geschrieben wird erst nach Ihrer Freigabe
- Nachvollziehbarer Abschlussbericht zu jedem Lauf
PermissionSync vergleicht die Berechtigungen von Data Center und Cloud Schema für Schema und Rolle für Rolle und entscheidet für jede einzelne Berechtigung nach einer festen Regelkette, ob sie angelegt, entfernt oder geschützt wird. Geschützt sind unter anderem Atlassian-verwaltete Gruppen, App-Rollen und -Konten, Dienstkonten, Portalkunden des Service Managements und Projektadministratoren.
Der Kern ist ein Sicherheitsmodell gegen den leisen Schaden: Unklares wird nie gelöscht, sondern vor der Regelkette aussortiert und in den Bericht geschrieben. Vor jedem echten Löschvorgang prüfen zwei Not-Aus, ob die Schutzmenge unerwartet klein ist oder der Löschvorschlag einen festgelegten Anteil überschreitet — sonst bricht der Lauf ab. Gelöscht wird nur einzeln, nie im Block.
Was eine Standard-Migration offen lässt
Nach der Standard-Migration
- Ein zu viel entferntes Recht fällt erst Wochen später auf
- Dienstkonten und App-Rollen geraten ins Löschen
- Änderungen laufen ungebremst durch
- Erst im Nachhinein sichtbar, was passiert ist
Mit diesem Werkzeug PermissionSync
- Unklares wird gemeldet, nie gelöscht
- Ausdrücklich geschützt
- Zwei Not-Aus vor jedem Löschvorgang
- Erst ein Bericht, dann kontrolliertes Schreiben
So arbeitet PermissionSync
Vergleichen, entscheiden, berichten, kontrolliert schreiben.
-
1
Vergleichen
Die Berechtigungen beider Seiten werden Schema für Schema und Rolle für Rolle aus der Datenschicht gelesen und gegenübergestellt.
Verifiziert: Gleiche Momentaufnahme, gleiches Ergebnis.
-
2
Entscheiden
Für jede Berechtigung entscheidet die feste Regelkette: anlegen, entfernen oder schützen. Unklares wird vorher aussortiert.
Verifiziert: Unklarheit führt zur Meldung, nicht zur Aktion.
-
3
Berichten
Das Ergebnis ist zunächst ein Bericht, der jede geplante Änderung ausweist.
Verifiziert: Nichts wird ohne getrennte Freigabe geschrieben.
-
4
Kontrolliert schreiben
Nach Freigabe wird geschrieben — mit zwei Not-Aus vor jedem Löschen und nur einzeln, nie im Block.
Verifiziert: Zwei Not-Aus, keine Block-Löschung.
Was es kann
Schema für Schema, Rolle für Rolle
Der Abgleich vergleicht beide Seiten systematisch und entscheidet je Berechtigung nach einer festen Regelkette: anlegen, entfernen oder schützen.
Unklares wird nie gelöscht
Lässt sich ein Benutzer, eine Gruppe oder eine Rolle nicht zweifelsfrei zuordnen, wird der Eintrag vor der Regelkette aussortiert und landet im Bericht — nie im Löschvorschlag.
Geschützte Konten
Atlassian-verwaltete Gruppen, App-Rollen und -Konten, Dienstkonten, Portalkunden und Projektadministratoren sind ausdrücklich geschützt.
Zwei Not-Aus vor dem Löschen
Ist die Schutzmenge unerwartet klein oder überschreitet der Löschvorschlag einen festgelegten Anteil, bricht der Lauf ab. Gelöscht wird nur einzeln, nie im Block.
Erst Bericht, dann Schreiben
Das Ergebnis ist zunächst ein Bericht. Das Schreiben ist ein getrennter, ausdrücklich freizugebender Schritt.
Aus der Datenschicht, nicht live
Gelesen wird ausschließlich aus der versionierten Datenschicht, nicht live — gleiche Momentaufnahme, gleiches Ergebnis.
Häufige Fragen vor der Migration
Kann PermissionSync versehentlich Rechte löschen?
Das ist genau das Risiko, gegen das es gebaut ist. Unklares wird nie gelöscht, sondern nur gemeldet. Vor jedem echten Löschvorgang greifen zwei Not-Aus, und gelöscht wird nur einzeln, nie im Block.
Welche Konten sind geschützt?
Unter anderem Atlassian-verwaltete Gruppen, App-Rollen und -Konten, Dienstkonten, Portalkunden des Service Managements und Projektadministratoren.
Sehen wir vorher, was geändert wird?
Ja. Das Ergebnis ist zunächst ein Bericht. Das Schreiben ist ein getrennter Schritt, der ausdrücklich freigegeben werden muss.
Warum aus der Datenschicht statt live?
Weil eine feste Momentaufnahme zu einem reproduzierbaren Ergebnis führt: gleiche Grundlage, gleiche Entscheidung — unabhängig davon, wann der Lauf startet.
Kontrolliert — von Anfang bis Abschlussbericht
Lesen vom Schreiben getrennt
Gelesen wird aus einer read-only Datenschicht, geschrieben nur über einen einzigen kontrollierten Kanal. Lesezugriffe belasten Ihre Cloud nie.
Testlauf vor jedem Schreiben
Der Dry-Run zeigt vollständig, was passieren würde. Geschrieben wird erst auf Ihre ausdrückliche Freigabe.
Wiederholbar ohne Risiko
Jeder Schritt lässt sich erneut ausführen, ohne Schaden anzurichten. Eine Unterbrechung ist kein Problem, ein zweiter Lauf erzeugt keine Dubletten.
Ein isolierter Stack pro Kunde
Alle Werkzeuge laufen auf der Jira-Migration-Manager-Plattform, pro Mandat vollständig getrennt. Keine Vermischung von Daten.
Der Abschlussbericht benennt jeden Vorgang einzeln: repariert, zu prüfen, übersprungen oder fehlgeschlagen. Nichts wird im Stillen falsch verarbeitet.
Läuft auf dem Jira Migration Manager
Dieses Werkzeug steht nicht allein. Es läuft auf der Plattform, die alle Werkzeuge vereint: Eine read-only Lese-Schicht zieht Data Center und Cloud in eine versionierte Momentaufnahme, und jede Änderung geht durch ein einziges, kontrolliertes Schreib-Gateway.
Mehr zum Jira Migration ManagerWeitere Werkzeuge
Migrations-Plattform
Jira Migration Manager
Die Plattform, die alle Migrationswerkzeuge unter einem Dach vereint und eine Jira-DC-zu-Cloud-Migration sicher und wiederholbar macht: getrennte Lese- und Schreibwege, ratenlimitiert in die Cloud, Zugangsdaten verschlüsselt, ein isolierter Stack je Kunde.
- Read-only-Lese-Schicht und ratenlimitierter Schreibkanal strikt getrennt
- Alle Werkzeuge auf einer Datenbasis, verkettbar zu Pipelines
- Ein kontrollierter Zugangspunkt, verschlüsselter Keystore, ein Stack je Kunde
Assets-Migration
Asset Relink
Migriert Insight/Assets vollständig in die Cloud: Felder und Kontexte, AQL-Filter, Screens und die Objektwerte an jedem Vorgang. Genau dort, wo Standard-Tools die Verknüpfungen verlieren.
- Felder, Kontexte und Screens in der Cloud anlegen
- AQL-Filter von Data Center nach Cloud übersetzen
- Objektwerte an jedem Vorgang neu verknüpfen
Managed Migration
Jira Migration Helper
JCMA migriert die Masse Ihrer Daten, lässt aber Konfiguration kaputt oder unmigriert zurück. Der Jira Migration Helper schließt diese Lücken Modul für Modul und fährt mit der Managed Migration die passenden Fixes pro fertigem Projekt automatisch — jedes standardmäßig im Dry-Run und gegen die echte Cloud-API geprüft.
- Filter, Dashboards, Felder, Rollen und Berechtigungen reparieren, was JCMA offen lässt
- Managed Migration: pro fertig gemeldetem Projekt automatisch die passenden Fixes fahren
- Web-UI oder CLI, jedes Modul Dry-Run-Standard und über das idempotente Write-Gateway abgesichert
Passt das zu Ihrer Migration?
Schildern Sie kurz Ihren Fall — ich sage Ihnen ehrlich, ob und wie dieses Werkzeug hilft.
Gespräch vereinbarenAtlassian beendet den Support für Data Center am 28. März 2029. Wer eine große, komplex verknüpfte Umgebung umzieht, plant das besser früh als spät.