Jira Migration Helper
JCMA gets your data into the cloud but leaves the configuration incomplete or broken. Jira Migration Helper repairs these gaps module by module and automates the follow-up with Managed Migration — every step 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
- 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
JCMA reliably migrates the bulk of your data, yet a substantial part of the configuration is left behind or arrives in the cloud broken: saved filters with dead field references, empty dashboards, skipped custom fields and incomplete permission schemes. This is exactly where the Jira Migration Helper comes in, working through this follow-up module by module. Every module runs dry-run by default with a full change log, and write access goes through a rate-limited, idempotent write gateway — so you change your cloud instance in a controlled way and never twice.
New is the Managed Migration: the automation layer above the repair modules. It attaches to a running JCMA migration and automatically runs the right fixes for every project as it is reported finished. This removes the manual rework project by project, and your cloud configuration is ready the moment JCMA is done.
What a standard migration leaves open
After a standard migration
- Saved filters fail in the cloud
- Dashboards are empty, fields and roles are missing
- The rework runs by hand, project by project
- JCMA error logs have to be searched and interpreted by hand
With this tool Jira Migration Helper
- Filters are translated to field IDs and cloud IDs and load again
- Gadgets, skipped fields and permissions are restored
- Managed Migration runs the fixes automatically per finished project
- The log analyzer classifies and fixes automatically where it is safe
In four verified steps
Jira Migration Helper writes nothing blindly. Every module runs dry-run first by default and shows exactly what would happen — writes only go through on your approval. Managed Migration runs these steps automatically for every finished project, every write through the rate-limited, idempotent write gateway.
-
1
Inventory After JCMA
Jira Migration Helper reads the state after the JCMA migration and records what was left behind or broken: dead field references in filters, empty dashboards, skipped fields and incomplete schemes. You see the scope of the rework before anything is changed.
Verified: scope of open rework named and visible
-
2
Repair Module by Module
Each repair module runs in dry-run first and shows exactly what it would change. You approve specifically what should be written; writes go through the idempotent write gateway, so even a repeated run changes nothing twice.
Verified: every change previewed in dry-run and approved
-
3
Managed Migration
The Migration Orchestrator attaches to the running JCMA migration and automatically runs the matching fixes for every project as it is reported finished. A queue with a dependency gate keeps the order, and after an interruption the run cleanly resumes from where it stopped.
Verified: every finished project processed automatically and in the right order
-
4
Verification & Report
After each module, Jira Migration Helper checks the result against the live Cloud API. Skipped cases, ambiguous matches and failures appear, named, in the final report you download as a ZIP — nothing is silently repaired wrong.
Verified: result checked against the Cloud API, everything documented in the report
What it does
Filter & JQL Repair
Makes saved filters cloud-ready again: translates field names to field IDs and cf references, corrects "Customer Request Type" to "Request Type" and remaps references to other filters onto the new cloud IDs. Operators are adjusted (such as = to ~ for text fields), and unsortable ORDER BY clauses are cleaned up so the filter loads at all. A system-clause guard protects valid project= clauses, and filters owned by others are repaired via a safe owner swap.
Dashboard Repair
Brings dashboards back to life: gadget links to filters and fields are translated from DC to cloud IDs and native gadgets are rebuilt. Dead project permissions are cleaned up without ever accidentally over-sharing a dashboard.
Skipped Custom Fields
Creates the fields JCMA skips — such as fields without a screen that are only set via automation or ScriptRunner. Including context and options, even for cascading select fields, so downstream automation and scripts keep working.
Roles & Permission Schemes
Reconciles permission schemes between DC and cloud and adds missing grants with safe holder mapping for users, groups and roles. So after the migration nobody has too much and nobody too little access.
Managed Migration
The Migration Orchestrator attaches to a running JCMA migration and automatically runs the matching repair modules for every project as it is reported finished. A queue with a dependency gate works through the projects in the right order, and a double gate prevents accidental repeat runs. If the run is interrupted, it cleanly resumes from where it stopped instead of starting over.
Logs & Jobs, Automated
The Migration Log Analyzer reads JCMA's error logs, classifies the messages and fixes them automatically where it is safe — the rest it presents, named, for a decision. The Migration Job Manager creates JCMA jobs, starts pre-checks and migration and continuously monitors the status. This lets you steer the entire migration from one place instead of jumping between tools and log files.
Common questions before migrating
Why isn't JCMA alone enough?
JCMA reliably migrates the bulk of your data but leaves a lot of configuration broken or unmigrated — such as filters with dead field references, empty dashboards and skipped fields. Jira Migration Helper closes exactly these gaps module by module. So it is not just the data that is moved, but your cloud instance is usable again.
What does Managed Migration actually do?
Managed Migration is the automation layer above the repair modules. It attaches to a running JCMA migration and automatically runs the right fixes for every project as it is reported finished, in the right order and with resume after an interruption. So you don't have to do the rework by hand or only at the end.
Can the automatic run accidentally break something?
Every module runs dry-run by default and shows in advance what it would change. Write access goes through an idempotent write gateway, so a repeated or resumed run changes nothing twice. A double gate prevents accidental repeat runs, and everything is recorded in the full change log.
How do I operate Jira Migration Helper?
You work either through a token-secured web UI with a live console and ZIP download of the report, or through the CLI. In both cases every module is dry-run by default and keeps a full change log. So you choose between a guided interface and automation in your pipeline, without losing control.
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
Automation Migration
AutomationMigrator
Migrated Jira automation rules often only appear to work in the cloud: scope, field references, triggers and owner break, and some rules never fire. AutomationMigrator compares every rule against its Data Center original and repairs it via API — exactly where standard tools report a broken rule as migrated.
- Repair scope, field references, triggers and owner per rule
- Detect silent rules that exist but never fire
- Show every repair as a dry run first, then write on approval
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.