FieldTranslationMigrator
For field translations the cloud offers no documented standard path. The FieldTranslationMigrator closes that gap — and thanks to a real mapping it matches far more fields than a name comparison.
- Field translations per language into the cloud
- Field mapping from the Extractor API, no name guessing
- Fields that cannot be matched go into a dedicated review list
- 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
Custom-field translations are easily lost in a migration because the cloud has no official path for them. The FieldTranslationMigrator reads the translations via a dedicated Data Center endpoint and places them on the correct cloud field IDs.
The difference is in the mapping: it comes straight from the Extractor API, not from comparing field names. The normalised matching finds roughly twice as many matches as a pure name comparison — and whatever still cannot be matched lands in a dedicated review list instead of nowhere.
What a standard migration leaves open
After a standard migration
- Field translations stay empty in the cloud
- Name comparison matches only half
- Unmatchable fields disappear
- An interruption means starting over
With this tool FieldTranslationMigrator
- Translations transferred per language
- Mapping from the Extractor API, twice as many matches
- The review list makes them visible
- Resume at the point of interruption
Five stages
From export to descriptions.
-
1
Export
All field translations are read via a dedicated Data Center endpoint.
Verified: Read-only, complete per language.
-
2
Field mapping
DC field to cloud field straight from the Extractor API, no name guessing.
Verified: Roughly twice as many matches as a name comparison.
-
3
Merge
The translations are placed on the cloud field IDs; fields that cannot be matched go into the review list.
Verified: Every mapping traceable.
-
4
Import
Preview, then write per language, with resume after interruption.
Verified: Only after approval, completed languages recorded.
-
5
Descriptions
Optional reconciliation of the field descriptions from Data Center to the cloud, again with a preview beforehand.
Verified: Only when explicitly selected.
What it does
Mapping from the Extractor API
The field mapping comes straight from the data layer, not from guessing over field names. The normalised matching finds roughly twice as many matches.
Transferred per language
The translations are placed on the correct cloud field IDs and written per language.
Review list, not silence
Fields that cannot be matched with certainty go into a dedicated review list — visible, not lost.
Preview before writing
Before the import a preview shows in full what would be set. Writing happens only afterwards.
Resume after interruption
The import runs per language and resumes at the point of interruption instead of starting over.
Descriptions optional
On request the field descriptions are reconciled from Data Center to the cloud too, again with a preview beforehand.
Common questions before migrating
Why does the mapping match more fields than a name comparison?
Because it comes from the normalised matching of the Extractor API, not from comparing field names. In practice that finds roughly twice as many matches.
What happens to fields that cannot be matched?
They are not quietly skipped but listed in a dedicated review list so you can decide deliberately.
What if the import breaks off midway?
The import runs per language and resumes at the point of interruption. Languages already done are recorded.
Are the field descriptions transferred too?
On request yes, as a separate, previewable step. Without selection it stays with the translations.
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.