StatusTranslationMigrator
The cloud has no official path for status translations either. The StatusTranslationMigrator closes the gap — and takes three routes to match as many statuses as possible.
- Status translations per language into the cloud
- Three-pass matching, project-specific too
- Origin of every match recorded, gaps reported
- 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
Status translations are tricky because the same status can be named differently in different workflows. The StatusTranslationMigrator reads the translation matrix per language, adds the status names from the API and then matches in three passes.
First the direct match, then the reverse route via the already translated label, finally the project-specific resolution for statuses that cannot be found globally. Every match is recorded with its origin, and statuses without an equivalent are reported separately.
What a standard migration leaves open
After a standard migration
- Status translations missing in the cloud
- Same names, wrong match
- Unclear where a translation comes from
- Unfindable statuses drop out
With this tool StatusTranslationMigrator
- Correctly translated per language
- Three-pass matching hits the right status
- Origin of every match recorded
- Resolved project-specifically or reported
Four stages
Export, mapping, merge, import.
-
1
Export
The Data Center translation matrix is read in full per language and supplemented with the status names from the API.
Verified: Complete per language.
-
2
Status mapping in three passes
Direct match, reverse route via the translated label, project-specific resolution.
Verified: Origin of every match recorded.
-
3
Merge
Depending on the type of match the right language version is set, including the English one retroactively where Data Center carries it.
Verified: Statuses without an equivalent reported separately.
-
4
Import
Preview, then write — one request per language across all statuses.
Verified: Completed languages recorded.
What it does
Three-pass matching
Direct match, reverse route via the translated label and project-specific resolution — for statuses that cannot be found globally.
Origin of every match
For each mapping it records which pass it came from. That makes the result checkable.
Gaps reported
Statuses without an equivalent are reported separately, not quietly discarded.
All languages, not just one
The migrator brings every maintained language version into the cloud, the right one depending on the type of match — and also fills in the English label retroactively where Data Center carries it.
Preview before writing
Before the import a preview shows in full what would be set.
One request per language
The cloud expects a single request per language across all statuses — that is exactly how it is written, and completed languages are recorded.
Common questions before migrating
How does the migrator find statuses that cannot be found globally?
Via a third pass that resolves project-specifically. Whatever the direct and reverse match miss is still matched this way.
Can I trace where a translation comes from?
Yes. Every match is recorded with its origin — which of the three passes it came from.
What happens to statuses without an equivalent?
They are reported separately instead of quietly discarded, so you can rework deliberately.
Why only one request per language?
Because the cloud expects it that way: one request per language across all statuses. That is exactly how it is written, and completed languages are recorded.
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.