Broken link between Jira Server and Confluence Cloud

[Simon Sahli]

Hello community,

we have migrated our Confluence instance already from Server to Cloud, however Jira is still on Server and will be migrated soon.

We have now have an issue coming from using these two different environments for which I wanted to ask for your input.
Some Jira tickets link to a Confluence page where they are mentioned. Since the migration these links do not work anymore, since the URL (domain) has changed.
It looks like this on the ticket: (link is invalid)

First of all, is there a way to find all these broken links on the tickets somehow?
And secondly, do you think there is any to repair these links in an automated way?

Thank you in advance!

[Trudy Claspill · Accepted solution]

Hello @Simon Sahli 

To connect Confluence Cloud to an Jira non-cloud instance the Jira non-cloud instance needs to either:

1. Be accessible on the internet with any protective firewall allowing traffic from the Atlassian Cloud IPs, or

2. You have to set up an Application Tunnel. See this documentation:

https://support.atlassian.com/organization-administration/docs/what-are-application-tunnels/

Whichever solution you implement, to update the broken links in Jira will require directly updating your database.

You will also have to determine the new Cloud URLs for each referenced Confluence page since the URLs are changed during the migration. The URL changes are not just to the base URL, but also to Page IDs, so it is not enough to just change the base URL.

Did you open a ticket with Atlassian support to support you during this migration effort? If so, you can work with Atlassian support through that ticket to get information about the SQL queries that need to be executed to collect the data and then update the database.

[Simon Sahli]

Hi @Trudy Claspill,

thanks for your response. The accessibility between Jira Server Confluence Cloud should work well in general, since for some links/ macros it works correctly, but I will still check this option a bit more in detail.

I am not surprised that you suggest the direct update on database approach, I was just hoping it might will be possible without it.
I haven opened a ticket at the Atlassian support yet, but yes I might do that or perhaps just reaching out to our Atlassian partner first, since it´s on their Server for now.

One additional question, in the Cloud I have found the "Jira Macro Repair" menu (see attachment). 
Would that be something that could help for this case?
What does this process actually do and can I just let it run in production without any risks?

[Trudy Claspill]

Before I address your question about the Jira Macro Repair tool I want to talk a bit more about the need to update links.

I work for an Atlassian Partner and have been executing migration of Confluence DC to Confluence Cloud and also reconnecting the Confluence Cloud instance to the Jira DC instance that was not migrated. I have been engaged with Atlassian Support while executing these migrations for clients.

This document addresses the broken links issue:

https://confluence.atlassian.com/confkb/after-a-successful-server-to-cloud-migration-url-links-are-broken-in-the-new-cloud-instance-1077781093.html

When migrating to Confluence Cloud, the base URL is changed. The remainder of the URL is also changed because the URL structure is different on Cloud. The page IDs are changed as the pages are added to Cloud. So, at a minimum, if you don't have a redirection of the original Confluence on-premise base URL to the new Confluence Cloud base URL, you could have broken Confluence links.

Within Confluence you can make links to other pages within the same Confluence. These might be done using relative links that can be found using the Recently Viewed and Search options in the Add Link dialog. However, if you used the Web Link option in that dialog then Confluence pastes the explicit link you provide. If you had any of those in your on-premise instance, those links in your Confluence Cloud instance still reference your on-premise Confluence instance.

In Jira if you had links to pages in your Confluence on-premise instance, those links continue to point to your on-premise instance. If you take your on-premise instance offline you may find those links are then broken.

So, in my experience I have had to work with Atlassian support to provide them with:

1. An extract of pages from the Confluence on-premise instance. They use that to create a map of source pages to Confluence Cloud pages and then update the Confluence Cloud instance if there are explicit links that need to be updated.

2. An extract of Jira issues that have links to Confluence. They use that in combination with the information in #1 to provide back to us database update statements to run against the Jira instance to update the Confluence page references to point to the new Confluence Cloud pages.

If you are working with an Atlassian Partner and they managed your migration to Cloud this is something they should already know about.

Regarding the Jira Macro Repair tool in Confluence Cloud - 

Each Jira Macro you inserted in Confluence on-premise has a reference to the Jira Application link for your on-premise Jira instance. When you migrated Confluence to Cloud, if you had to create a new Application Link to Jira using an Application Tunnel, then those macros are no longer referencing a valid Application Link. The Jira Macro Repair tool looks for Jira Macros that reference an invalid Application Link, and allow you to map those macros to a new, valid Application Link (that you already created in Confluence Cloud).

That tool does not repair explicit URL references outside of Jira Macros.

[Simon Sahli]

Hi @Trudy Claspill

first, thank you very much for your elaborated answer!

I will first inform our Atlassian Partner (that was also partly involved in the Confluence Cloud migration and they owned the on-premise Confluence) with some examples and the information from this thread so that they understand what the problem is too.
Then with you suggestion we can approach Atlassian directly and hopefully we can find a smooth way to solve this.


Concerning the "Jira Marco Repair" tool, I guess this will then be relevant, once we have changed the Jira Server to Cloud. I made myself a reminder for after the Jira migration to let this repair tool run.