Asset Relink
Moving to the Cloud breaks the links between your assets and your issues. Asset Relink rebuilds them — completely, repeatably, and checked after every step.
- Create fields, contexts and screens in the Cloud
- Translate AQL filters from Data Center to Cloud
- Relink object values on every issue
- 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
Insight/Assets links servers, contracts or components to thousands of issues. A standard migration to the Cloud leaves little of that intact: object IDs change, the asset fields lose their schema binding and their filters, and the values on the issues point nowhere. Fields are suddenly empty or no longer selectable, and asset-driven automations stop firing.
Asset Relink rebuilds this state in full — in three stages. First the fields and their contexts, then the screens and the AQL filters, finally the object values on every single issue. After each stage the tool reconciles the result against the Data Center data. A test run shows exactly what would happen in advance; nothing is written until you approve it.
What a standard migration leaves open
After a standard migration
- Asset fields are empty or no longer selectable
- Saved AQL filters return nothing
- Values on issues point to wrong or missing objects
- Automations around assets no longer fire
With this tool Asset Relink
- Every field is bound to its object schema and fillable
- Filters are translated to Cloud, invalid ones detected and left out
- Every value is relinked via a stable object identifier
- Fields and values are back in place, the logic works again
In three verified stages
Asset Relink writes nothing blindly. Each stage can be repeated as often as needed without doing harm, and is reconciled against the Data Center data once finished. A test run shows exactly what would happen in advance — nothing is written until you approve it.
-
1
Fields & contexts
Asset Relink creates the asset fields in the Cloud and binds each one to the correct object schema. Only that binding turns a present field into one you can actually select and fill.
Verified: Field exists and is correctly bound to the schema
-
2
Screens & AQL filters
Every field is attached to the right screens — per project and issue type, including where it was only filled in the background by automation in Data Center. In parallel, the object filters are translated from Data Center to Cloud; invalid filters are detected and left out.
Verified: Fields on the right screens, valid filters translated
-
3
Relink object values
Asset Relink reconnects every asset value on every issue to the correct Cloud object. Resolution runs over a stable object identifier and in batches, turning hours into minutes.
Verified: every value reconciled against the Data Center source
What it does
Fields and contexts
Creates the asset fields in the Cloud and binds each one to the correct object schema. Only then is a field not just present, but actually selectable and fillable.
Screens and edit forms
Attaches every asset field to the right screens — per project and issue type. Including fields that were only filled in the background by automation in Data Center.
Translate AQL filters
Carries the object filters over from Data Center to Cloud (IQL to AQL). Filters that would be invalid in the Cloud are detected and left out — instead of blocking issue writes later on.
Relink object values
Reconnects every asset value to the correct Cloud object. Resolution runs over a stable object identifier and in batches — what would take hours by hand takes minutes.
Writes even when blocked
If the Cloud API refuses write access, Asset Relink sets the values through a safe Forge route. That way even a field that isn't on the edit form still gets its value.
A check after every stage
After fields, screens and values, Asset Relink reconciles the result against the Data Center data. Ambiguous matches, skipped projects and failures are named in the final report — nothing is silently mislinked.
Common questions before migrating
Will my asset fields end up empty?
In a standard migration, fields lose their schema binding and are no longer selectable. Asset Relink recreates each field, binds it to the correct object schema, and then checks that it is fillable.
Will my saved filters still work?
Asset filters are invalid in the Cloud at first. Asset Relink translates them from IQL to AQL and reports the ones that cannot be carried over cleanly — instead of letting them fail silently.
What happens to my automations?
Automations around assets only fire once fields and values are back in place. That is exactly what Asset Relink restores: as soon as fields are bound and values relinked, your existing logic works again.
And if the Cloud API blocks the write?
For exactly this case there is a safe Forge route. Asset Relink sets the values even where the normal API refuses — and even when the field is not on the edit form at all.
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
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.