Extractor
The Extractor reads Jira Data Center and Cloud once, in full, and serves the result as a versioned, read-only data layer — the single source from which every tool in the JMM platform draws the same verified data.
- 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
- 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
Tools that query Jira live for every question are slow and fragile, and they burn through your scarce Cloud API budget. A quieter problem weighs heavier: the official Jira search silently skips every project the API user lacks Browse permission for. Your data is then incomplete, with no error to warn you.
The Extractor pulls Data Center and Cloud once, in full, into a cached, versioned snapshot and serves all of it as a clean read-only API. Every run is blue-green: a snapshot goes live only once it is complete — no partial state ever reaches a downstream tool. The whole platform works from one reproducible truth instead of hitting the Cloud again for every question.
What a standard migration leaves open
After a standard migration
- Every tool queries Jira live — slow and fragile
- Every question burns scarce Cloud API budget
- Projects without Browse permission go silently missing
- The data set varies by tool and point in time
With this tool Extractor
- One versioned snapshot every tool reads from instantly
- Extracted once, read any number of times — no further API load
- An admin path captures all projects, not just the visible ones
- One complete snapshot as the shared source
Three steps to one shared data set
The Extractor never delivers half the data. First it extracts in full, then it reconciles, then it serves — and a snapshot goes live only when it is complete.
-
1
Extraction
The Extractor pulls Data Center and Cloud in a single run, in full, into a versioned snapshot. The run is blue-green: a new snapshot builds in the background and goes live only after it has completed.
Verified: only a complete snapshot goes live
-
2
Reconciliation
From both snapshots the Extractor computes ready DC→Cloud mappings: type-aware for fields, language-aware for priorities, subtask-aware for issue types, structural for object types — plus projects, roles, and users.
Verified: same-named fields of different types stay separate
-
3
Delivery
Data and mappings are available as a read-only API and as export files. Every tool in the platform reads the same verified data from it, without hitting the Cloud again.
Verified: a frozen contract every tool can rely on
What it does
A complete snapshot of DC and Cloud
A single run captures both systems in full: projects, fields, issue types, priorities, roles, permission schemes, automation rules with full payloads, filters, boards, dashboards, screens, Insight/CMDB object types and schemas, and users. You get one closed data set instead of scattered individual queries.
Ready DC→Cloud mappings, not raw data
The Extractor delivers not just data but dependable mappings: field mapping with type awareness (same-named fields of different types are never confused, system fields keyed by stable ID rather than localized name), priorities language-aware (Critical↔Kritisch), issue types subtask-aware, object types resolved structurally, plus projects, roles, and users. That removes manual mapping work and prevents silent mismatches.
Captures projects without Browse permission too
The Extractor reads issue and asset values through an admin path that bypasses the Browse-permission wall of the Jira search. So you capture every project, not just the visible ones — and avoid a silently incomplete migration that would otherwise surface only after the move.
Atomic blue-green versioning
Every run follows the blue-green principle: only a complete extraction goes live, the platform never serves a partial state. Snapshots are reproducible and versioned, and older versions stay available — should you need to compare or roll back.
Read-only with a frozen contract
The Extractor never changes anything, and its outputs are a frozen contract that downstream tools can rely on. Within the JMM it is strictly separated from the write path (Write Gateway): read access never touches your production Cloud budget.
One API, flexible storage
A read-only HTTP API serves all data and mappings consistently. Storage is either a single SQLite file or, via DATABASE_URL, Postgres — without any change to the API. A web setup guides you through import and field mapping on first start.
Common questions before migrating
Why not just query Jira live from every tool?
Live queries are slow and fragile and consume your scarce Cloud API budget on every question. Worse: the Jira search silently skips projects without Browse permission. The Extractor reads everything once and serves it as a stable, cached data set — from then on every tool only queries the Extractor.
How do you make sure every project is captured?
The Extractor reads issue and asset values through an admin path that bypasses the Browse-permission wall of the official search. That captures projects the API user has no Browse permission for too — and avoids an incomplete data set that would only surface after the migration.
Can the platform ever work with half the data?
No. Every run is blue-green: a new snapshot goes live only once the extraction has completed in full. If a run aborts, the previous complete snapshot stays active. Downstream tools never see a partial state.
Does the Extractor change anything in my Jira systems?
No. The Extractor is read-only and its output contract is frozen, so downstream tools can rely on stable results. Within the JMM it is strictly separated from the write path (Write Gateway): reading and writing are deliberately kept apart.
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.