Zum Inhalt springen
Wolzenburg Consulting
Migration as a Service

Komplexe Atlassian-Migrationen, sauber gelöst.

Wir bringen Ihre Jira- und Confluence-Umgebung vom Data Center in die Cloud — inklusive der Dinge, an denen Standard-Tools scheitern: Automationen, Assets, Structure, Filter und Berechtigungen. Gründlich, nachvollziehbar, jedes Ergebnis gegen das Original im Data Center geprüft.

Instanz-Analyse anfragen Werkzeuge ansehen
  • Data Center → Cloud
  • Erprobung auf Testsystemen, Live nach Validierung
  • Eigene Werkzeuge
migration — dc → cloud 
$ migrate scan --deep
# prüfe Automationen, Assets & Structure …✓ Befunde erkannt — jeder mit Fundort protokolliert
$ migrate fix --apply (staging)
✓ Ergebnisse auf Testsystem geprüft✓ Referenzen neu verknüpft — bereit für Go-Live
Das Problem

Der Umzug ist der einfache Teil

Der native Migrationspfad bringt Projekte, Vorgänge und Anhänge zuverlässig in die Cloud. Bei gewachsenen Data-Center-Instanzen ist damit aber nur der einfache Teil erledigt. Die eigentliche Arbeit beginnt bei allem, was danach unbemerkt nicht mehr funktioniert.

Die meisten Migrationen scheitern nicht am Umzug der Tickets, sondern an dem, was danach kaputt ist.

Automatisierungen

Regeln migrieren als Rohtext. Feld-, Status- und Nutzerreferenzen zeigen ins Leere. Eine Regel steht auf grün und tut trotzdem nichts.

Unser Werkzeug AutomationMigrator gleicht jede Regel gegen ihr Original im Data Center ab und behebt die stillen Brüche — mit Protokoll je Befund. Mehr erfahren

Assets / Insight

Objektschemata, Feldkontexte und Vorgangs-Referenzen brechen. AQL-Abfragen und Asset-Felder verlieren ihren Bezug.

Unser Werkzeug AssetMigrator und Asset Relink stellen Objekte, Felder und Kontexte in der Cloud vollständig wieder her. Mehr erfahren

Filter & JQL

Gespeicherte Filter, Board- und Dashboard-Abfragen verweisen auf Data-Center-interne Felder und IDs, die es in der Cloud nicht mehr gibt.

Unser Werkzeug Das Gutachten deckt tote Filter und JQL-Abfragen auf; die Struktur-Werkzeuge ziehen Filter und Views sauber nach. Mehr erfahren

Strukturen

Structure-Berechtigungen und gespeicherte Views überträgt der offizielle Pfad nicht — sie müssen von Hand nachgebaut werden.

Unser Werkzeug StructureMigrator überträgt Berechtigungen und gespeicherte Views board-genau nach Structure for Cloud. Mehr erfahren

Eigene Felder

Felder ohne Screen-Eintrag, Scripted Fields und Übersetzungen fallen durch das Raster des nativen Pfades.

Unser Werkzeug FieldTranslationMigrator und CustomFieldMerger ziehen Felder, Übersetzungen und Dubletten sauber nach. Mehr erfahren

Berechtigungen

Projektrollen, Permission Schemes und App-Berechtigungen kommen unvollständig an, Rollenmitgliedschaften fehlen.

Unser Werkzeug PermissionSync und der JMH-Reparaturkasten gleichen Rollen und Permission Schemes Schema für Schema ab. Mehr erfahren

Eine grüne Automationsregel ist eine Behauptung, kein Beweis. Aus Erfahrung

Das Ergebnis ist ein Projekt, das formal „durchgelaufen" ist und im Betrieb an unzähligen Stellen nachjustiert werden muss. Der Unterschied zwischen einer Migration, die durchläuft, und einer, die funktioniert, liegt genau in diesen Details.

Migration as a Service

Migration, die auch die schweren Fälle erledigt

Die meisten Migrationen scheitern nicht am Umzug der Tickets, sondern an dem, was danach kaputt ist. Genau dort setzen wir an: Wir übernehmen die technisch anspruchsvollen Teile end-to-end — als Service, mit klaren Zwischenständen.

Kein Datenverlust

Jeder Schritt ist nachvollziehbar und wiederholbar: erst Erprobung auf Testsystemen, Validierung der Ergebnisse, dann der Live-Gang — nie blind.

Tiefe statt Oberfläche

Automationen, ScriptRunner, Assets/Insight, Structure, Filter, Dashboards, Berechtigungen: die Bereiche, die Standard-Migrationen offen lassen.

Mit eigenen Werkzeugen

Eine erprobte Werkzeug-Familie — vereint im Jira Migration Manager — automatisiert Analyse und Reparatur, von der rein lesenden Bestandsaufnahme bis zur projektweise automatisierten Nacharbeit. Die Aufwands- und Kostenrechnung zeigt den Unterschied zu Handarbeit aus der echten Instanz.

So läuft die Migration ab

1

Analyse

Vollständiger Scan von Data Center und Cloud. Wir finden, was nach der Migration brechen wird — bevor es bricht.

2

Migration

Umzug der Inhalte und Konfiguration, abgestimmt auf JCMA und die Besonderheiten Ihrer Umgebung.

3

Reparatur

Automationen, Assets, Structure und Co. werden auf Testsystemen korrigiert und gegen die Cloud verifiziert — mit der Managed Migration pro fertig gemeldetem Projekt automatisch.

4

Go-Live

Abnahme, Live-Migration nach Freigabe und Übergabe mit Bericht. Sie wissen genau, was passiert ist.

Im Fokus

Die Plattform und ihre Spezialwerkzeuge

Zwei Dinge tragen eine Migration: eine Plattform, die alles zusammenhält, und Werkzeuge, die genau dort greifen, wo es schwierig wird.

Plattform

Jira Migration Manager

Alle Werkzeuge laufen im selben, isolierten Stack pro Kunde: Eine nur lesende Schicht zieht Data Center und Cloud in eine versionierte Momentaufnahme, die Werkzeuge arbeiten darauf, und jede Änderung geht über einen einzigen, kontrollierten Schreibweg.

  • Ein isolierter Stack pro Kunde, im eigenen Rechenzentrum
  • Lesen und Schreiben strikt getrennt — kontrolliert und protokolliert
  • Alle Werkzeuge an einem Ort — einzeln nutzbar, im Verbund stark
Zur Plattform
Plattform-Architektur: Jira Data Center mit Exporter → Jira Migration Manager (ein Stack je Kunde, Datenschicht, Gateway) → Jira Cloud
Assets / Insight

Die Asset-Familie

Insight bzw. Assets ist der anspruchsvollste Teil einer Jira-Migration. Drei Werkzeuge greifen ineinander: neu aufbauen, verknüpfen, synchron halten — bis die Objektwelt in der Cloud vollständig und geprüft steht.

  • AssetMigrator — Assets aufbauen
  • Asset Relink — Assets-Migration
  • AssetSync — Assets synchronisieren
Asset-Werkzeuge ansehen

AssetMigrator

Asset Relink

AssetSync

Strukturen

StructureMigrator

Der offizielle Migrationspfad für Structure for Jira überträgt die Board-Hierarchien — aber nicht, wer sie sehen darf und mit welcher Ansicht. StructureMigrator schließt genau diese Lücke, board-genau und gegen Data Center geprüft.

  • Berechtigungen und gespeicherte Ansichten board-genau übertragen
  • Nutzer und Projektrollen automatisch den Cloud-Pendants zugeordnet
  • Probelauf vor jedem Schreibschritt, vorhandene Cloud-Boards bleiben unangetastet
Zu StructureMigrator

Im Überblick

Berechtigungen Gespeicherte Ansichten Projektrollen Board-genau Gegen Data Center geprüft
Service Management

RequestType Sync

Bei Umzügen zwischen JSM-Cloud-Instanzen kommen Request Types oft unvollständig oder anders an. RequestType Sync gleicht sie regelbasiert ab — samt Formularen und Übersetzungen, mit Probelauf vor jedem Schreibschritt.

  • Formulare und Request-Type-Übersetzungen vollständig migriert
  • Vorgangsansicht, Texte, Icons, Portalgruppen und Zugriff im Abgleich
  • Probelauf vor dem Schreiben, Freigabe vorausgesetzt
Zu RequestType Sync

Im Überblick

Formulare Übersetzungen Vorgangsansicht Texte & Icons Portalgruppen Zugriff Screen-Aufbau
Felder & Übersetzungen

Felder und Übersetzungen vollständig in der Cloud

Custom-Field- und Status-Übersetzungen gehören zu den Dingen, die bei einer Standard-Migration zurückbleiben. Zwei Werkzeuge holen sie vollständig in die Cloud — mit einem Mapping aus der Extractor-API statt aus Namensraten.

  • FieldTranslationMigrator — Feld-Übersetzungen
  • StatusTranslationMigrator — Status-Übersetzungen
Felder-Werkzeuge ansehen

Im Überblick

Feld-Übersetzungen Status-Übersetzungen Alle Sprachen Mapping aus Extractor-API
Alle Werkzeuge ansehen
So begleiten wir Ihre Migration

Von der Analyse bis zum Nachweis

Vier Schritte, vier belastbare Ergebnisse — Analysieren, Angebot, Durchführung, Nachweis. Jeder Schritt lässt etwas Greifbares in Ihrer Hand.

1

Analyse & Gutachten

Bevor migriert wird, wissen Sie, was auf Sie zukommt.

Eine rein lesende Bestandsaufnahme Ihrer Instanz bewertet jeden Punkt nach Migrationsaufwand — grün läuft mit, gelb ist zu prüfen, rot ist echte Handarbeit. Ergebnis ist ein verständliches Gutachten, keine endlose Rohdatenliste.

Mehr erfahren
2

Angebot & Kosten

Vom Befund zum nachvollziehbaren Angebot.

Auf Basis des Gutachtens rechnen wir Aufwand und Kosten aus der echten Instanz — Position für Position, mit und ohne Werkzeug-Einsatz. So wird sichtbar, wo Automatisierung Aufwand spart. Das Ergebnis ist ein transparentes Angebot, das wir zu Projektstart gemeinsam mit Ihnen schärfen.

Mehr erfahren
3

Geführte Durchführung

Die Migration Schritt für Schritt — bis zur Abnahme.

Aus Ihren echten Daten entsteht ein Ablaufplan für den Umzug: Reihenfolge, Prüfpunkte, Rückfall-Punkte und eine klare Liste der Nacharbeiten, die kein Standard-Werkzeug automatisch erledigt.

Mehr erfahren
4

Ergebnisnachweis

Schwarz auf weiß: Was ist angekommen?

Nach der Migration ein Bericht pro Objekttyp und Projekt: Abgleich Quelle gegen Ziel, Status auf einen Blick, offene Punkte klar benannt statt beschönigt — die Grundlage für die formale Abnahme.

Mehr erfahren

Analysieren → Migrieren → Nachweisen

So arbeiten wir

Drei getrennte Stacks — vom ersten Test bis zur Produktion

Eine ernsthafte Migration probiert man nicht im Produktivsystem. Deshalb richten wir in der Regel drei vollständig getrennte Umgebungen ein — jede mit eigenem Data-Center- und Cloud-Ziel, jede mit voller Protokollierung über alle Läufe.

  1. 1 Data-Center-Test ↔ Cloud-Sandbox

    Testmigrationen

    Der Stack für die ersten Durchläufe: Machbarkeit prüfen, Werkzeuge einstellen, Umfang und Aufwand aus echten Daten messen — ohne Risiko für irgendein Produktivsystem.

  2. 2 Data-Center-Test ↔ Cloud-Pre-Prod

    Vorbereitung & Abnahme

    Der Stack fürs Grün-Werden: Hier wird gezielt alles auf den Go-Live vorbereitet und wiederholt verifiziert — inklusive Tests, UAT und formaler Abnahme durch Ihr Team.

  3. 3 Data-Center-Prod ↔ Cloud-Prod

    Produktion

    Der finale Stack für den echten Umzug: dieselben, längst erprobten Abläufe — nur jetzt auf den Produktivsystemen, freigegeben und Schritt für Schritt protokolliert.

Drei Stacks, ein durchgängiger Nachweis: Jeder Lauf in jeder Umgebung ist protokolliert und nachvollziehbar. Professionelles Setup statt Migration auf gut Glück.

Der kontrollierte Ablauf

Nichts wird geschrieben, bevor es simuliert, geprüft und freigegeben ist

Jede Migration folgt demselben Ablauf: erst lesen und simulieren, dann gegen das Original im Data Center prüfen — und erst nach Ihrer Freigabe schreiben.

  1. 1

    Analyse

    Ein rein lesendes Gutachten zeigt vor dem ersten Schritt, wo die Migration aufwändig wird.

  2. 2

    Auslesen

    Eine versionierte, rein lesende Momentaufnahme von Data Center und Cloud als gemeinsame Grundlage.

  3. 3

    Probelauf

    Jeder schreibende Schritt wird zuerst vollständig simuliert — ohne dass in der Cloud etwas passiert.

  4. 4

    Verifikation

    Das Ergebnis wird gegen den Data-Center-Stand geprüft. Erst wenn es dem Original entspricht, gilt ein Schritt als tragfähig.

  5. 5

    Freigabe & Schreiben

    Sie geben frei, dann schreibt ein einziger, kontrollierter Schreibweg — mit gedrosselter Schreibrate, ohne etwas doppelt zu schreiben, vollständig protokolliert.

Sandbox first: In der Regel wird erst gegen eine Sandbox migriert und verifiziert, dann die Produktivmigration freigegeben.

Keine KI im Migrationslauf: Der Kern arbeitet vollständig regelbasiert und wiederholbar. Derselbe Eingangsstand führt zum selben Ergebnis — heute wie in drei Monaten.

Eine Migration ist erst dann fertig, wenn auch das Komplizierte wieder läuft — nicht nur die Tickets.
Wolf Wolzenburg
Was uns besser macht

Nachprüfbar bis zur Quelle

Entscheidend ist, dass Sie sich auf das Ergebnis verlassen können. Jede Aussage über Ihre Migration ist belegt und jederzeit nachprüfbar — Sie wissen vorab, woran Sie sind, und können den Erfolg hinterher zweifelsfrei nachweisen: vor Fachbereich, Revision und Geschäftsführung.

Immer dasselbe Ergebnis

Kein Modell rät, nichts wird geschätzt. Dieselbe Instanz führt heute wie in drei Monaten zum exakt gleichen Ergebnis — deterministisch, wie es in der Fachsprache heißt: regelbasiert, wiederholbar, ohne KI im Migrationslauf.

Nachvollziehbar

Jeder Befund ist bis zur Quelle belegt: wo im System das Problem sitzt, warum es eines ist und was dagegen unternommen wird — Fundort für Fundort statt pauschaler Zusicherung.

Lückenlos protokolliert

Über jeden Analyse-, Probelauf- und Schreibvorgang entsteht ein vollständiges Protokoll. Wer wann was verändert hat, bleibt jederzeit prüfbar — bis hinunter auf die Ebene der Revision.

Gemessen statt geschätzt

Umfang und Aufwand kommen aus Ihrer echten Instanz, exakt gezählt — nicht aus Erfahrungswerten oder Daumenregeln. Ein Angebot, das man nachrechnen kann.

Was Sie am Ende in der Hand halten

  • Pre-Migration-Gutachten aus Ihrer echten Instanz
  • Belastbare Aufwands- und Kostenschätzung — gemessen, nicht geraten
  • Runbook für den Migrationstag
  • Verifikationsprotokoll für jeden Schritt
  • Abschlussbericht mit Fundorten und offener Nacharbeit

Die Fragen, die Sie stellen sollten

Setzen Sie KI im Migrationslauf ein?
Nein. Der Kern arbeitet vollständig regelbasiert. KI darf bei der Vorbereitung unterstützen, aber kein Modell entscheidet, was in Ihre Cloud geschrieben wird — sonst wäre das Ergebnis nicht mehr jedes Mal gleich.
Wo liegen unsere Daten während der Migration?
Ihre inhaltlichen Daten verlassen Ihre Systeme nicht — sie verbleiben ausschließlich auf Ihren Data-Center- und Cloud-Instanzen. Bei uns liegen, wenn überhaupt, nur Metadaten und die Verknüpfungsschlüssel (Data-Center-ID ↔ Cloud-ID) — in einem isolierten Stack nur für Sie, in unserem eigenen Rechenzentrum, ohne fremden Cloud-Anbieter dazwischen.
Was passiert, wenn ein Lauf abbricht?
Nichts Unkontrolliertes: Jeder Schreibvorgang ist protokolliert und so abgesichert, dass nichts doppelt geschrieben wird — ein abgebrochener Lauf lässt sich einfach wiederholen. Scheitert etwas grundsätzlich, entsteht ein Befundbericht auf Gutachten-Niveau.

Wir zeigen klar auf, was geht — und lösen dabei deutlich mehr als der native Standardpfad. Belegt, nachvollziehbar, jederzeit mit demselben Ergebnis wiederholbar.

Beratung & Programme

Von der Vision zum Arbeitspaket

Migration ist selten alles. Wir planen und steuern komplexe IT-Vorhaben ganzheitlich — von der Strategie bis zur Umsetzung, technisch fundiert und governance-sicher.

Programm- & Projektaufbau

Vision, Roadmap und Arbeitspakete — Programme und Projekte sauber strukturiert, gesteuert und bis zum „Business as usual" geführt.

Architektur & Governance

Ziel- und Bestandsarchitekturen (TOGAF, ArchiMate), Entscheidungsvorlagen und tragfähige Governance für Cloud und Betrieb.

DSGVO & Compliance

Datenschutz, Datensicherheit und regulatorische Anforderungen von Anfang an mitgedacht — bis hin zu ISO-27001-Themen.

ITSM/ITIL & Adoption

Service-Management nach ITIL, Change und Adoption — damit die neue Lösung nicht nur läuft, sondern auch genutzt wird.

Mehr über unsere Arbeitsweise

In Zahlen

Jahre IT-Transformation & Migration
15+
alle Werkzeuge im Jira Migration Manager
Eine Plattform
jeder Schreibvorgang vorab gegen das Original im Data Center geprüft
Probelauf zuerst
Spezialisierung
Data Center → Cloud
Aus der Praxis

Projekte, an denen wir gerade arbeiten

Vier anonymisierte Migrationsprojekte — und der Umfang, der zeigt, warum der native Pfad hier nicht reicht. Zahlen gerundet, ohne Rückschluss auf den Kunden.

Maschinenbau, international

~3.300 Nutzer · ~250 Projekte · ~500.000 Vorgänge

Umfang

  • ~480 Automationsregeln
  • ~30 Assets-Schemata mit ~470 Objekttypen
  • ~1.100 Custom Fields
  • ~600 JSM-Queues
  • ~130 Workflows

Eine gewachsene Data-Center-Landschaft mit Service Management und Assets für mehrere Gesellschaften — vollständig in die Cloud.

Handels- und Einkaufsverbund

~3.300 Nutzer · ~70 Projekte

Umfang

  • ~200 Automationsregeln
  • ~12 Assets-Schemata mit ~270 Objekttypen
  • ~30 Permission Schemes
  • ~21 Issue-Security-Schemes
  • ~610 Custom Fields

Data Center mit Service Management und Assets — vor der Migration vollständig analysiert und bewertet.

Softwarehersteller, international

~40 Projekte

Umfang

  • ~210 Automationsregeln
  • ~790 Filter
  • ~310 Custom Fields
  • ~90 Request Types

Viele Filter und Automationen im Verhältnis zur Projektzahl — Vorbereitung der Cloud-Migration.

Lebensmittelhandel, Verbund

2 Data-Center-Instanzen · ~270 Projekte

Umfang

  • ~840 Filter
  • ~430 Workflows
  • ~350 Custom Fields
  • ~200 Dashboards
  • ~80 Automationsregeln

Zwei Data-Center-Instanzen mit vielen Projekten und Workflows werden für die Cloud-Migration analysiert.

Die Zahlen beschreiben den Umfang, der sauber in die Cloud muss — gerundet und anonymisiert. Keiner der Fälle ist bisher produktiv umgeschaltet; wir zeigen, was ist, nicht was sich gut liest.
Sicherheit & Betrieb

Ihre Migration läuft in unserem eigenen Rechenzentrum

Keine fremde Cloud, kein geteilter Hoster: Alle Werkzeuge laufen auf eigener, dedizierter Hardware — pro Mandat vollständig getrennt und nach aktuellem Stand der Technik abgesichert.

Ihre Inhalte bleiben bei Ihnen

Inhaltliche Daten verlassen Ihre Systeme nicht — sie verbleiben ausschließlich auf Ihren Data-Center- und Cloud-Instanzen. Bei uns liegen, wenn überhaupt, nur Metadaten und die Verknüpfungsschlüssel (Data-Center-ID ↔ Cloud-ID).

Eigenes Rechenzentrum

Alle Tools laufen in unserem eigenen RZ auf dedizierter Hardware — getrennt von allem anderen, ohne fremden Cloud-Anbieter dazwischen.

Linux & BSD

Durchgängig auf gehärteten Linux- und BSD-Systemen betrieben — schlank, transparent, ohne unnötige Angriffsfläche.

CrowdSec & moderne Security

Abgesichert mit CrowdSec und State-of-the-art-Sicherheitstechnik: aktive Angriffserkennung, Härtung und laufende Überwachung.

Pro Mandat isoliert

Jedes Mandat läuft vollständig separiert auf eigener, nur dafür genutzter Hardware — keine Vermischung von Kundendaten.

CrowdSec M1 M2 M3

Jedes Mandat erhält seine eigene, vollständig getrennte Umgebung — abgeschirmt durch CrowdSec.

Über mich

Wolf Wolzenburg

Ich bin spezialisiert auf Atlassian-Migrationen vom Data Center in die Cloud — und besonders auf die technisch anspruchsvollen Fälle, vor denen viele zurückschrecken. Ein Ansprechpartner, der die Migration selbst fährt: Wo andere abwinken, baue ich das Werkzeug, das die Aufgabe löst.

Hinter der Migration steht ein Trusted Advisor für digitale Transformation: 15+ Jahre internationale Programm- und Projektleitung, ebenso zu Hause bei Microsoft 365, Azure und der Power Platform wie bei Atlassian. Sauber dokumentiert, auf Testsystemen erprobt, ohne böse Überraschungen am Go-Live-Tag.

  • Data Center → Cloud

    Migrations-Fokus

  • Hands-on

    eigener Code & APIs

  • Validiert

    vor dem Go-Live

Wolf Wolzenburg

Wolf Wolzenburg

Trusted Advisor · Atlassian & Microsoft 365 · Programm- & Projektleitung

„Eine Migration ist erst dann fertig, wenn auch das Komplizierte wieder läuft — nicht nur die Tickets.“

Mehr über mich
Kontakt

Migration im Blick? Reden wir darüber.

Ob ganze Migration oder nur die kniffligen Reste: Schildern Sie kurz Ihren Fall — wir melden uns mit einer ehrlichen Einschätzung.

E-Mail schreiben info@wolzenburg.de

Antwort in der Regel innerhalb eines Werktags.