Anyone knows how to fix broken issue links after migration of Jira Software to cloud?
I am testing migration one of our Jira Software instances to cloud. After migration and after recreating application links to Jira ServiceManagement and another Jira Software instance, I experience that links only works one-way. From the migrated Jira Software they work fine, but from ServiceManagement and the other Jira Software they are broken.
I guess it is because the Jira Software that has been migrated to cloud has got some sort of new ID, and therefore ServiceManagement and the other Jira Software does not "know" that the cloud instance has replaced the server instance.
Atlassian support is referring to some generic processes that is not specific enough for me to fix the issue:
Any help is highly appreciated.
Best Regards
Bo
Solved! Go to Solution.
Thanks Janco. I will keep you advice in mind in case I cannot find any other solution. But I would prefer to avoid doing my own scripts if possible.
Did you try to migrate all the issues from the on-prem to the cloud?
We cannot migrate ServiceManagement due to contractual and GDPR considerations. The other Jira Software is in the cloud already. Still links break.
Hi Bo, sorry to reopen this topic after so long: did you find a solution for this, eventually?
After Server or Data Center to Cloud migrations, broken links are often caused by legacy base URLs still embedded in issue descriptions, comments, custom fields, or Confluence page bodies. These are not always fixed automatically, especially when issue keys changed or tiny URLs were used.
We built Legacy URL Scanner for Jira and Confluence to address this systematically. The app scans content for legacy instance URLs, classifies findings, and applies a rule based replacement pipeline with governance rules, RegExp patterns, and URL mappings.
It also supports automatic issue key resolution via JQL and detects Confluence tiny URLs, which are often missed by standard migration tooling.
This is particularly useful for post migration validation and controlled remediation at scale.
Happy to provide more details if helpful.
We had the same issue, but there is a conveniant solution to this: the Atlassian-Support will do this for you. Keep Googling: there is an help article with SQL-queries you have to run on your Server-instance and send these results to the support. They will do the rest. Migrated 18k tickets and 36k pages half a year before, just found 1 or 2 cases where it did not work out.
Thank you very much, Ralf. Exactly what I need. I will Google, and discuss with Atlassian.
Hi Bo,
You have probably already found the relevant information, but for the benefit of others migrating Confluence to cloud, please refer to the information below.
Once the migration of Confluence to cloud completes, the first step is to run the Macro Repair Tool. It may require running the tool several times until the tool does not prompt for any more repairs. Running until you get an error free result is needed to identify and correct the links within the tool's repair scope.
Using the Jira Macro Repair
https://confluence.atlassian.com/confkb/using-the-jira-macro-repair-1084362152.html
As of January 2023, there is a know bug you should be aware of concerning the Macro Repair Tool. If you find that the Macro Repair Tool keeps prompting for the same repairs, wait 60 minutes to allow for any backend processing that might be running to complete, and try running the Macro Repair Tool again. If it is still prompting to make the same repair, please open a Support ticket with Atlassian. If you have been working with an Atlassian Cloud Migration Manager (CMM), you would need to follow their instructions on opening a Problem Ticket associated with the migration to get the proper assistance.
CONFCLOUD-73050 - Jira Macro Repair needs to be run multiple times after migration
https://jira.atlassian.com/browse/CONFCLOUD-73050
Once the Macro Repair has completed, or while Atlassian Support reviews the macro repair results as noted above, gather the information in the support document referenced below and open a support ticket \ problem ticket with Atlassian Support to run the Confluence Link Repair. Atlassian will need that information to run their link repairs.
After a successful Server to Cloud Migration, URL links are broken in the new Cloud instance
https://confluence.atlassian.com/confkb/after-a-successful-server-to-cloud-migration-url-links-are-broken-in-the-new-cloud-instance-1077781093.html
Please keep in mind that the link repair scripts take a significant amount of time to run, but Atlassian Support will update you when they start the link repairs and usually provide an estimate on when the repairs should complete.
I hope this information is helpful.
Regards,
Paul
Thanks much, Paul. Now, we are not migrating Confluence, only Jira Software, leaving Confluence and Jira ServiceManagement on-premise. Do you have similar information about how to repair broken issue links between:
All help is highly appreciated.
I have some information on Jira link repair, but not much. This was related from one of the Cloud Migration Engineers as part of a similar discussion.
It does not sound like it's helpful, but the Confluence link repair process does make "some" repairs in Jira.
Atlassian is working on enhancements to the post-migration link repair process and they do repair the Jira link as well on a few scenarios as mentioned above.
Also, for the Jira Issues Macro, they have the Jira Macro Repair Tool for Confluence (https://confluence.atlassian.com/confkb/using-the-jira-macro-repair-1084362152.html), which is a tool to fix all Jira Issues Macros after the migration to Cloud.
For reference, you can find a Glossary of Types of Links Resolved by Atlassian Support (https://confluence.atlassian.com/confkb/after-a-successful-server-to-cloud-migration-url-links-are-broken-in-the-new-cloud-instance-1077781093.html).
I hope some of that is helpful.
Paul
Thanks for the additional information. I am glad to see that Atlassian is actually working on improving this! As for the repair tool, it seems like it is only available in the cloud, and thus it is not possible to use it on our on-premise installation, I am afraid.