Jira Migration Manager
The Jira Migration Manager is the foundation that unites every migration tool under one roof and makes a Jira DC-to-Cloud migration safe and repeatable over weeks — with separate read and write paths as a safety principle.
- 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
- 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
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
- Insight / Assets
- Automation
- Structure
- Filters, dashboards, fields
Jira Migration Manager
One isolated stack per customerProxy & Portal
Token-secured edge, one tab per tool
Extractor — read layer
Complete, versioned snapshot of DC and Cloud (read-only), including ready-made DC→Cloud mappings
Tool family
All migration tools in the same stack — usable on their own, powerful together
DataManager & Keystore
Versioned intermediate results, encrypted credentials per customer
Write Gateway — write layer
A single write channel: rate-limited, idempotent, fully audited
Target
Jira Cloud
- Assets for JSM
- Automation (repaired)
- Structure (migrated)
- Filters & dashboards
Reads and writes are separated: read access never touches the Cloud budget, every change flows through the gateway in a controlled, logged way — and is checked against the Data Center source.
Migrating Jira Data Center to the Cloud is not a single button press but a chain of many steps over weeks — against a Cloud with hard API rate limits and with data you cannot afford to lose. Standalone scripts hit Jira live for every question, burn through scarce API budget and leave no traceable record. What is missing is the foundation that holds the whole chain together.
The Jira Migration Manager provides that foundation and unites every tool under one roof. The principle runs through everything: a read-only read layer pulls your data in once and completely, a versioned data manager holds the intermediate results, and a rate-limited write gateway is the only way back into the Cloud — all behind a token-secured perimeter, credentials in an encrypted keystore, one isolated stack per customer.
What a standard migration leaves open
After a standard migration
- Loose scripts hit Jira live for every question
- Writes run unchecked into the Cloud's rate limits
- Credentials lie scattered across scripts and logs
- Each step on its own, with no record and hardly repeatable
With this tool Jira Migration Manager
- One read-only snapshot serves every tool
- A write gateway holds the limits and retries safely
- All access encrypted in the keystore, separated per customer
- Chained pipelines, every change simulatable and logged
One thread in four stages
The Jira Migration Manager guides every migration along the same controlled path: first read, then match, then process, finally write under control. Reading and writing are kept strictly apart. Every write change runs through the write gateway — rate-limited, idempotent, simulatable and logged.
-
1
Read without risk
The Extractor pulls Data Center and Cloud in once and completely as a versioned snapshot. From then on every tool works from this frozen data base, so the reads never burden the Cloud a second time. Reading is separate from writing and cannot change anything.
Verified: a complete, versioned snapshot is in place
-
2
Match
From the snapshot the platform builds reliable DC-to-Cloud mappings that account for type and language. Fields that share a name but differ in type are not confused, and priorities are matched language-aware. That settles what belongs where before any later write.
Verified: type- and language-aware mappings are settled
-
3
Process
The platform's tools build on one another and store their intermediate states in the DataManager. A tool reuses the previous one's output instead of recomputing a step. This produces repeatable pipelines with traceable intermediate states.
Verified: intermediate states versioned in the DataManager
-
4
Write under control
Every change goes through the write gateway, which holds to Atlassian's rate limits and handles 429 responses and retries itself. Calls are idempotent, can be simulated beforehand as a dry run, and are then recorded in a complete audit trail. You keep the approval for the real run.
Verified: every change rate-limited, idempotent and logged
What it does
Extractor: read-only read layer
The Extractor pulls Data Center and Cloud in once and completely as a versioned snapshot. Every tool works from this frozen data base instead of hitting the Cloud again for each question. It delivers ready-made DC-to-Cloud mappings rather than raw data. Reading is thereby kept risk-free and separate from writing.
Write gateway: controlled writes
The write gateway is the single write channel into the Cloud and holds to Atlassian's rate limits through a global token bucket. It handles 429 responses and retries automatically, so no run fails on an exceeded limit. Every call is idempotent — a repeat never changes anything twice. A dry run shows every planned change in advance, and every executed change is recorded in a complete audit trail.
DataManager: the pipeline's working memory
The DataManager is the migration's named, versioned working memory and holds the intermediate results of each tool. One tool builds on the output of the previous one instead of recomputing every step. Tools can thereby be chained into repeatable pipelines. Every state stays versioned and traceable.
Keystore: encrypted credentials
The Keystore holds all credentials encrypted (Fernet) and kept separate per customer. No token ever sits in code or logs, where it could leak by accident. The per-customer separation prevents data or access from being mixed across tenants. Every credential stays where it belongs.
Proxy & portal: one perimeter
Proxy and portal form a single, token-secured perimeter in front of all tools. The web interface gives each tool its own tab, so you configure and follow jobs without terminal access. The platform runs internally and is not exposed on the open network. That leaves exactly one controlled entry point instead of many open endpoints.
Tool family on the platform
The specialized tools come together on the platform: Asset Relink, Jira Migration Helper, AutomationMigrator, StructureMigrator and more. They all use the Extractor's data as their input and the write gateway as their output, instead of each opening its own path into the Cloud. They thereby share one data base and a single security model. Each tool stays usable on its own and is stronger in concert.
Common questions before migrating
Will the migration overload our Cloud instance?
No. Reading happens only once into a snapshot, after which queries no longer burden the Cloud. Writing goes exclusively through the write gateway, which runs a global token bucket against Atlassian's rate limits and handles 429 responses and retries itself.
What happens if a run breaks off or is repeated?
The write gateway's calls are idempotent — a repeat never changes anything twice and creates no duplicates. You can safely restart a run. The intermediate states in the DataManager remain versioned, so processing continues where it left off.
Can we see what happens before writing for real?
Yes. Every write step can be simulated as a dry run and shows each planned change in advance without changing anything. You keep the approval for the real run. After execution, every change is recorded in a complete audit trail.
How are multiple customer migrations kept apart?
Each customer gets its own isolated stack with its own keystore. Data and access are therefore never mixed across tenants. The credentials sit encrypted in the keystore and never appear in code or logs.
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.
More tools
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
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.