AssetSync
Not every migration happens on a single cut-over day. When Data Center and cloud run side by side for a while, AssetSync keeps the assets on both sides continuously in sync.
- Repeatable DC→Cloud reconciliation via delta
- Create, update, delete — by plan
- Dry run by default, reference relink included
- 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
In staged migrations the assets in Data Center keep changing while the cloud is already built. AssetSync reconciles both sides repeatably: it determines the delta and applies only the actual changes — create, update, delete — instead of rewriting everything each time.
Every run starts with a dry run that shows what would happen. Nothing is written until you approve it, and a two-stage reference relink restores the object-to-object relationships.
What a standard migration leaves open
After a standard migration
- A full copy on every reconciliation
- Repeated runs create duplicates
- Changes during the transition get lost
- References break when carried over
With this tool AssetSync
- Only the actual delta transferred
- Repeatable, without duplication
- Data Center and cloud stay in step
- A two-stage reference relink restores them
How the reconciliation runs
Repeatable, with dry run and approval.
-
1
Scope & mapping
You set the scope; the DC↔Cloud mapping forms the basis for the reconciliation.
Verified: Only the defined scope is considered.
-
2
Snapshot & delta
Both sides are captured and the delta is determined: what is missing, what changed, what is surplus.
Verified: Differences listed in full.
-
3
Plan & dry run
From the delta a plan is built; the dry run shows in full what would be created, updated or deleted.
Verified: Nothing is written without approval.
-
4
Apply & relink
After approval the changes are applied and the references relinked in two stages.
Verified: Object-to-object relationships restored.
What it does
Delta instead of full copy
AssetSync compares both sides and transfers only the actual differences — created, updated or deleted.
Repeatable without duplicates
The reconciliation can be run as often as needed. A second run creates no duplicates, only the new changes.
Dry run by default
Before every write a dry run shows in full what would happen. Nothing is written until you approve it.
Two-stage reference relink
After the values, the object-to-object references are relinked in two stages, across schemas too.
A clear flow with a plan
Set the scope, mapping, snapshot of both sides, delta, plan, apply — every step traceable.
In progress: return path and scheduling
The DC→Cloud sync is ready for use. In the works are the reverse sync Cloud→Data Center, scheduling and a three-way conflict resolution.
Common questions before migrating
Why do I need AssetSync if there is the AssetMigrator?
The AssetMigrator builds the structure once in an empty target. AssetSync is for afterwards: when the Data Center data keeps changing during a transition and the cloud has to be brought along repeatably.
Does a second run create duplicates?
No. AssetSync works via a delta and a stable mapping. A repeated run transfers only what has changed.
Can I see beforehand what happens?
Yes. The dry run is the default and shows in full what would be created, updated or deleted. Nothing is written until your explicit approval.
Does the reconciliation also go from the cloud back to Data Center?
The path from Data Center to the cloud is ready for use. The reverse sync in the other direction, scheduling and a three-way conflict resolution are in development.
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.