Zum Inhalt springen
Wolzenburg Consulting
Migration as a Service

Komplexe Atlassian-Migrationen, sauber gelöst.

Ich bringe 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. Technisch tief, nachvollziehbar, ohne Datenverlust.

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 DC-Original 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 DC-interne Felder und IDs, die es in der Cloud nicht mehr gibt.

Unser Werkzeug Das Gutachten findet jede tote Abfrage; 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

Custom Fields

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 der Praxis

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 setze ich an: Ich übernehme 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 read-only Bestandsaufnahme bis zur projektweise automatisierten Nacharbeit. Schneller, gründlicher und günstiger als Handarbeit.

So läuft die Migration ab

1

Analyse

Vollständiger Scan von Data Center und Cloud. Ich finde, 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.

Plattform-Überblick

Ein Stack für die gesamte Migration: der Jira Migration Manager

Alle Werkzeuge laufen im selben Stack — dem Jira Migration Manager (JMM). Eine read-only-Lese-Schicht zieht Data Center und Cloud in eine versionierte Momentaufnahme, die spezialisierten Werkzeuge arbeiten darauf, und jede Änderung geht durch ein einziges, kontrolliertes Schreib-Gateway. Pro Kunde ein eigener, isolierter Stack.

Quelle

Jira Data Center

Lesen (read-only)

Jira Migration Manager

Ein isolierter Stack pro Kunde

  • Extractor — Lese-Schicht
  • DataManager & Keystore
  • Write-Gateway — Schreib-Schicht
Asset Relink Jira Migration Helper AutomationMigrator StructureMigrator + weitere
Kontrolliert schreiben

Ziel

Jira Cloud

Bewusst konservativ gebaut

  • Ein isolierter Stack pro Kunde
  • Eigenes Rechenzentrum, kein fremder Hoster
  • Datensparsam: kein Tracking, keine externen Dienste
  • Lesen und Schreiben strikt getrennt
Mehr zum Jira Migration Manager
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 DC-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 DC-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 DC-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 Data-Center-Original 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

    Extract

    Eine versionierte, read-only Momentaufnahme von Data Center und Cloud als gemeinsame Grundlage.

  3. 3

    Dry-Run

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

  4. 4

    Verifikation

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

  5. 5

    Freigabe & Write

    Sie geben frei, dann schreibt ein einziges Gateway — ratenlimitiert, idempotent, lückenlos auditiert.

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

Nachweisbar, nicht behauptet

Der Unterschied zu losen Skripten und Bauchgefühl-Angeboten: Jedes Werkzeug arbeitet regelbasiert und wiederholbar, jede Bewertung ist bis zur Quelle belegt, und über jeden Lauf wird lückenlos Protokoll geführt. Sie müssen uns nichts glauben — Sie können es nachlesen.

Deterministisch

Kein Modell rät, nichts wird geschätzt. Dieselbe Instanz führt heute wie in drei Monaten zum exakt gleichen Ergebnis — 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-, Dry-Run- und Schreibvorgang entsteht ein vollständiges Log. 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 — das wäre nicht reproduzierbar.
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: Geschrieben wird idempotent und protokolliert, ein abgebrochener Lauf lässt sich wiederholen, ohne doppelt zu schreiben. 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, reproduzierbar.

Beratung & Programme

Von der Vision zum Arbeitspaket

Migration ist selten alles. Ich plane und steuere 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 meine Arbeitsweise

In Zahlen

Jahre IT-Transformation & Migration
15+
eigene Werkzeuge auf einer Plattform
23
geprüfte Ergebnisse vor dem Live-Gang
100%
Spezialisierung
DC→Cloud
Produkte & Werkzeuge

Werkzeuge, die die Migration überhaupt erst beherrschbar machen

Aus echten Migrationsprojekten entstanden: spezialisierte Werkzeuge für genau die Teile, die JCMA und Standard-Verfahren offen lassen. Asset Relink und der Jira Migration Helper mit Managed Migration sind die Hauptprodukte — und alle laufen gemeinsam auf einer Plattform, dem Jira Migration Manager. Einzeln nutzbar, im Verbund stark.

Steuerung & Verfolgung 1

Migration steuern

Migration steuern & verfolgen

Migrationsjobs werden aus den Werkzeugen heraus angelegt, vorgeprüft und gestartet; eine read-only Statusseite zeigt den Fortschritt auch Beteiligten ohne Zugriff. Die Managed Migration repariert pro fertig gemeldetem Projekt automatisch mit — die Nacharbeit beginnt währenddessen, nicht danach.

Betrieb & Troubleshooting 1

Kontrolle im Lauf

Quellsystem-Kontrolle

Während der Migration wird Ihr Data-Center-Jira laufend überwacht und gezielt in seinen Betriebsparametern gesteuert: Startfreigabe vor dem Lauf, Speicher- und Fehlerüberwachung während der Migration, kontrollierter Fernneustart und eine Notbremse. So behalten Sie das Quellsystem im entscheidenden Moment sicher unter Kontrolle. Scheitert ein Lauf, entsteht ein Befundbericht auf Gutachten-Niveau.

Wo Jira Cloud keine API bietet 1

ohne API

Produktionsreife Werkzeuge ohne API

Für Migrationsdomänen, in denen Jira Cloud keine dokumentierte API und keine nutzbaren Endpunkte bietet — etwa Feld- und Status-Übersetzungen, Structure-Rechte oder JSM. Hier setzen vollwertige, produktionsreife Werkzeuge an: reproduzierbar, mit Vorschau, Freigabe und Verifikation wie überall in der Suite. Die Anmeldung wird einmal eingerichtet, danach laufen sie ohne weiteres Zutun. Ändert Atlassian die Oberfläche, lernt das Werkzeug seinen Weg neu, statt neu gebaut zu werden.

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.

  • DC→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 — ich melde mich mit einer ehrlichen Einschätzung.

E-Mail schreiben info@wolzenburg.de

Antwort in der Regel innerhalb eines Werktags.