Complex Atlassian migrations, done right.
I move your Jira and Confluence environment from Data Center to Cloud — including the parts where standard tools give up: automation, assets, structure, filters and permissions. Technically deep, transparent, with no data loss.
- Data Center → Cloud
- Tested on staging, live after validation
- Purpose-built tools
$ migrate scan --deep # scanning automation, assets & structure …✓ findings detected — each logged with its location $ migrate fix --apply (staging) ✓ results validated on staging✓ references relinked — ready for go-live
Moving the tickets is the easy part
The native migration path moves projects, issues and attachments to the cloud reliably. On grown Data Center instances that only gets the easy part done. The real work begins with everything that quietly breaks afterwards.
Most migrations do not fail at moving the tickets, but at what is broken afterwards.
Automation
Rules migrate as raw text. Field, status and user references point nowhere. A rule shows green and still does nothing.
Our tool AutomationMigrator checks every rule against its DC original and repairs the silent breaks — with a log for each finding. Learn moreAssets / Insight
Object schemas, field contexts and issue references break. AQL queries and asset fields lose their reference.
Our tool AssetMigrator and Asset Relink fully restore objects, fields and contexts in the cloud. Learn moreFilters & JQL
Saved filters, board and dashboard queries point to DC-internal fields and IDs that no longer exist in the cloud.
Our tool The assessment finds every dead query; the structure tools carry filters and views across cleanly. Learn moreStructures
Structure permissions and saved views are not carried over by the official path — they have to be rebuilt by hand.
Our tool StructureMigrator carries permissions and saved views board-accurately to Structure for Cloud. Learn moreCustom fields
Fields with no screen entry, scripted fields and translations fall through the cracks of the native path.
Our tool FieldTranslationMigrator and CustomFieldMerger carry fields, translations and duplicates across cleanly. Learn morePermissions
Project roles, permission schemes and app permissions arrive incomplete, role memberships are missing.
Our tool PermissionSync and the JMH repair kit reconcile roles and permission schemes scheme by scheme. Learn moreA green automation rule is a claim, not a proof. From the field
The result is a project that formally "ran through" and then needs adjusting in countless places in operation. The difference between a migration that runs through and one that works lies exactly in these details.
A migration that handles the hard cases too
Most migrations don't fail at moving the tickets — they fail at what breaks afterwards. That is exactly where I come in: I take on the technically demanding parts end to end, as a service, with clear checkpoints along the way.
No data loss
Every step is transparent and repeatable: first tested on staging systems, results validated, then the go-live — never blindly.
Depth, not surface
Automation, ScriptRunner, Assets/Insight, Structure, filters, dashboards, permissions: the areas a standard migration leaves behind.
With purpose-built tools
A proven family of tools — united in the Jira Migration Manager — automates analysis and repair, from the read-only assessment to per-project automated rework. Faster, more thorough and cheaper than manual work.
How the migration runs
Analysis
A full scan of Data Center and Cloud. I find what will break after the migration — before it does.
Migration
Moving content and configuration, aligned with JCMA and the specifics of your environment.
Repair
Automation, assets, structure and the rest are fixed on staging and verified against the Cloud — with Managed Migration running automatically per finished project.
Go-live
Sign-off, live migration after approval and handover with a report. You know exactly what happened.
One stack for the whole migration: the Jira Migration Manager
Every tool runs in the same stack — the Jira Migration Manager (JMM). A read-only read layer pulls Data Center and Cloud into a versioned snapshot, the specialised tools work on it, and every change goes through a single, controlled write gateway. One isolated stack per customer.
Source
Jira Data Center
Jira Migration Manager
One isolated stack per customer
- Extractor — read layer
- DataManager & Keystore
- Write Gateway — write layer
Target
Jira Cloud
Deliberately conservative by design
- One isolated stack per customer
- Own data centre, no third-party host
- Data-minimal: no tracking, no external services
- Reading and writing strictly separated
Three separate stacks — from first test to production
You don't rehearse a serious migration in production. That's why we typically set up three fully separate environments — each with its own Data Center and Cloud target, each with full logging across all runs.
-
1 DC test ↔ Cloud sandbox
Test migrations
The stack for the first runs: prove feasibility, tune the tools, measure scope and effort from real data — with no risk to any production system.
-
2 DC test ↔ Cloud pre-prod
Preparation & sign-off
The stack for going green: everything is prepared for go-live and verified again and again — including testing, UAT and formal sign-off by your team.
-
3 DC prod ↔ Cloud prod
Production
The final stack for the real move: the same long-rehearsed steps — only now on the production systems, approved and logged step by step.
Three stacks, one continuous record: every run in every environment is logged and traceable. A professional setup instead of migrating on hope.
Nothing is written before it is simulated, checked and approved
Every migration follows the same flow: read and simulate first, then check against the Data Center original — and write only after your approval.
-
1
Analysis
A read-only assessment shows before the first step where the migration gets demanding.
-
2
Extract
A versioned, read-only snapshot of Data Center and Cloud as the shared basis.
-
3
Dry-run
Every writing step is fully simulated first — without anything happening in the cloud.
-
4
Verification
The result is checked against the DC state. Only when it matches the original does a step count as sound.
-
5
Approval & write
You approve, then a single gateway writes — rate-limited, idempotent, fully audited.
Sandbox first: as a rule, migration and verification run against a sandbox before the production migration is approved.
No AI in the migration run: the core works fully rule-based and repeatable. The same input state leads to the same result — today and in three months.
A migration is only done when the complicated parts work again — not just the tickets.
Provable, not just promised
The difference from loose scripts and gut-feel quotes: every tool runs rule-based and repeatable, every assessment is evidenced down to the source, and every run is logged without gaps. You don't have to take our word for it — you can read it back.
Deterministic
No model guesses, nothing is estimated. The same instance yields the exact same result today and in three months — rule-based, repeatable, with no AI in the migration run.
Traceable
Every finding is evidenced down to the source: where the problem sits, why it is one and what is done about it — finding by finding, not a blanket assurance.
Logged end to end
Every analysis, dry run and write produces a complete log. Who changed what and when stays auditable at any time — down to the level your auditors need.
Measured, not estimated
Scope and effort come from your real instance, counted exactly — not from experience values or rules of thumb. A quote you can actually check.
What you hold in your hands at the end
- Pre-migration assessment from your real instance
- Solid effort and cost estimate — measured, not guessed
- Runbook for migration day
- Verification log for every step
- Final report with locations and open follow-up work
The questions you should be asking
- Do you use AI in the migration run?
- No. The core is entirely rule-based. AI may assist in preparation, but no model decides what gets written into your cloud — that would not be reproducible.
- Where does our data sit during the migration?
- Your content never leaves your systems — it stays exclusively on your Data Center and Cloud instances. What sits with us, if anything, is only metadata and the mapping keys (Data Center ID ↔ Cloud ID) — in an isolated stack just for you, in our own data centre, with no third-party cloud in between.
- What happens if a run breaks off?
- Nothing uncontrolled: writes are idempotent and logged, an aborted run can be repeated without writing twice. If something fails fundamentally, you get a findings report at assessment quality.
We show plainly what's achievable — and solve considerably more than the native standard path. Evidenced, traceable, reproducible.
From vision to work package
Migration is rarely the whole story. I plan and steer complex IT initiatives end to end — from strategy to delivery, technically grounded and governance-safe.
Programme & project setup
Vision, roadmap and work packages — programmes and projects cleanly structured, steered and taken through to business as usual.
Architecture & governance
Target and current-state architectures (TOGAF, ArchiMate), decision papers and viable governance for cloud and operations.
GDPR & compliance
Data protection, data security and regulatory requirements considered from the start — through to ISO 27001 topics.
ITSM/ITIL & adoption
Service management per ITIL, change and adoption — so the new solution not only runs but gets used.
By the numbers
- years in IT transformation & migration
- 15+
- purpose-built tools on one platform
- 23
- validated results before go-live
- 100%
- specialisation
- DC→Cloud
Tools that make the migration manageable in the first place
Born out of real migration projects: specialised tools for exactly the parts JCMA and standard procedures leave open. Asset Relink and the Jira Migration Helper with Managed Migration are the flagship products — and all of them run together on one platform, the Jira Migration Manager. Usable on their own, powerful together.
Analysis & quote 2
Pre-migration assessment
JiraAnalyzer
A detailed assessment of your entire Data Center instance before the migration begins: where the move runs smoothly, where it gets difficult, what has to be reworked by hand — and where our tools take that work off your plate.
- Checks every area of the instance, from apps and automation to assets
- Names concretely what gets difficult and what needs manual rework
- Shows for each finding which of our tools covers it
Quote & cost
Effort & cost calculation
Shows, from the real inventory of your instance, where our toolset saves time and budget — and gives you the solid basis for your quote.
- Makes the savings from our tools visible
- Computes from the real inventory, read-only
- An open, transparent calculation
Data layer 3
Read source: Jira
Jira Migration Exporter
The Data Center plugin that supplies the migration with data: across 43 endpoints it delivers the complete configuration picture of your Jira instance — read-only, as the single reliable source for every tool.
- Complete configuration picture across 43 endpoints in 9 areas
- Read-only, no access to ticket content
- Replaces ScriptRunner scripts: usable without ScriptRunner too
Read source: Confluence
Confluence Migration Exporter
The sister plugin for Confluence Data Center: it delivers the complete picture of your Confluence environment — spaces, page tree, permissions, macros and more — read-only, as the reliable source for the Confluence migration.
- Complete picture of the Confluence environment
- Read-only, structure and configuration only
- Shipped signed, checkable at any time
Data layer
Extractor
Otherwise every migration tool queries Jira live — which is slow, fragile, and burns through your scarce Cloud API budget. The Extractor pulls Data Center and Cloud once, in full, into a versioned snapshot and serves it as a read-only API.
- One run pulls DC and Cloud in full into a versioned snapshot
- Read-only API with ready DC→Cloud mappings, type- and language-aware
- Blue-green: only a complete snapshot goes live, never half the data
Assets / Insight 3
Assets Migration
Asset Relink
Migrates Insight/Assets to the Cloud in full: fields and contexts, AQL filters, screens and the object values on every issue. Exactly where standard tools lose the links.
- Create fields, contexts and screens in the Cloud
- Translate AQL filters from Data Center to Cloud
- Relink object values on every issue
Build assets
AssetMigrator
Rebuilds your complete Insight/Assets structure in an empty cloud tenant — including all object-to-object links, in four stages and checked against the Data Center original at the end.
- Schemas, object types and objects fully rebuilt
- Object-to-object links included
- Reconciled against the DC original at the end
Sync assets
AssetSync
Reconciles your assets repeatably from Data Center to the cloud — for staged migrations where the source data still changes during the transition.
- Repeatable DC→Cloud reconciliation via delta
- Create, update, delete — by plan
- Dry run by default, reference relink included
Structures & workflows 2
Structure for Jira
StructureMigrator
Moves your Structure for Jira boards from Data Center to Cloud — including the permissions and saved views that the official migration path leaves behind. Transferred board by board, verified against the Data Center state, with existing Cloud boards left untouched.
- Transfers permissions and views Atlassian doesn't migrate — board by board
- Maps users and project roles to their Cloud counterparts automatically
- Dry-run before every write step, duplicate protection for existing Cloud boards
Workflows
WorkflowMigrator
Moves your workflows to the cloud and works through exactly the break points where the native path leaves the most rework — and writes the procedure down as a runbook entry for the production run.
- Field, status and project references cleanly remapped
- Anything with no cloud equivalent goes into the deviation report
- Fixes error patterns beforehand, recorded as a runbook step
Fields & translations 3
Field translations
FieldTranslationMigrator
Moves the custom-field translations from Data Center to the cloud — with a field mapping straight from the Extractor API instead of guessing names, finding roughly twice as many matches.
- Field translations per language into the cloud
- Field mapping from the Extractor API, no name guessing
- Fields that cannot be matched go into a dedicated review list
Status translations
StatusTranslationMigrator
Moves the status translations from Data Center to the cloud — with a three-pass matching that even finds statuses that cannot be found globally, and records the origin of every match.
- Status translations per language into the cloud
- Three-pass matching, project-specific too
- Origin of every match recorded, gaps reported
Duplicate fields
CustomFieldMerger
Merges duplicate custom fields in the cloud — the right moment to clean up and at the same time the most dangerous, because filters, boards, automation and screens depend on them. Five stages, every write step behind a typed confirmation.
- Duplicate fields merged safely
- All dependencies found beforehand and followed up
- Every write step with a dry run and a typed confirmation
Service Management 2
JSM canned responses
CannedResponseMigrator
Moves the Service Management canned responses from Data Center to the cloud — idempotent, with placeholders remapped and, if Confluence was migrated too, references correctly redirected.
- Canned responses across all service projects
- Idempotent: a second run creates no duplicates
- Placeholders remapped, references redirected to the cloud
JSM queues
JSM-Queue-Repair
Repairs the queries behind the agent queues that point to Data Center-internal IDs after the migration and therefore run empty — precisely, without touching the other settings.
- Empty-running agent queues filled again
- Only the query replaced, everything else stays
- Only after confirmation, end state read back
Control & tracking 1
Control & track the migration
Migration jobs are created, pre-checked and started from within the tools; a read-only status page shows progress even to stakeholders without access. Managed Migration repairs automatically per completed project — the rework begins during, not after.
Repair after JCMA 2
Managed Migration
Jira Migration Helper
JCMA migrates the bulk of your data but leaves configuration broken or unmigrated. Jira Migration Helper closes these gaps module by module and, with Managed Migration, runs the right fixes for each finished project automatically — every one dry-run by default and verified against the live Cloud API.
- Repair filters, dashboards, fields, roles and permissions that JCMA leaves open
- Managed Migration: automatically run the right fixes per project as it finishes
- Web UI or CLI, every module dry-run by default and secured by the idempotent write gateway
Permission schemes
PermissionSync
Reconciles the permissions on both sides scheme by scheme and role by role — with a safety model for the area where a migration does the quietest damage: anything unclear is never deleted, and two emergency stops kick in before every deletion.
- Permissions reconciled scheme by scheme, role by role
- Anything unclear is reported, never deleted
- Two emergency stops before every real deletion
Operations & troubleshooting 1
Source-system control
During the migration your Data Center Jira is continuously monitored and deliberately steered in its operating parameters: start clearance before the run, memory and error monitoring during the migration, a controlled remote restart and an emergency stop. That keeps the source system safely under control at the decisive moment. If a run fails, a findings report at assessment level results.
Runbook & evidence 2
Runbook
Runbook generator
Generates the concrete step-by-step guide for migration day from the real instance inventory — along with an honest list of what stays manual.
- A ready runbook from the real inventory
- Remaining-work list in nine categories
- Visible gaps instead of guessed numbers
Final report
Final report
After the migration it answers the question every project runs into: what did not come across? And for each point it gives the location and the way to repair it — straight into your Confluence as living documentation.
- What is missing, where it is, how to repair it
- From the real migration and remediation logs
- Lands straight in your Confluence, multiply safeguarded
Where Jira Cloud offers no API 1
Production-grade tools without an API
For migration domains where Jira Cloud offers no documented API and no usable endpoints — such as field and status translations, Structure permissions or JSM. This is where full, production-grade tools step in: reproducible, with preview, approval and verification like everywhere in the suite. Sign-in is set up once, after which they run without further intervention. If Atlassian changes the interface, the tool relearns its path instead of being rebuilt.
Your migration runs in our own data centre
No third-party cloud, no shared host: all tools run on our own dedicated hardware — fully separated per mandate and secured to the current state of the art.
Your content stays with you
Content data never leaves your systems — it stays exclusively on your Data Center and Cloud instances. What sits with us, if anything, is only metadata and the mapping keys (Data Center ID ↔ Cloud ID).
Own data centre
All tools run in our own data centre on dedicated hardware — separate from everything else, with no third-party cloud provider in between.
Linux & BSD
Operated entirely on hardened Linux and BSD systems — lean, transparent and with no unnecessary attack surface.
CrowdSec & modern security
Secured with CrowdSec and state-of-the-art security technology: active intrusion detection, hardening and continuous monitoring.
Isolated per mandate
Each mandate runs fully separated on dedicated hardware used only for it — no mixing of client data.
Every mandate gets its own fully separated environment — shielded by CrowdSec.
Wolf Wolzenburg
I specialise in Atlassian migrations from Data Center to Cloud — and especially in the technically demanding cases many shy away from. One person who runs the migration personally: where others wave it off, I build the tool that solves the job.
Behind the migration stands a trusted advisor for digital transformation: 15+ years of international programme and project leadership, as much at home with Microsoft 365, Azure and the Power Platform as with Atlassian. Cleanly documented, proven on staging, with no nasty surprises on go-live day.
-
DC→Cloud
migration focus
-
Hands-on
own code & APIs
-
Validated
before go-live
Wolf Wolzenburg
Atlassian Migration Expert · Wolzenburg Consulting
"A migration is only done when the complicated parts work again too — not just the tickets."
Let's talkMigration on the horizon? Let's talk.
Whether it's a full migration or just the tricky leftovers: describe your case in a few lines — I'll get back to you with an honest assessment.
Usually a reply within one business day.