JSM-Queue-Repair
After the migration the queries behind the JSM queues often point to old, DC-internal IDs and run empty. JSM-Queue-Repair puts exactly these queries back in order.
- Empty-running agent queues filled again
- Only the query replaced, everything else stays
- Only after confirmation, end state read back
- Dry run before every write
- Checked against Data Center after every stage
- Nothing is written until you approve it
- A traceable final report for every run
Agent queues are the daily working tool in Service Management. If their queries point to Data Center-internal IDs after the move, the queue runs empty and work stalls. JSM-Queue-Repair replaces the query precisely and leaves all other settings untouched.
Because Atlassian rebuilds this area often, the tool confirms its write path against the real edit form before it writes. Every write is preceded by a dry run, writing happens only after explicit confirmation, and the end state is read back afterwards.
What a standard migration leaves open
After a standard migration
- Queues run empty after the move
- Queries point to dead DC IDs
- A repair risks other settings
- A change written unchecked
With this tool JSM-Queue-Repair
- Queries back in order, queues filled
- Switched to valid cloud references
- Only the query replaced, the rest stays
- Dry run, confirmation, end state read back
Four stages
Set up, confirm the write path, dry run, write.
-
1
Set up
The session is created once in the browser and persists across restarts.
Verified: One-time setup, reproducible thereafter.
-
2
Confirm the write path
The edit form of a queue is used once; the tool aligns the save operation with the stored path.
Verified: A safeguard for an area Atlassian rebuilds often.
-
3
Dry run
The existing state is read, only the query is replaced, and the planned write is shown.
Verified: All other settings stay untouched.
-
4
Write and check
Only after explicit confirmation is it written, then the end state is read back.
Verified: Result checked against the cloud.
What it does
Only the query replaced
Only the query behind the queue is repaired. All other settings stay untouched.
Write path confirmed first
The tool aligns its save operation once against the real edit form — the safeguard for an area Atlassian rebuilds often.
Dry run before writing
The existing state is read and the planned write is shown in full before anything happens.
Only after confirmation
Writing happens only after explicit confirmation. The end state is then read back.
Set up once
The session is set up once and persists across restarts. After that the repair runs reproducibly.
Usable per project
The repair can be run for individual projects instead of having to be permanently active.
Common questions before migrating
Why do the queues run empty after the migration?
Because their queries point to Data Center-internal IDs that no longer exist in the cloud. JSM-Queue-Repair switches the queries to valid cloud references.
Are other settings of the queue changed?
No. Only the query is replaced. All other settings stay untouched.
Why is the write path confirmed first?
Because Atlassian rebuilds this area often. The tool aligns its save operation once against the real form so the repair writes reliably.
Does this have to run permanently on all stacks?
No. The repair is used per project and is deliberately not permanently active on all stacks.
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
Migration platform
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.