Investigation to migrate from Wush-hosted Jira instance to Atlassian-hosted

Problem to be solved

We investigated a move from hosting of the JIRA server product by our provider Wush.net to cloud hosting by Atlassian, the makers of Jira. The main impetus for the move was that for several developers in Australia, the Wush-hosted JIRA instance seemed painfully slow with load times of several minutes. Tests with partial data load in Atlassian hosted appeared promising, so we decided to start a migration process. We also anticipated saving money over time since Wush charges for hosting services but Atlassian, due to our 100% open source status, does not. Though we did anticipate running the two instances in parallel for a period of time that had not been determined, so anticipated savings would not likely have happened for a while.

Status - on hold

The latest data from the Australian developers indicates that for some reason the performance issues for our Wush-hosted instance have improved significantly and are comparable to the Atlassian cloud hosted Jira. We also learned that 3rd party plug-ins which are free for us to use on the JIRA hosted version are not free on the Atlassian cloud service due to the cost to Atlassian of maintaining hosted services. These 3rd party plug-ins charge per user and looked like it was going to negate any potential cost savings. Due to the lack of any discernable performance difference and a likely increase in cost, it does not make sense to execute a migration for now.

Details for future reference

• The migration entails 3 zipped files: the main backup file, the attachments file and an avatars file. The main backup file can be initiated by an administrator through the GUI, but Wush actually needs to retrieve the backup file and manually zip up the attachments file and the avatars file. The attachments file contains the images and other files connected with JIRA issues, they are essential. Wush had to ftp the files to a shared space for me to retrieve. 
• The import process, which one can initiate through the GUI as an admin, on the Atlassian instance failed with a known issue. But Atlassian was able to get it working. So the process ended up being that I sent the three files to Atlassian support for them to upload, which seemed to work fine. Actually, I did not get a chance to see the results of that avatars upload because Atlassian forgot to import this zip file. 
• The user records, which should come across in the main backup file, failed to import, even with help from Atlassian support. However, there does appear to be a well documented way to move user records over via CSV file and retain permissions. Here is the link to that information - https://confluence.atlassian.com/crowdkb/how-do-i-generate-a-csv-export-of-users-and-memberships-from-a-specific-directory-in-crowd-442271568.html
• There is no limit for active user accounts the JIRA server product but there is a limit on cloud hosting of 2,000 active user accounts. 
• The main 3rd party plug in that might have been difficult to replace or live without was Adaptavist Scriptrunner, which helps us immensely with an automated workflow to transition issues to resolved with the correct fix version automatically. I'm not sure if native JIRA workflow triggers would have worked or not to meet this need. Our 3rd party Git integration probably could have been turned off and we could have managed with the native Git integration. But it is nice to have access to 3rd party plug-ins.

Latest on performance from Australia

Status from one developer in Australia:

 https://sakaiproject.atlassian.net/   13 seconds
 Click "Log in"                        8.2 seconds
 Click  Projects > View All Projects   3.6 seconds
 Click "Sakai" project                 14 seconds
 Click Issues > Search For Issues      4.54 seconds
 Search for "Samigo"                   3 seconds
 Click "SAM-3128"                      3 seconds

Same test on jira.sakaiproject.org (cold cache):

 https://jira.sakaiproject.org/        18 seconds
 Click "Log in"                        3.79 seconds
 Click Projects > View All Projects    6.05 seconds
 Click "Sakai" project                 12 seconds
 Click Issues > Search For Issues      9.21 seconds
 Search for "Samigo"                   4 seconds
 Click "SAM-3116"                      2 seconds

On Atlassian JIRA (cold cache):

 https://sakaiproject.atlassian.net/   10.4 seconds
 Click "Log in”                        8.5 seconds
 Click  Projects > View All Projects   4.38 seconds
 Click "Sakai" project                 13.2 seconds
 Click Issues > Search For Issues      5.38 seconds
 Search for "Samigo"                   2 seconds
 Click "SAM-3128”                      2.6 seconds

On jira.sakaiproject.org (cold cache):

 https://jira.sakaiproject.org/        13.2 seconds
 Click "Log in"                        3.19 seconds
 Click Projects > View All Projects    4.05 seconds
 Click "Sakai" project                 10.7 seconds
 Click Issues > Search For Issues      4.39 seconds
 Search for "Samigo"                   3 seconds
 Click "SAM-3116”                      3.2 seconds

And subjective testing from Steve Swinsberg: 

"I've given the hosted environment a spin and to be honest I can't really tell the difference between that and the wush version that much.

Not sure if the recent version upgrade has done anything but it seems faster recently."