Upgrade Path from 5.7.1

[Walter Ades]

Documentation found on upgrade paths seems to say to me that it can be taken straight to 7.2.1 but this fails when trying to remove a database index that it says cannot be found or permissions to DROP do not exist. After rolling back the upgrade process several times I've found that the index in question has either existed or not, created the index named the same way and made sure the account using MSSQL has proper permissions without much success.

Is there a specific path that is recommended such as 5.7.1 > 6.0.1 > 7.0.1 > and to current? Any help would be appreciate! Thank you.

[Nic Brough -Adaptavist-]

I would do 5.7 -> 6.4 -> 7.0 -> 7.target.  And test 5.7 -> 6.4 a lot - if you have any problems, do 5.7 -> 6.0 -> 6.4

The reason for this is that there are a whole batch of gotcha's along that path that are removed by taking smaller steps. 

Do NOT skip 6.something -> 7.0.  7.0 has code in it that upgrades certain data items correctly, but that code is deprecated and removed from 7.1 and above, so if you skip 7, it very subtly corrupts your data in some areas.

One of the most common symptoms of skipping 7.0 is priorities.  They'll work fine, all the way up to 7.8-ish.  After 7.8, they'll also work fine, but you will not be able to create priority schemes!

[Walter Ades]

Thank you kindly for your response. I'll likely just go to 6.0 > 6.4 > 7.0 > current to avoid the gotchas you mention.

I'll report back with details on the attempt.

Thanks again!

[Walter Ades]

Hi again!

Following up to say that the upgrade process from 5.7.1 to 6.0.1 completed successfully. Our site started up and was accessible thus showing content in Confluence. However, after stopping the Atlassian Confluence service in preparation for a migration and then restarting to see where I left off after a week out of the office, I find that the service starts but the site is not available.. When trying to access it my browser basically continues to try and load indefinitely both locally and remotely.

I'm not sure if this is helpful or not but here is what is found in the atlassian-confluence.log before shutdown and after start up:

https://drive.google.com/open?id=1HBOPwU2B0YLIQCT88TxytfHq4Q1WKhHK 

[Walter Ades]

Well... apparently this server spent almost an hour and a half updating Syncrhony components and then became available again. I have no idea of this should be expected at every startup or what.