Weitere Migrations-Tools
Wo Standard-Apps und JCMA enden, beginnt das passende Spezialwerkzeug: eine Familie kleiner, scharf zugeschnittener Tools für die Migrationslücken, die der offizielle Pfad still offen lässt.
- Sechs reale Werkzeuge für genau die Lücken, die kein Standard-Tool schließt
- Einzeln einsetzbar, im Verbund stark — eine konsistente Tool-Familie
- Durchgängig Sandbox-First, mit Dry-Run, Resume und nachvollziehbarem Logging
- Dry-Run vor jedem Schreiben
- Nach jeder Stufe gegen Data Center geprüft
- Ein isolierter Stack pro Kunde
- Abschlussbericht nennt auch Übersprungenes
Eine Jira-DC→Cloud-Migration scheitert selten am großen Ganzen, sondern an den vielen kleinen Lücken, die der offizielle Pfad lautlos offen lässt: Status- und Feld-Übersetzungen, die in der Cloud verschwinden, externe Datenquellen, die nicht mehr greifen, oder ein Gutachten, das vor dem ersten Schreibzugriff schlicht fehlt. Jede dieser Lücken kostet nach dem Go-live Tage an Handarbeit — oder fällt erst auf, wenn Nutzer sich beschweren.
Für genau diese Stellen entsteht jeweils ein präzise zugeschnittenes Werkzeug, statt ein überladenes Universaltool zu bauen. Jedes Tool ist einzeln einsetzbar und im Verbund stark, und alle folgen demselben sicheren Prinzip: Sandbox-First, Dry-Run und geprüfter Schreibpfad, damit Ihr Produktivsystem nie zum Versuchsfeld wird.
Was eine Standard-Migration offen lässt
Nach der Standard-Migration
- Cloud zeigt nicht-englischen Nutzern nur noch englische Status-Namen
- Externe Datenquellen aus Elements Connect greifen in der Cloud nicht mehr
- Aufwand und Risiko der Migration sind vor dem Start nur geschätzt
- Eine seltene Lücke hat keine Standardlösung und bleibt liegen
Mit diesem Werkzeug Weitere Migrations-Tools
- Jede Status- und Feld-Übersetzung ist locale-genau zurückgespielt und validiert
- Fehlende Datasources sind per Diff erkannt und sicher neu angelegt
- Ein vollständiges Gutachten beziffert Mengen, Befunde, Risiko und Tool-Coverage
- Ein maßgeschneidertes, produktionsreifes Werkzeug schließt genau diese Lücke
Was es kann
StatusTranslationMigrator — Status-Übersetzungen retten
Bei DC→Cloud gehen die i18n-Übersetzungen von Status-Namen verloren, sodass die Cloud nicht-englischen Nutzern nur noch englische Status anzeigt. Das Werkzeug exportiert die Status-Übersetzungen aus Data Center und mappt sie DC↔Cloud, wobei es direkte und umgekehrte Treffer automatisch erkennt. Anschließend importiert es jede Übersetzung locale-genau zurück — abgesichert durch Validierung und mit Resume, falls ein Lauf unterbrochen wird.
FieldTranslationMigrator — Feld-Übersetzungen wiederherstellen
Übersetzungen von Custom-Field-Namen wie „Kostenstelle" für de_DE gehen bei der Migration verloren, und die Cloud bietet dafür keinen öffentlichen REST-Endpunkt. Das Werkzeug exportiert die DC-Field-Translations und mappt die Felder DC↔Cloud. Den Import schreibt es feld- und locale-genau über einen Endpunkt, der per Browser-Interception ermittelt wurde — mit Resume für sichere Wiederaufnahme.
ElementsConnectConfigMigrator — externe Datenquellen übertragen
Elements Connect (früher nFeed) bindet externe Datenquellen wie SAP, Datenbanken oder REST-APIs in Ihre Felder ein, doch diese Konfiguration wird bei der Migration nicht übernommen. Das Werkzeug exportiert die DC-Datasources und bildet einen Diff gegen den Cloud-Stand, um zu erkennen, was wirklich fehlt. Fehlende Datasources legt es per UI-Automation an — inklusive Kategorie-Mapping, sicherem Auth-Handling und automatischem Retry bei Rate-Limits.
JiraAnalyzer — das Pre-Migration-Gutachten
Eine rein lesende Analyse Ihrer DC-Instanz, die niemals auf Data Center schreibt: Mengengerüst, App- und Custom-Field-Inventar sowie JCMA-artige Befunde. Jeder Befund wird einem konkreten Suite-Werkzeug oder einer Handarbeits-Aufgabe zugeordnet, sodass Sie wissen, wer welche Lücke schließt. Ergebnis ist ein vollständiges Gutachten mit Management-Summary, Mengengerüst, Befunden, Tool-Coverage-Matrix sowie Risiko- und Aufwandsbewertung — als belastbare Grundlage für Scoping, Angebot und Planung, vor dem ersten Schreibzugriff.
BehaviourToForms — ScriptRunner-Behaviours in JSM-Forms
ScriptRunner-Behaviours aus Jira DC haben in der Cloud kein direktes Gegenstück, weshalb dynamische Feldlogik sonst von Hand neu gebaut werden müsste. Das Werkzeug überführt sie vollautomatisch in JSM-Forms (ProForma) — über eine mehrstufige, KI-gestützte Pipeline vom Auslesen der DC-Konfiguration über schema-validiertes Form-JSON bis zum idempotenten, verifizierten Deploy. Der Deploy läuft ausschließlich auf dem Testsystem, geschützt durch eine strikte Prod-Sperre.
Maßgeschneiderte Sonderwerkzeuge — für Lücken ohne Standardlösung
Manche Migrationslücken haben schlicht keine Standardlösung, weil sie aus Ihrer individuellen Konfiguration entstehen. Für genau solche Fälle entsteht ein präzise zugeschnittenes, produktionsreifes Werkzeug — mit Dry-Run, Resume, strukturiertem Logging und Sandbox-First-Betrieb. Diese Eigenschaften teilt jedes Tool der Familie, sodass auch ein Einzelstück denselben Sicherheits- und Qualitätsanspruch erfüllt wie der Rest der Suite.
Häufige Fragen vor der Migration
Schreiben die Analyse-Werkzeuge auf mein Produktivsystem?
Nein. Der JiraAnalyzer arbeitet rein lesend und fasst Data Center nie schreibend an. Alle schreibenden Werkzeuge folgen dem Sandbox-First-Prinzip mit Dry-Run und geprüftem Schreibpfad, sodass Ihr Produktivsystem nie zum Versuchsfeld wird.
Was passiert, wenn ein Lauf mittendrin abbricht?
Die Migrations-Werkzeuge sind auf Resume ausgelegt und nehmen einen unterbrochenen Lauf an der richtigen Stelle wieder auf. So entstehen keine halben Datenstände, und ein zweiter Lauf wiederholt nicht, was bereits erfolgreich übertragen wurde.
Brauche ich alle sechs Werkzeuge oder kann ich einzelne nutzen?
Jedes Werkzeug ist einzeln einsetzbar und löst seine Aufgabe für sich. Im Verbund decken sie zusammenhängende Migrationslücken ab, doch wenn Ihre Instanz etwa keine Elements-Connect-Datenquellen hat, lassen Sie das entsprechende Tool einfach weg.
Meine Lücke ist hier nicht aufgeführt — was dann?
Genau dafür gibt es die maßgeschneiderten Sonderwerkzeuge. Für eine Lücke ohne Standardlösung entsteht ein präzise zugeschnittenes, produktionsreifes Tool, das denselben Eigenschaften folgt wie der Rest der Familie: Dry-Run, Resume, strukturiertes Logging und Sandbox-First.
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.