Fixing static links between a migrated Confluence Cloud and Jira Data Center instances
Asked by Matt:

We are assessing the possibility of moving from Confluence Data Center to Confluence Cloud. Our previous analysis of this migration had proven that there were still many unknowns with regards to the migration tooling and the fact that 10K user license was still in EAP.

Previously we were told that in order to resolve the URL mismatch we'd need to manually touch and update the Jira database to find and update all references of the old Confluence DC URL to the new Cloud URL.

This is worrisome due to the fact that page ids change during a migration to the cloud platform. So first we are required to map old page ids to new page ids and then manually update each URL reference in the Jira database.

Has there been any movement in the tooling behind this scenario? Is it possible for Atlassian to incorporate this within the migration tool or a full playbook revolving around this scenario?

How have other organizations or partners handled this when migrating one product from server/dc to Cloud while the other remains self-hosted?


Answers:
author: Daniel Eads
body: Hi Matt,

Thanks for raising this question, as there is some active work around Confluence links in Jira. Publicly you can track work here: [MIG-98 Confluence Links in JIRA issues should be updated automatically based on the new applink configurations](https://jira.atlassian.com/browse/MIG-98) . I can confirm that the process today involves manual database queries and touchup. However, we are working on the build-in functionality to fix the links after the migration.

I'd like to make sure I fully understand your use-case. Can you confirm that this will be the ideal state of your applications?:

* Confluence **Cloud** (migrated from DC)
* Jira **Data Center** (not migrated)

As work progresses with addressing application links, making sure we've got your use-case covered will be helpful. More information will be posted on MIG-98 when it's available. I'll also update this thread as appropriate when we have more news.

Thanks,  
Daniel \| Atlassian Support

comments: author: Matt
body: Thank you Daniel for those details! Yes, you understand the layout as we expect it to look with a move to the cloud for Confluence.

A related question, does Atlassian have any plan or insight in helping customers keep link integrity for systems/applications external to the Atlassian ecosystem? My thought here is an app that can be hosted on-prem after a migration to the cloud and does the page id mapping and redirect for the user. This would help us get ahead of thousands of broken links on our intranet.


author: Daniel Eads
body: Hi Matt,

The current method for doing this involves either:

* Leaving the current Server application running, putting all projects/spaces on a read-only permission, and using a banner announcement to let users know to go to Cloud instead (and update their links/bookmarks)  

  OR  

* Applying a 301 at nginx/Apache/etc to catch all requests to the Server application URL and redirect them to Cloud (can result in broken links still in some situations)

On the Atlassian tooling side, [MIG-45 Ability to Set DNS redirection after the migration](https://jira.atlassian.com/browse/MIG-45) looks at this case, but is currently gathering interest. If you have any ideas specific to that suggestion, please add them to the Jira issue!

Thanks for thinking though the move scenarios and asking questions! All input helps round out the corners in the migration process.


Tags: confluence-server

migration-customer-care

server