Extractor
Der Extractor liest Jira Data Center und Cloud genau einmal vollständig aus und stellt das Ergebnis als versionierte, read-only Datenschicht bereit — die gemeinsame Quelle, aus der jedes Werkzeug der JMM-Plattform dieselben geprüften Daten bezieht.
- Ein Lauf zieht DC und Cloud vollständig in eine versionierte Momentaufnahme
- Read-only-API mit fertigen DC→Cloud-Zuordnungen, typ- und sprachbewusst
- Blue-Green: nur ein vollständiger Stand geht scharf, nie halbe Daten
- Dry-Run vor jedem Schreiben
- Nach jeder Stufe gegen Data Center geprüft
- Ein isolierter Stack pro Kunde
- Abschlussbericht nennt auch Übersprungenes
Werkzeuge, die für jede Frage live gegen Jira gehen, sind langsam und fragil und verbrennen Ihr knappes Cloud-API-Budget. Schwerer wiegt ein stilles Problem: Die offizielle Jira-Suche überspringt lautlos jedes Projekt, auf das der API-Nutzer kein Browse-Recht hat. Ihre Datenbasis ist dann unvollständig, ohne dass eine Fehlermeldung darauf hinweist.
Der Extractor zieht Data Center und Cloud einmal vollständig in eine gecachte, versionierte Momentaufnahme und stellt daraus alles als saubere read-only API bereit. Jeder Lauf ist Blue-Green: Erst wenn eine Extraktion vollständig ist, wird sie scharf geschaltet — halbe Datenstände erreichen kein nachgelagertes Werkzeug. So arbeitet die gesamte Plattform auf einer einzigen, reproduzierbaren Wahrheit, statt die Cloud bei jeder Frage erneut zu belasten.
Was eine Standard-Migration offen lässt
Nach der Standard-Migration
- Jedes Tool fragt live gegen Jira — langsam und fragil
- Jede Frage verbrennt knappes Cloud-API-Budget
- Projekte ohne Browse-Recht fehlen lautlos in den Daten
- Der Datenstand ist je nach Werkzeug und Zeitpunkt uneinheitlich
Mit diesem Werkzeug Extractor
- Ein versionierter Stand, aus dem alle Tools sofort lesen
- Einmal extrahiert, beliebig oft gelesen — ohne weitere API-Last
- Ein Admin-Pfad erfasst alle Projekte, nicht nur die sichtbaren
- Eine vollständige Momentaufnahme als gemeinsame Quelle
In drei Schritten zur gemeinsamen Datenbasis
Der Extractor liefert nie halbe Daten. Erst wird vollständig extrahiert, dann abgeglichen, dann bereitgestellt — und scharf geschaltet wird ein Stand nur, wenn er komplett ist.
-
1
Extraktion
Der Extractor zieht Data Center und Cloud in einem Lauf vollständig in eine versionierte Momentaufnahme. Der Lauf ist Blue-Green: Ein neuer Stand entsteht im Hintergrund und wird erst nach vollständigem Durchlauf aktiv.
Verifiziert: nur ein vollständiger Stand wird scharf geschaltet
-
2
Abgleich
Aus beiden Ständen berechnet der Extractor fertige DC→Cloud-Zuordnungen: typbewusst für Felder, sprachbewusst für Prioritäten, subtask-bewusst für Vorgangstypen, strukturell für Objekttypen — dazu Projekte, Rollen und Nutzer.
Verifiziert: gleichnamige Felder verschiedenen Typs bleiben getrennt
-
3
Bereitstellung
Daten und Mappings stehen als read-only API und als Exportdateien bereit. Jedes Werkzeug der Plattform liest daraus dieselben geprüften Daten, ohne die Cloud erneut zu belasten.
Verifiziert: eingefrorener Contract, auf den sich alle Tools verlassen
Was es kann
Vollständige Momentaufnahme von DC und Cloud
Ein Lauf erfasst beide Systeme komplett: Projekte, Felder, Vorgangstypen, Prioritäten, Rollen, Berechtigungsschemata, Automationsregeln mit vollständigen Payloads, Filter, Boards, Dashboards, Screens, Insight-/CMDB-Objekttypen und -schemata sowie Nutzer. Sie haben damit einen geschlossenen Datenstand statt verstreuter Einzelabfragen.
Fertige DC→Cloud-Zuordnungen statt Rohdaten
Der Extractor liefert nicht nur Daten, sondern belastbare Mappings: Feld-Zuordnung mit Typunterscheidung (gleichnamige Felder verschiedenen Typs werden nicht verwechselt, Systemfelder über ihre stabile ID statt über lokalisierte Namen), Prioritäten sprachbewusst (Critical↔Kritisch), Vorgangstypen subtask-bewusst, Objekttypen strukturell sowie Projekte, Rollen und Nutzer. Das spart manuelle Zuordnungsarbeit und verhindert stille Fehlzuordnungen.
Erfasst auch Projekte ohne Browse-Recht
Vorgangs- und Asset-Werte liest der Extractor über einen Admin-Pfad, der die Browse-Berechtigungsmauer der Jira-Suche umgeht. So erfassen Sie wirklich alle Projekte, nicht nur die sichtbaren — und vermeiden eine lautlos unvollständige Migration, die sonst erst nach dem Umzug auffällt.
Atomare Blue-Green-Versionierung
Jeder Lauf läuft nach dem Blue-Green-Prinzip: Erst eine vollständige Extraktion wird scharf geschaltet, nie liefert die Plattform einen halben Stand aus. Stände sind reproduzierbar und versioniert, ältere Versionen bleiben abrufbar — falls Sie vergleichen oder zurückgehen müssen.
Read-only mit eingefrorenem Contract
Der Extractor verändert nie etwas, und seine Ausgaben sind als Contract eingefroren — nachgelagerte Werkzeuge können sich darauf verlassen. Im JMM ist er strikt vom Schreibpfad (Write-Gateway) getrennt: Lesezugriffe fassen Ihr produktives Cloud-Budget nicht an.
Eine API, flexible Speicherung
Eine read-only HTTP-API liefert alle Daten und Mappings einheitlich aus. Gespeichert wird wahlweise als einzelne SQLite-Datei oder per DATABASE_URL auf Postgres, ohne dass sich die API ändert. Ein Web-Setup führt beim Erststart durch Import und Feldzuordnung.
Häufige Fragen vor der Migration
Warum nicht einfach jedes Tool live gegen Jira abfragen?
Live-Abfragen sind langsam und fragil und verbrauchen bei jeder Frage Ihr knappes Cloud-API-Budget. Schwerer wiegt: Die Jira-Suche überspringt lautlos Projekte ohne Browse-Recht. Der Extractor liest einmal vollständig aus und stellt daraus eine stabile, gecachte Datenbasis bereit — alle Tools fragen danach nur noch den Extractor.
Wie stellen Sie sicher, dass wirklich alle Projekte erfasst werden?
Vorgangs- und Asset-Werte liest der Extractor über einen Admin-Pfad, der die Browse-Berechtigungsmauer der offiziellen Suche umgeht. Damit erfassen Sie auch Projekte, auf die der API-Nutzer kein Browse-Recht hat — und vermeiden eine unvollständige Datenbasis, die erst nach der Migration auffallen würde.
Kann die Plattform jemals mit halben Daten arbeiten?
Nein. Jeder Lauf ist Blue-Green: Ein neuer Stand wird erst scharf geschaltet, wenn die Extraktion vollständig durchgelaufen ist. Bricht ein Lauf ab, bleibt der bisherige vollständige Stand aktiv. Nachgelagerte Werkzeuge sehen nie einen unvollständigen Stand.
Verändert der Extractor etwas an meinen Jira-Systemen?
Nein. Der Extractor ist read-only und sein Ausgabe-Contract ist eingefroren, damit sich nachgelagerte Tools auf stabile Ergebnisse verlassen können. Im JMM ist er strikt vom Schreibpfad (Write-Gateway) getrennt: Lesen und Schreiben sind bewusst auseinandergezogen.
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.