Custom Migration Tools
Where standard apps and JCMA end, the right special-purpose tool begins: a family of small, sharply tailored tools for the migration gaps the official path quietly leaves open.
- Six real tools for precisely the gaps no standard tool closes
- Usable individually, strong in combination — one consistent tool family
- Sandbox-first throughout, with dry-run, resume and traceable logging
- Dry run before every write
- Checked against Data Center after every stage
- One isolated stack per customer
- The final report names what was skipped, too
A Jira DC→Cloud migration rarely fails on the big picture; it fails on the many small gaps the official path leaves open without a sound: status and field translations that disappear in the Cloud, external data sources that no longer work, or an assessment that is simply missing before the first write. Each of these gaps costs days of manual work after go-live — or only surfaces once users start to complain.
For exactly these points, one precisely tailored tool is built, rather than one overloaded universal tool. Every tool is usable on its own and strong in combination, and all of them follow the same safe principle: sandbox-first, dry-run and a verified write path, so your production system never becomes a testing ground.
What a standard migration leaves open
After a standard migration
- The Cloud shows non-English users only English status names
- External data sources from Elements Connect no longer work in the Cloud
- Migration effort and risk are only estimated before the start
- A rare gap has no standard solution and is left undone
With this tool Custom Migration Tools
- Every status and field translation is restored locale-accurately and validated
- Missing data sources are detected via diff and safely re-created
- A complete assessment quantifies volumes, findings, risk and tool coverage
- A tailored, production-ready tool closes precisely this gap
What it does
StatusTranslationMigrator — rescue status translations
During DC→Cloud the i18n translations of status names are lost, so the Cloud shows non-English users only English statuses. The tool exports the status translations from Data Center and maps them DC↔Cloud, automatically detecting both direct and reverse matches. It then imports every translation back locale-by-locale — protected by validation and with resume in case a run is interrupted.
FieldTranslationMigrator — restore field translations
Translations of custom field names such as "Kostenstelle" for de_DE are lost during migration, and the Cloud offers no public REST endpoint for them. The tool exports the DC field translations and maps the fields DC↔Cloud. It writes the import field- and locale-accurately via an endpoint identified through browser interception — with resume for safe continuation.
ElementsConnectConfigMigrator — carry over external data sources
Elements Connect (formerly nFeed) binds external data sources such as SAP, databases or REST APIs into your fields, yet this configuration is not carried over during migration. The tool exports the DC data sources and builds a diff against the Cloud state to detect what is genuinely missing. It then creates the missing data sources via UI automation — including category mapping, safe auth handling and automatic retry on rate limits.
JiraAnalyzer — the pre-migration assessment
A read-only analysis of your DC instance that never writes to Data Center: volume figures, app and custom field inventory, and JCMA-style findings. Each finding is assigned to a concrete suite tool or a manual task, so you know who closes which gap. The result is a complete assessment with a management summary, volume figures, findings, a tool coverage matrix and a risk and effort rating — a reliable basis for scoping, quoting and planning, before the first write.
BehaviourToForms — ScriptRunner Behaviours into JSM Forms
ScriptRunner Behaviours from Jira DC have no direct counterpart in the Cloud, so dynamic field logic would otherwise have to be rebuilt by hand. The tool converts them fully automatically into JSM Forms (ProForma) — via a multi-stage, AI-assisted pipeline from reading the DC configuration through schema-validated form JSON to an idempotent, verified deploy. The deploy runs exclusively on the test system, protected by a strict production lock.
Tailored special-purpose tools — for gaps without a standard solution
Some migration gaps simply have no standard solution because they arise from your individual configuration. For exactly such cases a precisely tailored, production-ready tool is built — with dry-run, resume, structured logging and sandbox-first operation. Every tool in the family shares these properties, so even a one-off meets the same safety and quality standard as the rest of the suite.
Common questions before migrating
Do the analysis tools write to my production system?
No. The JiraAnalyzer works read-only and never touches Data Center in writing mode. All writing tools follow the sandbox-first principle with dry-run and a verified write path, so your production system never becomes a testing ground.
What happens if a run breaks off midway?
The migration tools are designed for resume and pick up an interrupted run at the right place. This means no half-finished data states arise, and a second run does not repeat what has already been transferred successfully.
Do I need all six tools or can I use individual ones?
Each tool is usable on its own and solves its task by itself. In combination they cover related migration gaps, but if your instance has no Elements Connect data sources, for example, you simply leave out the corresponding tool.
My gap is not listed here — what then?
That is exactly what the tailored special-purpose tools are for. For a gap without a standard solution, a precisely tailored, production-ready tool is built that follows the same properties as the rest of the family: dry-run, resume, structured logging and sandbox-first.
In control — from start to final report
Reading separated from writing
Reads come from a read-only data layer; writes go through a single controlled channel. Read access never burdens your Cloud.
A test run before every write
The dry run shows exactly what would happen. Nothing is written until you explicitly approve it.
Repeatable without risk
Every step can be run again without doing harm. An interruption is no problem, and a second run creates no duplicates.
One isolated stack per customer
All tools run on the Jira Migration Manager platform, fully separated per engagement. No mixing of data.
The final report names every item individually: repaired, to review, skipped or failed. Nothing is silently processed wrong.
Runs on the Jira Migration Manager
This tool does not stand alone. It runs on the platform that unites every tool: a read-only read layer pulls Data Center and Cloud into a versioned snapshot, and every change goes through a single, controlled write gateway.
More on the Jira Migration ManagerMore tools
Jira Migration Manager
The platform that brings every migration tool under one roof and makes a Jira DC-to-Cloud migration safe and repeatable: separate read and write paths, rate-limited into the Cloud, credentials encrypted, one isolated stack per customer.
- Read-only read layer and rate-limited write channel kept strictly separate
- All tools on one shared data base, chainable into pipelines
- Token-secured perimeter, encrypted keystore, one stack per customer
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
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
A fit for your migration?
Describe your case in a few lines — I'll tell you honestly whether and how this tool helps.
Book a callAtlassian ends support for Data Center on 28 March 2029. If you are moving a large, deeply connected environment, plan early rather than late.