RequestType Sync
Bei Umzügen zwischen JSM-Cloud-Instanzen kommen Request Types oft unvollständig oder anders an — die Lücken fallen erst im Kundenportal auf. RequestType Sync gleicht sie regelbasiert ab, mit Probelauf vor jedem Schreibschritt.
- Formulare und Request-Type-Übersetzungen vollständig migrieren
- Vorgangsansicht, Texte, Icons, Portalgruppen und Zugriff im Abgleich
- Probelauf vor dem Schreiben, Freigabe vorausgesetzt
- Probelauf vor jedem Schreiben
- Nach jeder Stufe gegen Data Center geprüft
- Geschrieben wird erst nach Ihrer Freigabe
- Nachvollziehbarer Abschlussbericht zu jedem Lauf
Bei einem Umzug zwischen zwei Jira-Service-Management-Cloud-Instanzen kommen Request Types und das, was an ihnen hängt, oft unvollständig oder anders an. Formulare fehlen, die Vorgangsansicht weicht ab, Texte und Icons stimmen nicht mehr, Portalgruppen und Zugriffe verschieben sich. Die Lücken fallen meist erst im Kundenportal auf — und bei vielen Request Types wird der Handabgleich schnell fehleranfällig.
RequestType Sync gleicht Request Types zwischen den beiden Cloud-Instanzen regelbasiert ab: Formulare, Vorgangsansicht, Texte und Icons, Portalgruppen, Zugriff, Übersetzungen und der Screen-Aufbau. Workflows, Feldanlage und bestehende Vorgänge fasst das Werkzeug bewusst nicht an. Jeder Lauf liest zuerst und ordnet zu, ermittelt die Abweichungen und zeigt sie in einem Probelauf. Geschrieben wird erst nach ausdrücklicher Freigabe, danach wird gegen die Quelle gegengeprüft. Es arbeitet regelbasiert statt mit KI — bei gleicher Ausgangslage kommt verlässlich das gleiche Ergebnis heraus, nachvollziehbar und ohne Überraschungen.
In geprüften Stufen
Lesen und zuordnen, Abweichungen ermitteln, Probelauf, Freigabe und Schreiben, Gegenprüfen.
-
1
Lesen und zuordnen
RequestType Sync liest die Request Types beider Cloud-Instanzen und ordnet sie einander zu.
-
2
Abweichungen ermitteln
Aus dem Abgleich wird sichtbar, wo Formulare, Vorgangsansicht, Texte, Icons, Portalgruppen, Zugriff, Übersetzungen oder der Screen-Aufbau voneinander abweichen.
-
3
Probelauf
Der geplante Schreibvorgang wird vollständig angezeigt, bevor etwas passiert.
Verifiziert: Nichts wird vor der Freigabe geschrieben.
-
4
Freigabe & Schreiben
Erst nach Ihrer ausdrücklichen Freigabe schreibt RequestType Sync die Abweichungen in die Ziel-Instanz.
-
5
Gegenprüfen
Nach dem Schreiben wird das Ergebnis gegen die Quell-Instanz verifiziert.
Verifiziert: Ergebnis gegen die Quelle geprüft.
Was es kann
Was mitkommt — und was nicht
Im Abgleich: Formulare, Vorgangsansicht, Texte und Icons, Portalgruppen, Zugriff, Übersetzungen und der Screen-Aufbau. Nicht angefasst: Workflows, Feldanlage und bestehende Vorgänge beziehungsweise Inhalte.
Probelauf vor dem Schreiben
Jeder Lauf ermittelt die Abweichungen zuerst und zeigt sie vollständig im Probelauf, bevor etwas geschrieben wird.
Verifikation gegen die Quelle
Geschrieben wird erst nach ausdrücklicher Freigabe. Danach wird das Ergebnis gegen die Quell-Instanz gegengeprüft.
Der Mensch entscheidet
Fachliche Abwägungen und Löschungen trifft immer ein Mensch — was die Plattform nicht zulässt, geht auch mit RequestType Sync nicht.
Häufige Fragen vor der Migration
Werden Formulare und die Übersetzungen der Request Types mit übertragen?
Ja. RequestType Sync überträgt die Formulare und die Übersetzungen der Request Types vollständig — ebenso Vorgangsansicht, Texte, Icons, Portalgruppen und Zugriff. Workflows, Feldanlage und bestehende Vorgänge bleiben bewusst unangetastet.
Werden Workflows oder Felder mitgezogen?
Nein. RequestType Sync gleicht Formulare, Ansichten, Texte, Icons, Portalgruppen, Zugriff und Übersetzungen ab — Workflows, Feldanlage und bestehende Vorgänge fasst es nicht an.
Kann versehentlich etwas überschrieben oder gelöscht werden?
Geschrieben wird erst nach einem Probelauf und Ihrer ausdrücklichen Freigabe. Löschungen entscheidet immer ein Mensch, nie das Werkzeug.
Kontrolliert — von Anfang bis Abschlussbericht
Lesen vom Schreiben getrennt
Gelesen wird aus einer rein lesenden Datenschicht, geschrieben nur über einen einzigen kontrollierten Kanal. Lesezugriffe belasten Ihre Cloud nie.
Testlauf vor jedem Schreiben
Der Probelauf 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 nur lesende Schicht zieht Data Center und Cloud in eine versionierte Momentaufnahme, und jede Änderung geht durch einen einzigen, kontrollierten Schreibweg.
Mehr zum Jira Migration ManagerWeitere Werkzeuge
Migrations-Plattform
Jira Migration Manager
Die Plattform, die alle Migrationswerkzeuge unter einem Dach vereint und eine Jira-Data-Center-zu-Cloud-Migration sicher und wiederholbar macht: getrennte Lese- und Schreibwege, mit gedrosselter Schreibrate in die Cloud, Zugangsdaten verschlüsselt, ein isolierter Stack je Kunde.
- Rein lesende Lese-Schicht und Schreibkanal mit gedrosselter Schreibrate strikt getrennt
- Alle Werkzeuge auf einer Datenbasis, verkettbar zu Abläufen
- 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 Probelauf 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 mit Probelauf als Standard und über einen kontrollierten Schreibweg abgesichert, der nichts doppelt schreibt
Passt das zu Ihrer Migration?
Schildern Sie kurz Ihr Vorhaben — wir sagen Ihnen klar, ob und wo es passt.
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.