I am looking for solutions that will migrate Relates to (child items) to ADO
To migrate “Relates to” (child item) links from another system (like Jira) to Azure DevOps using Exalate, you’ll want to ensure that parent-child relationships and issue links are properly mapped during synchronization.
Here’s how you can approach this:
-
Maintain Hierarchy and Links: Exalate allows you to map and maintain issue hierarchies and links (such as parent-child or “relates to”) between systems. For Azure DevOps, you can use the
parentIdfield to establish these relationships. -
Sample Sync Scripts:
- Outgoing sync (from source system):
replica.parentId = workItem.parentId - Incoming sync (on Azure DevOps):
if (replica.parentId) { def localParent = syncHelper.getLocalIssueKeyFromRemoteId(replica.parentId.toLong()) if (localParent) { workItem.parentId = localParent.id } }
These scripts ensure that the parent-child relationship is preserved when migrating or syncing issues to Azure DevOps.
- Outgoing sync (from source system):
-
Advanced Use Cases: If you need to map more complex hierarchies or different types of links (like “relates to” or custom relationships), you can further customize your sync rules. Exalate’s scripting engine and AI Assist can help generate or refine these scripts for your specific scenario. For more details and examples, check out the documentation on Jira and Azure DevOps integration and how to sync work items with a parent link in Exalate for Azure DevOps.
-
Migration Considerations: While Exalate is primarily an integration tool, it can be used for migration. However, bulk operations may require additional planning due to node size limits and API constraints. See the migration guidelines here: Can I Use Exalate for Migration?.
By customizing your sync rules as shown above, you can migrate “relates to” (child) links into Azure DevOps and maintain the correct relationships between work items.
I have the parent child link done for all the sub tasks but question here is on how to link the relates to Linked work items

any of these
is blocked by, is blocked, etc..
@Ariel_Aguilar appreciate your help here
Hi pradheep,
You may want to take a look at: Jira Cloud Azure DevOps: Bi-directional hierarchy sync
Let me know if you have any further question.
Kind regards,
Ariel
I wanted to follow up—were you able to resolve the issue using the solution @Ariel_Aguilar provided? Please let us know if you need any further assistance.
Thanks,
Sonal
Still the related issue is not resolved. need guidance as i need one way sycn from jira to ADO
Hi @pradheep
Can we have a small screen share session to resolve this? I will provide you the Calendly link where you can book the session. You will find the Calendly information in your “My Messages”.
Thanks,
Sonal
Yes pls share and we can do EST timezone.
Yes already shared in DM
@Sonal_Otwani could you please look into this as this is still open
Hi @pradheep
Could you please remind me where we left off during our last call? I’d like to pick up from there and ensure nothing is missed.
Thanks
Hi @pradheep
I wanted to follow up if you were able to sync linkages using the script provided in our last call?
Thanks,
Sonal
Hi Sonal
Can we setup a call tomorrow to resolve the related to issue. its persisting still and a quick act can fix.
Sonal
I have setup meeting monday.
This is critical and customer had escalated as this is more critical.
Regards
Pradheep
Hi @pradheep
Thanks for joining the call yesterday.
I changed the script, and seems like it is working now .
Can you please validate few issues from Jira to ADO and update me?
Thanks,
Sonal
Hi @pradheep
As you confirmed, the linkages are working now.
Can you please test for 4-5 random workitems from Jira to ADO
Now your question would be why the mapping is not working:
“clones”:“System.LinkTypes.Duplicate-Forward”,
“is cloned by”:“System.LinkTypes.Duplicate-Reverse”,
The mapping itself is conceptually correct in terms of directionality, but it fails during migration because of the topology constraint differences between the two systems. Here’s why:
The Root Cause: Tree vs Network Topology
Jira’s “clones/is cloned by” uses a Network topology — meaning it’s completely flexible, many-to-many, no restrictions. An issue can clone 5 things and be cloned by 10 things simultaneously.
ADO’s System.LinkTypes.Duplicate uses a Tree topology — which enforces these rules:
-
No circular links — if A → B, then B → A is not allowed
-
Only one parent — a work item can only have ONE “Duplicate Of” (reverse) link
-
No chains that form loops — A → B → C → A is rejected
What Breaks During Sync
When the Exalate tries to replay Jira’s clone links using ADO’s Duplicate link type, it will fail whenever it encounters any of these patterns in your Jira data:
| Jira Pattern | Why ADO Rejects It |
|---|---|
| Issue A clones both B and C | A can only be “Duplicate Of” one item |
| A clones B, and B clones A | Circular reference — Tree topology forbids this |
| A clones B, B clones C, C clones A | Indirect circular chain |
Even a single violation in your dataset can cause the migration to error out or silently drop links.
Our Fix
Map Jira’s clone links to System.LinkTypes.Related instead:
json
"clones": "System.LinkTypes.Related",
"is cloned by": "System.LinkTypes.Related"
The Related link type uses a Network topology (just like Jira’s clone links), so it has no restrictions on cardinality or directionality. The trade-off is that you lose the “duplicate” semantic label, but all your links will migrate successfully.
Thanks,
Sonal
Got it. So you have done everything to related?
But when we migrated 1 workitem during our session it was working linking to duplicate of? Where can I see the script. I dont see it in the new exalate.
Email for confirmation is still not there.
Hi @pradheep
I guess we resolved this issue.
Kindly raise another question if you find any further issue.
Thanks,
Sonal
Sonal
Thanks and got it resolved and thanks for your time and effort in resolving.