StructureMigrator
Der offizielle Migrationspfad für Structure for Jira überträgt Ihre Board-Hierarchien — aber nicht, wer sie sehen darf und mit welcher Ansicht. StructureMigrator schließt genau diese Lücke: Berechtigungen und Views wandern board-genau in die Cloud, nachprüfbar gegen den Data-Center-Stand.
- Überträgt Berechtigungen und Views, die Atlassian nicht migriert — board-genau
- Ordnet Nutzer und Projektrollen automatisch ihren Cloud-Pendants zu
- Dry-Run vor jedem Schreibschritt, Duplikatschutz für vorhandene Cloud-Boards
- Dry-Run vor jedem Schreiben
- Nach jeder Stufe gegen Data Center geprüft
- Ein isolierter Stack pro Kunde
- Abschlussbericht nennt auch Übersprungenes
Structure for Jira ist in großen Data-Center-Installationen oft das zentrale Planungswerkzeug: hierarchische Board-Ansichten über viele Projekte, dazu Berechtigungen, die regeln, wer ein Board sehen und bearbeiten darf, und gespeicherte Views mit den passenden Spalten. Der offizielle Cloud-Migrationspfad überträgt davon nur die Board-Hierarchien. Berechtigungen und Views bleiben zurück — und müssen anschließend Board für Board von Hand neu gesetzt werden. Bei dutzenden bis über tausend Boards wird daraus tagelange, fehleranfällige Klickarbeit, deren Ergebnis niemand belastbar nachprüfen kann.
StructureMigrator übernimmt genau diesen Teil. Das Werkzeug liest die Berechtigungen und Views aus Data Center aus, ordnet Nutzer und Projektrollen ihren Cloud-Pendants zu und schreibt beides board-genau über die Structure-Cloud-Schnittstelle in die Cloud. Jeder schreibende Schritt läuft zuerst als Dry-Run, der zeigt, was passieren würde, ohne etwas zu verändern. Bereits vorhandene Cloud-Boards erkennt das Tool und lässt sie unberührt, und nach der Übertragung gleicht eine automatische Prüfung die Cloud-Berechtigungen gegen den Data-Center-Stand ab.
Was eine Standard-Migration offen lässt
Nach der Standard-Migration
- Berechtigungen kommen bei der Migration nicht mit — jedes Board muss von Hand neu freigegeben werden
- Gespeicherte Views fehlen, Teams richten jede Spaltenansicht erneut ein
- Nutzer und Rollen müssen mühsam von Hand auf die Cloud abgebildet werden
- Ob nach der Nacharbeit wirklich alles stimmt, lässt sich kaum überprüfen
Mit diesem Werkzeug StructureMigrator
- Wer ein Board sehen und bearbeiten darf, ist board-genau in die Cloud übertragen
- Views sind übertragen und korrekt berechtigt, die gewohnten Ansichten stehen sofort bereit
- Nutzer und Projektrollen sind über die Atlassian-Account-ID automatisch zugeordnet
- Eine automatische Prüfung gleicht die Cloud-Berechtigungen gegen den Data-Center-Stand ab
In drei geprüften Stufen
StructureMigrator schreibt nichts blind. Jeder Schritt lässt sich einzeln und gezielt auf ein einzelnes Board beschränken, jeder schreibende Schritt läuft vorab als Dry-Run, und bestehende Cloud-Boards bleiben durch die Duplikat-Erkennung unberührt. Nach der Übertragung wird das Ergebnis gegen den Data-Center-Stand geprüft.
-
1
Erfassen & Zuordnen
StructureMigrator erkennt zunächst die technischen Eckdaten Ihrer Cloud-Instanz automatisch und liest dann alle Board-Berechtigungen aus Data Center aus. Anschließend ordnet es Nutzer über die Atlassian-Account-ID und die Projektrollen ihren Cloud-Pendants zu — die Grundlage dafür, dass später jede Berechtigung bei der richtigen Person landet.
Verifiziert: Cloud-Konfiguration erkannt, Data-Center-Berechtigungen exportiert, Nutzer und Rollen zugeordnet
-
2
Migrieren
Das Tool ruft alle vorhandenen Cloud-Boards ab, erkennt Duplikate anhand von Name, Eigentümer und Aufbau und überträgt die Berechtigungen dann board-genau über die Structure-Cloud-Schnittstelle. Bereits vorhandene Boards bleiben dabei unangetastet, und jeder Schreibschritt lässt sich vorab im Dry-Run prüfen.
Verifiziert: Berechtigungen board-genau übertragen, bestehende Cloud-Boards geschützt
-
3
Views & Verifikation
Zuletzt überträgt StructureMigrator die gespeicherten Views und setzt deren Berechtigungen in der Cloud korrekt. Danach gleicht eine automatische Prüfung alle übertragenen Berechtigungen gegen den Data-Center-Export ab, sodass nachvollziehbar dokumentiert ist, dass die Cloud dem Original entspricht.
Verifiziert: Views übertragen und berechtigt, Berechtigungen gegen Data Center geprüft
Was es kann
Cloud-Konfiguration automatisch erkannt
Region, Domain-, App- und Install-ID Ihrer Cloud-Instanz ermittelt StructureMigrator selbst aus dem laufenden Netzwerkverkehr. Sie müssen diese verstreuten technischen Parameter nicht zusammensuchen und nicht abtippen — das spart Zeit und schließt eine typische Fehlerquelle aus, bevor der erste Schritt läuft.
Nutzer und Projektrollen automatisch zugeordnet
Data-Center-Konten und Projektrollen werden über die Atlassian-Account-ID ihren Cloud-Pendants zugeordnet, nicht über leicht abweichende Namen. So landen die übertragenen Berechtigungen nach der Migration bei den richtigen Personen und Rollen — und nicht versehentlich bei jemand anderem.
Berechtigungen board-genau übertragen
Wer welches Board sehen und bearbeiten darf, überträgt StructureMigrator vollständig von Data Center in die Cloud — Board für Board, über die offizielle Structure-Cloud-Schnittstelle. Das ist genau der Teil, den der Standard-Migrationspfad auslässt und den Sie sonst von Hand nachziehen müssten.
Gespeicherte Views inklusive
Gespeicherte Spaltenkonfigurationen — die Views — wandern mit in die Cloud und erhalten dort wieder die richtigen Berechtigungen. Ihre Teams öffnen ihre Boards in der Cloud mit den gewohnten Ansichten, statt sich jede Spaltenanordnung erneut einrichten zu müssen.
Bestehende Cloud-Boards geschützt
Boards, die in der Cloud schon existieren, erkennt StructureMigrator zuverlässig anhand von Name, Eigentümer und Aufbau und lässt sie unberührt. Ein zweiter Lauf oder eine Teilmigration erzeugt dadurch keine Dubletten und überschreibt keine vorhandene Konfiguration — Sie können gefahrlos wiederholen.
Dry-Run und automatische Verifikation
Vor jedem schreibenden Schritt zeigt ein Dry-Run alle geplanten Änderungen, ohne etwas zu verändern. Nach der Migration gleicht eine automatische Prüfung die übertragenen Berechtigungen gegen den Data-Center-Stand ab und dokumentiert das Ergebnis — Sie sehen schwarz auf weiß, dass die Cloud dem Original entspricht.
Häufige Fragen vor der Migration
Werden meine bestehenden Cloud-Boards überschrieben?
Nein. StructureMigrator erkennt vorhandene Cloud-Boards anhand von Name, Eigentümer und Aufbau und lässt sie unberührt. Dadurch erzeugen auch ein zweiter Lauf oder eine Teilmigration keine Dubletten und überschreiben keine bestehende Konfiguration.
Kann ich erst ein einzelnes Board testen, bevor ich alles migriere?
Ja. Jeder Schritt lässt sich auf ein einzelnes Board beschränken, und jeder schreibende Schritt läuft vorab als Dry-Run, der zeigt, was passieren würde, ohne etwas zu verändern. So können Sie an einem Pilot-Board prüfen und erst danach in die Breite gehen.
Landen die Berechtigungen wirklich bei den richtigen Personen?
StructureMigrator ordnet Nutzer über die Atlassian-Account-ID zu, nicht über Namen, die in Data Center und Cloud abweichen können. Projektrollen werden gesondert zugeordnet. So treffen die übertragenen Berechtigungen die richtigen Personen und Rollen.
Wie kann ich nachprüfen, dass die Cloud dem Data-Center-Stand entspricht?
Nach der Migration gleicht eine automatische Verifikation die übertragenen Cloud-Berechtigungen gegen den Data-Center-Export ab und dokumentiert das Ergebnis. Abweichungen werden benannt, statt unbemerkt zu bleiben — Sie haben einen nachprüfbaren Beleg.
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
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
- Token-gesicherte Außenkante, 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.