AssetMigrator
Insight, or Assets, is the most demanding part of a Jira migration. The AssetMigrator rebuilds your entire object world in an empty cloud tenant — structure, values and links — and proves at the end that everything arrived.
- Schemas, object types and objects fully rebuilt
- Object-to-object links included
- Reconciled against the DC original at the end
- 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
Object schemas, references and the asset values on the issues all have to reach the cloud in full — otherwise queries and automation later run into nothing. The AssetMigrator handles this in a four-stage pipeline: read the Data Center state, bring it offline into a clean creation order, create it in the cloud, and finally check it against the original.
Order is the crux: object types are created parent-first, scalar, status and user values first, then the references including cross-schema resolution. That way all the links hold in the end, not just half of them.
What a standard migration leaves open
After a standard migration
- Assets rebuilt by hand, object by object
- Links break or go missing
- Unclear whether everything really arrived
- Wrong order, half results
With this tool AssetMigrator
- The complete structure built automatically
- Object-to-object references are preserved
- Reconciled against the original with a complete mapping
- Parent-first, prepared deterministically
The four stages
From capture to proof.
-
1
Capture
A snapshot of the object structures is read from the Data Center.
Verified: Read-only, complete state.
-
2
Prepare
All objects are brought offline into a clean creation order.
Verified: Dependencies resolved before anything is written.
-
3
Create
Schemas, object types (parent-first, with attributes) and objects are created, then the references are set including cross-schema resolution.
Verified: Mandatory-field and uniqueness rules applied.
-
4
Verify
The cloud is reconciled against the Data Center original and a complete mapping is written.
Verified: Proof: the cloud matches the original.
What it does
Complete structure rebuilt
Schemas, object types and objects are created in full in the cloud target — not just the shell, but with scalar, status and user values.
Parent-first order
Object types are created in the correct dependency order. What builds on something else is created in that order too.
References included
Reference attributes and reference values are set including cross-schema resolution — the object-to-object links are preserved.
Mandatory fields and uniqueness
Mandatory-field and uniqueness rules are applied rather than quietly skipped.
Checked against the original
At the end the cloud is reconciled against the Data Center original and a complete mapping is written.
Prepared offline, deterministic
The creation order is computed offline from the snapshot — reproducible and independent of the order of inputs.
Common questions before migrating
Does the AssetMigrator work on very large object worlds?
Yes. The creation order is computed offline from the snapshot before anything is written. Precisely with large, interwoven structures this is the decisive difference from doing it by hand.
Are the links between objects preserved?
Yes. After the objects, the reference attributes and reference values are set, including cross-schema resolution. The object-to-object relationships come across in full.
How is it ensured that nothing is missing?
The final stage reconciles the cloud against the Data Center original and writes a complete mapping. Anything that does not match is reported, not skipped.
What if the target already has assets?
The AssetMigrator is designed to build in an empty cloud tenant. For repairing and wiring assets in an already migrated target, Asset Relink is the right tool.
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.