Allow relocation of application links even if the target application is still accessible.

Description

This would be very useful for people migrating off Cloud to Server. In this case, the Cloud instance they are migrating away from is still up, and they obviously have no control over taking it down. However, the new Server applications now need to link to each other. You can set up a new link, but all existing content (eg JIRA Issues Macros in Confluence, links to Confluence pages in JIRA) will still reference the old system and are not updated.

This would also be very useful for people doing server migrations - they want to set up and link the two new servers and test them while their prod servers are still online. For those users, they can bring production down, use the relocate link on the test servers, then bring production back up. This would remove the need for a production outage.

Workarounds

There are two workarounds - either you can force the link to appear by making the server inaccessible (not possible in Cloud), or you can replace the strings in the database.

If the target server is inaccessible, the Relocate link will appear. You can force the server to be inaccessible even while it is up by modifying the hosts file on the source server to contain an entry for the target server that is incorrect. This will make the target server appear offline to the source server, and the 'relocate' link will be available.

Replace the application URLs in the databases

  • Search and replace references to the old application URL in the entities.xml of the export with the new URL, then reimport it.

  • Replace the strings directly in the database:

    1 2 3 4 5 // For content in JIRA update remotelink set url = replace(url, 'https://<cloud-instance>/wiki', 'https://<installed-Confluence-instance>'); // For content in Confluence update bodycontent set body = replace(body, 'https://<cloud-instance>', 'https://<installed-JIRA-instance>');

    NB: The above query is written for Postgres and may need to be modified to work on your db system. Always take a backup before making any changes to the database, and restart the application afterwards.

Environment

None

Testing Notes

None

Status

Assignee

Unassigned

Reporter

Denise Unterwurzacher

Labels

None

Add-on Type

None

Team

None

CC

None

Risk factor

None

QA Kickoff Status

None

QA Demo Status

None

Affects versions

4.0.14
3.10.7
4.1.3
4.2.1

Priority

Major
Configure