Problems importing Jira Software 6.4 into Jira Cloud

[sedwards]

All I want to do is get our Jira Server 6.4’s data of Projects and Issues imported into Jira Cloud, that is the end goal.   

I will list the steps I have gone through so far to try to get it there and the problems I have run into. I am now stuck and have no other ideas on how to proceed. Any advice would be helpful.

This article has steps on how to migrate from Server to Cloud:
https://confluence.atlassian.com/cloud/migrate-from-jira-server-to-jira-cloud-972349848.html

- Step 3: Back up your Jira Server Database  (“Database Backup”)

- Step 4: Back up your Jira Server attachments (“Attachments Backup”)

- Step 5: Import your server into Jira Cloud (“Jira Cloud Restore”)

((Our Jira Server is version 6.4 on a Windows 10 machine))

I did the Database Backup and Attachments Backup, then did the Jira Cloud Restore.

Got this error message:

“JIRA must be version 7.0+ for import so start over and install 7.0 upgrade to .11 then re-export and try again”

So I found where to download Jira 7.0, installed it, rebooted our server…  

((Our Jira Server is now upgraded to version 7.0, from version 6.4))

I did the Database Backup and Attachments Backup, then did the Jira Cloud Restore.

When on Jira Cloud, I browse the Projects and the data is all there. I browse the Issues, there are NO ISSUES IMPORTED.

I found this forum post suggesting that you must actually have version 7.6 (not 7.0) to prevent the issue of no issues being imported:

https://confluence.atlassian.com/adminjiracloud/importing-issues-776636788.html

So I found where to download Jira 7.6, installed it, rebooted our server…  

((Our Jira Server is now upgraded to version 7.6, from version 7.0))

Localhost:8080 has an error, I view the error logs to find:

No JRE_HOME or JAVA_HOME environment variable is set - attempting to just run 'java' command
'"java"' is not recognized as an internal or external command, operable program or batch file.

Related support issue: https://jira.atlassian.com/browse/JRASERVER-21502

I find that JAVA is not installed on the server. I have to now install JAVA. I find that we need JDK 1.8 which translates to Java SE version 8. I install Java SE 8.

I run the config.bat and can now click “Save” (per support issue instructions in above url).  

Now our localhost:8080 Jira server loads and I can get back to the localhost “System” page to backup the Jira Server.

I did the Database Backup (and named it “JiraSystemBackupData_7dot6.zip”) and Attachments Backup, then did the Jira Cloud Restore… and get the error message:

Import error

There was an error importing file JiraSystemBackupData_7dot6.zip. Following issues were reported:

Cannot complete the import because one of the import files contains failed upgrade taskrecords: '73011'. Search the Atlassian Administrator Knowledge Base for instructions on how to fix this, or contact Atlassian Support for help.

I have looked and looked and can not figure out how to fix this “73011” error. So now I’m stuck.

For any Atlassian staff who may read this: So far, this has been a very painful and seemingly unnecessarily difficult process to do what seems like should be such a simple task: export data from server, import data to cloud. It’s just a list of Projects, Issues, and associated users. Why are there so many hoops to jump through?

[Andy Heinzer · Accepted solution]

Hi,

Sorry to hear about the frustrations here.  I can see that you are running an older version of Jira and are wanting to migrate this data into a Cloud site.  As you have discovered, our Cloud platform does not support importing directly from backups created from these older unsupported versions of server.  We have an expectation that your data will have been updated to the most current version of server available prior to migrating to Cloud.  As of today for Jira Server, that is 8.13.0.

In turn it will be necessary to complete at least two upgrades to get your data in a state that will be ready to imported to Cloud.  All older versions of Jira need to pass through the upgrade of a Jira 7.0.x version as this was a major change.  Once that upgrade is successful, you should then be able to upgrade to the latest 8.13.0 version. It sounds like the 7.0.x upgrade was successful here, but that in the process of trying to go to 7.6.x, you appear to have a failed upgrade task with the id of 73011. 

I did some searching on this error and found a few different support cases where this has happened.  In those other cases it appears that this happened because Jira attempted to make some SQL command changes to the database that were not supported on the older database versions that were running Jira.  In turn we always recommend that when you do an upgrade to Jira that you first check to make sure that you are meeting the Supported Platforms listed for that version.  You will notice that this document has a version selector on the top right corner of the page.  The 7.6 version of that document might be helpful for this specific case.  I recall a few other support cases where we saw this commonly happen on MS SQL 2008 or older databases.  The particular upgrade task in question here is trying to use a SQL command that is not possible to execute in that version of SQL.  However since that version was deprecated back in 7.2 if memory serves, this only became a problem during upgrades to newer versions where that database was no longer supported.

From this point, I would try using the backup from the 7.0.x version of Jira and then create a new database being sure to select a database type/version that is supported for the version that you want to upgrade to.   Postgresql 9.6 is a supported platform for both Jira 7.6.x and 8.13.x.  So that is my ideal database candidate to use in my view, but of course you can pick any database type/version from that supported platforms page.

I would recommend trying the following steps:

1. Fresh install of Jira 8.13.0,
2. Choose a supported database from supported platforms for 8.13
3. Setup that database per the appropriate guide found in Connecting Jira applications to a database.
4. Use the Jira config tool to connect Jira to this new, empty database and save changes
5. Start Jira (when Jira starts connected to an empty database, it launches the setup wizard)
6. Before doing anything else, restore your file attachments to the $JIRAHOME/data/ directory.  This is important because there are potential upgrade tasks that happen between these major versions upgrades that can rename the attachment filenames Jira stores as flat files.  If those files are not in place in the correct directory at the time that upgradetask runs, you could end up with broken attachments in Jira
7. You can then use the setup wizard and choose the option to 'import existing data'  This prompts you to select the XML .zip file which should be copied to the $JIRAHOME/import/ folder.
8. You might need to apply a valid license at the time of this upgrade in order to continue this import.  If needed generate an evaluation Server license for Jira Software/Jira Service Desk from https://my.atlassian.com

This should have the affect of upgrading Jira to 8.13.0 on a supported platform with all your data.  Provided this is successful, you can then generate a new XML backup zip file here and use that in the process to import to Cloud.

Please try these steps and let me know if you run into any more problems here.  Again, sorry to hear that it feels like a lot of hoops to jump through to get your data into Cloud.  But I think these steps are necessary in order to maintain the integrity of your data.  A lot of the database structures in Jira have changed significantly since 6.4 and our Cloud platform is not expected to be able to support imports from end of life versions of Jira Server.

Let me know how it goes.

Andy

[sedwards]

Thank you for your thorough detailed reply. I have tried following those steps but ended up at the exact same end result:  no issues found in Jira Cloud.

• I did a fresh install of 8.13  with a fresh clean database (sql 2016)
• I imported the data and all projects and issues showed up in Jira Server (yay!) so my local 8.13 jira appears to be working correctly 
• I backed up the data into a new .zip file from 8.13, and the backup appears to have been successful. 
• I restored Jira Cloud from the 8.13 .zip backup.
• All of the projects imported
• None of the issues imported << SAME ISSUE I ran into before that made me think I need to upgrade from 7.0 to 7.6 before backing up local data into .zip to import into cloud

The reason I think none of the issues imported is because if I am at Jira Cloud, and I choose any project to see its "Issues" page, I see "No issues were found matching your search" as the default home page of the issues page. This makes me think there are no filters applied and the default search result is to show all issues, that there are no issues at all.


Assuming that the 8.13 local is a valid database, and the backup is a valid backup, can you think of any reason a successful import could cause issues to be hidden from me if I am logged in as the only administrator user? Is there some funky security settings I'm unaware of? Can't think of any other reason to cause this.  

I am open to suggestions on how to try to get the issues to import correctly, or to be able to view them on Jira Cloud.

Thanks

[Andy Heinzer]

Jira Cloud won't apply secret security settings.  But if the Jira Server issues were using Security Schemes, then those would schemes be imported as well by this method, and your Cloud administrator account might not necessarily meet the criteria needed to view those issues.  So while it is possible the issues exist in Cloud right now, and you can't see them because of issue security, but that's not really a common scenario.

Also there might be another more common factor here in that this appears in Jira Cloud Free plan where you are trying to do this import into.  The Free plans in cloud have a number of limitations as noted in https://support.atlassian.com/jira-cloud-administration/docs/what-is-the-free-jira-cloud-plan/

To avoid that as a potential complicating factor, it might be best to upgrade your Cloud site to an evaluation of the Standard plan, at least temporarily to complete this migration.  At least when Jira Cloud is in this standard level, you can make adjustments to project roles, permission schemes, etc that you cannot do when Jira is using the Free plan.

However before you do that, I would want to first confirm that the initial upgrade from Jira 6.4 to 7.0 worked.  Such as by confirming that you see those issues in Jira 7.0 and it appears to be working there.  If so, then I would also want to confirm that the upgrade to 8.13 worked, and you can see the Jira issues in that version as well, before creating a new backup there to be used in Cloud.

[sedwards]

I checked the issues and they appear to be working (they exist, I can browse any individually to review all comments and timestamps), after both upgrades: 7.0 and 8.13

[sedwards]

Thank you, your suggestions fixed the problem.

Upgrading to the Standard plan trial (from Free plan), then importing the projects/issues data, resulted in issues showing up.

After that, downgrading back to free, means we don't pay anything for Standard since it was a trial duration, and our issues still show up.

[sedwards]

@Andy Heinzer 

Found another problem I am hoping you might be able to help answer:

All of the Projects and their Issues imported successfully into the cloud except for the Service Desk issues.

A project called Service Desk with the abbreviation prefix of "DESK" exists in both our old system (8.13 local version) and in the cloud import.

In the 8.13 local version, I can see all of the issues. In the cloud, there are no issues associated with DESK.

Any ideas or suggestions?

[Andy Heinzer]

Sorry for the late response here.  But those issues should still be on the Cloud site.  The most likely explanation is that Service Desk project has a different permission scheme that does not grant 'browse' access to your specific account.  

I would check to see what the browse permission is set to for that project first.  Provided your account is a member of the group or project role, you should at least be able to see these issues via a JQL search.  However when viewing the project itself, it is possible you would not have a view of issues inside the queues unless you were a licensed Agent in Service Desk (which has recently been rebranded Jira Service Management)

[sedwards]

I reviewed the "people" for that Service Desk project (/plugins/servlet/project-config/DESK/people) and discovered that the account I am logging in with does not have any explicitly defined rights, but other users were imported that have various access levels.

When I attempt to "Add People" button, choose my email address to find my user account, then try to assign myself to ANY role and then click "Add", in the bottom left of the screen an error message pops up saying "Something went wrong, Project not found". and so my user account doesn't get added.

^ I have also changed our account from Free to Standard (trial), logged out and logged back in, and no effect, still can't add myself to be an Administrator.

[sedwards]

I logged in as one of the users that was imported as "Administrator" to the Service Desk project. I also see no issues when logged in as that user.

When you say check the "browse permissions", where do I go to see that and what am I attempting to look for or change to help this problem?

Also when I visit the "Customer Permissions" admin page "/jira/servicedesk/projects/DESK/settings/customer-permissions" the page says "An error occurred, An error occurred while loading this page", and shows nothing else. Not sure if that is relevant.

[sedwards]

Ah! We don't have Jira Service Manage (the cloud Service Desk product) installed at all.. seems like that could be why we have this problem.

https://www.atlassian.com/try/cloud/signup?bundle=jira-service-management&edition=free

[sedwards]

After installing the 30 Day trial of the Jira Service Desk Management, because it said we can't use free if we have 10 users or 3 agents, I was still unable to add my username as a new Admin for the Service Desk project via the People editor page. I also still see no issues no matter who I am logged in as.

I decided to delete the Service Desk "DESK" project and do a fresh import in case the installation of the Jira Service Manager might help an import now succeed.

Now when attempting to import the previous 8.13 backup from our Jira Client, a new error message I've never seen before shows up and import fails:

Import error

There was an error importing file JiraSystemBackupData_8dot13.zip. Following issues were reported:

• We can't complete your upgrade. It looks like the data you are trying to import is from an earlier version of Jira Service Management. You need to upgrade to Jira Service Management 3.0 first, then export new data and try again. Read these upgrade notes for instructions: external.link.jira.confluence.upgrade.guide.for.old.service.desk.version.jsm
  
  
  
  @Andy Heinzer  Any idea what the "external.link.jira.confluence.upgrade.guide.for.old.service.desk.version.jsm" was meant to point to? seems like a bug in the import display that should be showing a url instead.

[Andy Heinzer]

Hi,

It sounds like the Jira Service Desk (JSD) data in that backup was not updated in previous upgrades.  There is a mandatory upgrade to Jira Service Desk 3.0 from any older version before you can then go to any higher version.  This minimum version upgrade is noted in the Jira Service Desk 3.2 release notes.

The problem with this is that you can only do that upgrade to JSD 3.0.x when Jira Core (or Jira Software) is running a 7.0.x version, and no other versions of Jira.  Which means that you will need to go back to the Jira 6.4 version you had, which likely had a Service Desk 1.x or 2.x version it was using, and then do an upgrade to a 7.0.x version of Jira first.

While on that 7.0.x version, you need to make sure to then also install Jira Service Desk 3.0.x so that this upgrade of the Service Desk data can occur. JSD will also need to have a valid license applied to it in order to do this upgrade, but you can generate an evaluation license over at https://my.atlassian.com in order to do that if need be. Once that happens, and this JSD project is working, you can then upgrade from that Jira 7.0.x/JSD 3.0.x version up to the latest version of 8.13.x/JSD 4.13.x.  

From there you can then import that data into Cloud.

Alternative to this approach would be to try to delete/drop all the previous Jira Service Desk specific AO tables from the SQL database, and then generate a new backup file.  This approach would keep the Jira issues themselves in JSD projects, but would lose all JSD specific data such as SLAs, JSD Automation, request types, etc.  We had a number of users find frustration at this upgrade requirement and for those admins that don't really want that old JSD data, it is possible (but unsupported) to remove it.  More details can be found in the customer comments in JSDSERVER-4732.  I only mention this approach because it could save you the hassle of having to redo two upgrades here if you really don't want/need that old JSD data for some reason.  If you need that data, then you will have to go back to the Jira 6.4 backup and perform these upgrades anyways.

Let me know if you have any concerns or questions about either approach to get past this latest problem.

Andy

[sedwards]

I'm curious to learn more about option #2. There are a lot of SQL tables that start with "AO" in our "jiradb" database. Only some of them, or all of them should be deleted? If only some, how can I find out exactly which ones?

Current list of our AO_  table names in case it helps you skim them to give input:


AO_0A5972_NOTIFICATION_SETTING
AO_0A5972_PUSH_REGISTRATION
AO_0AC321_RECOMMENDATION_AO
AO_21D670_WHITELIST_RULES
AO_21F425_MESSAGE_AO
AO_21F425_MESSAGE_MAPPING_AO
AO_21F425_USER_PROPERTY_AO
AO_2C4E5C_MAILCHANNEL
AO_2C4E5C_MAILCONNECTION
AO_2C4E5C_MAILGLOBALHANDLER
AO_2C4E5C_MAILHANDLER
AO_2C4E5C_MAILITEM
AO_2C4E5C_MAILITEMAUDIT
AO_2C4E5C_MAILITEMCHUNK
AO_2C4E5C_MAILRUNAUDIT
AO_2F1435_HEALTH_CHECK_STATUS
AO_2F1435_PROPERTIES
AO_2F1435_READ_NOTIFICATIONS
AO_38321B_CUSTOM_CONTENT_LINK
AO_3B1893_LOOP_DETECTION
AO_4789DD_HEALTH_CHECK_STATUS
AO_4789DD_PROPERTIES
AO_4789DD_READ_NOTIFICATIONS
AO_4789DD_TASK_MONITOR
AO_4AEACD_WEBHOOK_DAO
AO_54307E_AGENTSIGNATURES
AO_54307E_ASYNCUPGRADERECORD
AO_54307E_CAPABILITY
AO_54307E_CONFLUENCEKB
AO_54307E_CONFLUENCEKBENABLED
AO_54307E_CONFLUENCEKBLABELS
AO_54307E_CSATENTRIES
AO_54307E_CUSTOMGLOBALTHEME
AO_54307E_CUSTOMTHEME
AO_54307E_EMAILCHANNELSETTING
AO_54307E_EMAILSETTINGS
AO_54307E_GOAL
AO_54307E_GROUP
AO_54307E_GROUPTOREQUESTTYPE
AO_54307E_IMAGES
AO_54307E_METRICCONDITION
AO_54307E_PARTICIPANTSETTINGS
AO_54307E_QUEUE
AO_54307E_QUEUECOLUMN
AO_54307E_REPORT
AO_54307E_SERIES
AO_54307E_SERVICEDESK
AO_54307E_STATUSMAPPING
AO_54307E_THRESHOLD
AO_54307E_TIMEMETRIC
AO_54307E_VIEWPORT
AO_54307E_VIEWPORTFIELD
AO_54307E_VIEWPORTFIELDVALUE
AO_54307E_VIEWPORTFORM
AO_550953_SHORTCUT
AO_563AEE_ACTIVITY_ENTITY
AO_563AEE_ACTOR_ENTITY
AO_563AEE_MEDIA_LINK_ENTITY
AO_563AEE_OBJECT_ENTITY
AO_563AEE_TARGET_ENTITY
AO_575BF5_DEV_SUMMARY
AO_575BF5_PROCESSED_COMMITS
AO_575BF5_PROVIDER_ISSUE
AO_575BF5_PROVIDER_SEQ_NO
AO_587B34_GLANCE_CONFIG
AO_587B34_PROJECT_CONFIG
AO_5FB9D7_AOHIP_CHAT_LINK
AO_5FB9D7_AOHIP_CHAT_USER
AO_60DB71_AUDITENTRY
AO_60DB71_BOARDADMINS
AO_60DB71_CARDCOLOR
AO_60DB71_CARDLAYOUT
AO_60DB71_COLUMN
AO_60DB71_COLUMNSTATUS
AO_60DB71_DETAILVIEWFIELD
AO_60DB71_ESTIMATESTATISTIC
AO_60DB71_ISSUERANKING
AO_60DB71_ISSUERANKINGLOG
AO_60DB71_LEXORANK
AO_60DB71_LEXORANKBALANCER
AO_60DB71_NONWORKINGDAY
AO_60DB71_QUICKFILTER
AO_60DB71_RANKABLEOBJECT
AO_60DB71_RAPIDVIEW
AO_60DB71_SPRINT
AO_60DB71_STATSFIELD
AO_60DB71_SUBQUERY
AO_60DB71_SWIMLANE
AO_60DB71_TRACKINGSTATISTIC
AO_60DB71_VERSION
AO_60DB71_WORKINGDAYS
AO_723324_CLIENT_CONFIG
AO_723324_CLIENT_TOKEN
AO_733371_EVENT
AO_733371_EVENT_PARAMETER
AO_733371_EVENT_RECIPIENT
AO_7A2604_CALENDAR
AO_7A2604_HOLIDAY
AO_7A2604_WORKINGTIME
AO_97EDAB_USERINVITATION
AO_9B2E3B_EXEC_RULE_MSG_ITEM
AO_9B2E3B_IF_COND_CONF_DATA
AO_9B2E3B_IF_COND_EXECUTION
AO_9B2E3B_IF_CONDITION_CONFIG
AO_9B2E3B_IF_EXECUTION
AO_9B2E3B_IF_THEN
AO_9B2E3B_IF_THEN_EXECUTION
AO_9B2E3B_PROJECT_USER_CONTEXT
AO_9B2E3B_RSETREV_PROJ_CONTEXT
AO_9B2E3B_RSETREV_USER_CONTEXT
AO_9B2E3B_RULE
AO_9B2E3B_RULE_EXECUTION
AO_9B2E3B_RULESET
AO_9B2E3B_RULESET_REVISION
AO_9B2E3B_THEN_ACT_CONF_DATA
AO_9B2E3B_THEN_ACT_EXECUTION
AO_9B2E3B_THEN_ACTION_CONFIG
AO_9B2E3B_THEN_EXECUTION
AO_9B2E3B_WHEN_HAND_CONF_DATA
AO_9B2E3B_WHEN_HANDLER_CONFIG
AO_A0B856_WEB_HOOK_LISTENER_AO
AO_A44657_HEALTH_CHECK_ENTITY
AO_AC3877_RL_USER_COUNTER
AO_AC3877_SETTINGS_VERSION
AO_AC3877_SYSTEM_RL_SETTINGS
AO_AC3877_USER_RL_SETTINGS
AO_B9A0F0_APPLIED_TEMPLATE
AO_C16815_ALERT_AO
AO_C77861_AUDIT_ENTITY
AO_CFF990_AOTRANSITION_FAILURE
AO_E8B6CC_BRANCH
AO_E8B6CC_BRANCH_HEAD_MAPPING
AO_E8B6CC_CHANGESET_MAPPING
AO_E8B6CC_COMMIT
AO_E8B6CC_GIT_HUB_EVENT
AO_E8B6CC_ISSUE_MAPPING
AO_E8B6CC_ISSUE_MAPPING_V2
AO_E8B6CC_ISSUE_TO_BRANCH
AO_E8B6CC_ISSUE_TO_CHANGESET
AO_E8B6CC_MESSAGE
AO_E8B6CC_MESSAGE_QUEUE_ITEM
AO_E8B6CC_MESSAGE_TAG
AO_E8B6CC_ORG_TO_PROJECT
AO_E8B6CC_ORGANIZATION_MAPPING
AO_E8B6CC_PR_ISSUE_KEY
AO_E8B6CC_PR_PARTICIPANT
AO_E8B6CC_PR_TO_COMMIT
AO_E8B6CC_PROJECT_MAPPING
AO_E8B6CC_PROJECT_MAPPING_V2
AO_E8B6CC_PULL_REQUEST
AO_E8B6CC_REPO_TO_CHANGESET
AO_E8B6CC_REPO_TO_PROJECT
AO_E8B6CC_REPOSITORY_MAPPING
AO_E8B6CC_SYNC_AUDIT_LOG
AO_E8B6CC_SYNC_EVENT
AO_ED669C_SEEN_ASSERTIONS
AO_F1B27B_HISTORY_RECORD
AO_F1B27B_KEY_COMP_HISTORY
AO_F1B27B_KEY_COMPONENT
AO_F1B27B_PROMISE
AO_F1B27B_PROMISE_HISTORY

[Andy Heinzer]

There is a specific subset of tables to drop.  Check out this comment on that JAC ticket, and this other comment.  Again, if you try this method, I would recommend first stopping Jira, creating a database backup with native database tools, and then you can run those SQL commands to alter that database.

If this works, you can then start up Jira again, and generate a new XML backup.  It might be possible to then import that backup into Cloud instead.  However if this does not work, please understand that this kind of data manipulation is not supported by Atlassian.  While I believe this can work to quickly work-around this problem if you do not wait that JSD specific data here, ultimately the supported method for doing this is to first upgrade that data to a Jira 7.0/JSD 3.0 version where the proper upgradetasks can be run to update that data in the expected manner.

There have also been other threads about this same problem, such as https://community.atlassian.com/t5/Jira-Service-Management/Jira-Service-Desk-unable-to-create-project/qaq-p/740346 that offer a more comprehensive set of steps you can follow here.

Andy

[sedwards]

For the sake of sharing:  after stopping the Jira service, then running the SQL scripts found in both of the links provided (same page, different comments that suggest exactly which tables to drop), then backing it up and attempting a cloud restore from that backup file:   same result as before with an error message when attempting to import: "We can't complete your upgrade. It looks like the data you are trying to import is from an earlier version of Jira Service Management. You need to upgrade to Jira Service Management 3.0 first, then export new data and try again. Read these upgrade notes for instructions:"

So I will try the 2nd suggestion of starting over the installation upgrade steps but including the service desk installer upgrade as well as part of those steps.  Installation steps planned:

Install Jira 6.4
restore database
Install Jira 7.0
Install JSD 3.0
get valid license eval from my.atlassian.com
Install jira 8.13
Install JSD 4.13
backup 8.13+4.13 into zip
restore to cloud

[Steve Edwards]

Step 0: Uninstall Jira. Delete all files/folders in old Jira install directory. Reboot server.
Step 1: Install Jira 6.4
- I have tried this with "Jira" only as the 1st option during initial install
- I have tried this with "Jira + Service Desk"
Step 2: restore 6.4 data backup to import Projects, Issues, and Service Desk data
Step 3: install Jira 7.0
Step 4: Install JSD 3.0
Step 5: Install Jira 8.13. Run config.bat to reapply SQL database config. Reboot server.
Step 6: Install JSD 4.13

Using the above steps for reference, I can never get past Step 5 because Jira localhost:8080 won't even load any more after I have completed Step 5.  When reviewing the atlassian.log file to figure out why, this seems to be the reason:


********************************************************************************************************************************************************************************************************
___ FAILED PLUGIN REPORT _____________________

5 plugins failed to load during Jira startup.

'com.atlassian.servicedesk.project-ui' - 'JIRA Service Desk Project Plugin' failed to load.
Cannot start plugin: com.atlassian.servicedesk.project-ui
Unable to resolve com.atlassian.servicedesk.project-ui [182](R 182.0): missing requirement [com.atlassian.servicedesk.project-ui [182](R 182.0)] osgi.wiring.package; (osgi.wiring.package=com.atlassian.servicedesk.api.license) [caused by: Unable to resolve com.atlassian.servicedesk [178](R 178.0): missing requirement [com.atlassian.servicedesk [178](R 178.0)] osgi.wiring.package; (osgi.wiring.package=com.atlassian.jira.plugins.workinghours.api.calendar) [caused by: Unable to resolve com.atlassian.jira.plugins.workinghours [128](R 128.0): missing requirement [com.atlassian.jira.plugins.workinghours [128](R 128.0)] osgi.wiring.package; (&(osgi.wiring.package=com.atlassian.activeobjects.external)(version>=0.19.0)(!(version>=3.0.0)))]] Unresolved requirements: [[com.atlassian.servicedesk.project-ui [182](R 182.0)] osgi.wiring.package; (osgi.wiring.package=com.atlassian.servicedesk.api.license)]

It was loaded from C:\Program Files\Atlassian\Application Data\JIRA\plugins\installed-plugins\servicedesk-project-ui-plugin-3.0.0.jar

'com.atlassian.servicedesk.plugins.automation.servicedesk-automation-modules-plugin' - 'Service Desk Automation Modules Plugin' failed to load.
Cannot start plugin: com.atlassian.servicedesk.plugins.automation.servicedesk-automation-modules-plugin
Unable to resolve com.atlassian.servicedesk.plugins.automation.servicedesk-automation-modules-plugin [180](R 180.0): missing requirement [com.atlassian.servicedesk.plugins.automation.servicedesk-automation-modules-plugin [180](R 180.0)] osgi.wiring.package; (osgi.wiring.package=com.atlassian.servicedesk.api.comment) [caused by: Unable to resolve com.atlassian.servicedesk [178](R 178.0): missing requirement [com.atlassian.servicedesk [178](R 178.0)] osgi.wiring.package; (osgi.wiring.package=com.atlassian.jira.plugins.workinghours.api.calendar) [caused by: Unable to resolve com.atlassian.jira.plugins.workinghours [128](R 128.0): missing requirement [com.atlassian.jira.plugins.workinghours [128](R 128.0)] osgi.wiring.package; (&(osgi.wiring.package=com.atlassian.activeobjects.external)(version>=0.19.0)(!(version>=3.0.0)))]] Unresolved requirements: [[com.atlassian.servicedesk.plugins.automation.servicedesk-automation-modules-plugin [180](R 180.0)] osgi.wiring.package; (osgi.wiring.package=com.atlassian.servicedesk.api.comment)]

It was loaded from C:\Program Files\Atlassian\Application Data\JIRA\plugins\installed-plugins\servicedesk-automation-modules-plugin-1.2.0.jar

'com.atlassian.jira.plugins.workinghours' - 'JIRA Working Hours Plugin' failed to load.
Cannot start plugin: com.atlassian.jira.plugins.workinghours
Unable to resolve com.atlassian.jira.plugins.workinghours [128](R 128.0): missing requirement [com.atlassian.jira.plugins.workinghours [128](R 128.0)] osgi.wiring.package; (&(osgi.wiring.package=com.atlassian.activeobjects.external)(version>=0.19.0)(!(version>=3.0.0))) Unresolved requirements: [[com.atlassian.jira.plugins.workinghours [128](R 128.0)] osgi.wiring.package; (&(osgi.wiring.package=com.atlassian.activeobjects.external)(version>=0.19.0)(!(version>=3.0.0)))]

It was loaded from C:\Program Files\Atlassian\Application Data\JIRA\plugins\installed-plugins\jira-workinghours-plugin-2.0.0.jar

'com.atlassian.servicedesk.application' - 'JIRA Service Desk Application' failed to load.
Cannot start plugin: com.atlassian.servicedesk.application
Unable to resolve com.atlassian.servicedesk.application [179](R 179.0): missing requirement [com.atlassian.servicedesk.application [179](R 179.0)] osgi.wiring.package; (osgi.wiring.package=com.atlassian.jira.plugins.workinghours.api.calendar) [caused by: Unable to resolve com.atlassian.jira.plugins.workinghours [128](R 128.0): missing requirement [com.atlassian.jira.plugins.workinghours [128](R 128.0)] osgi.wiring.package; (&(osgi.wiring.package=com.atlassian.activeobjects.external)(version>=0.19.0)(!(version>=3.0.0)))] Unresolved requirements: [[com.atlassian.servicedesk.application [179](R 179.0)] osgi.wiring.package; (osgi.wiring.package=com.atlassian.jira.plugins.workinghours.api.calendar)]

It was loaded from C:\Program Files\Atlassian\Application Data\JIRA\plugins\installed-plugins\jira-servicedesk-application-3.0.0.jar

'com.atlassian.servicedesk' - 'JIRA Service Desk' failed to load.
Cannot start plugin: com.atlassian.servicedesk
Unable to resolve com.atlassian.servicedesk [178](R 178.0): missing requirement [com.atlassian.servicedesk [178](R 178.0)] osgi.wiring.package; (osgi.wiring.package=com.atlassian.jira.plugins.workinghours.api.calendar) [caused by: Unable to resolve com.atlassian.jira.plugins.workinghours [128](R 128.0): missing requirement [com.atlassian.jira.plugins.workinghours [128](R 128.0)] osgi.wiring.package; (&(osgi.wiring.package=com.atlassian.activeobjects.external)(version>=0.19.0)(!(version>=3.0.0)))] Unresolved requirements: [[com.atlassian.servicedesk [178](R 178.0)] osgi.wiring.package; (osgi.wiring.package=com.atlassian.jira.plugins.workinghours.api.calendar)]

It was loaded from C:\Program Files\Atlassian\Application Data\JIRA\plugins\installed-plugins\jira-servicedesk-3.0.0.jar

********************************************************************************************************************************************************************************************************


Any advice?

[Andy Heinzer]

Before going any further, I think we need to check one step between steps 4 and 5.  That would be to make sure that Jira Service Desk has a valid license applied to it.  Without a valid license (an eval is just fine) JSD won't startup properly and then cannot upgrade that data.

Provided that has happened, it is still possible plugins are failing to load on the next upgrade.  It looks like there are left over plugins from the Jira Service Desk 3.0 version that are still in the $JIRAHOME/plugins/installed-plugins/ folder when you try to install Jira 8.x.  These won't be compatible, but I didn't expect them to cause the startup to fail.

Try this:

• Stop Jira 8.13
• Go into the C:\Program Files\Atlassian\Application Data\JIRA\plugins\installed-plugins\ path and locate these plugins failing to load
• Move these files out of the $JIRAHOME/ directory (you could also delete them)
• Start Jira 8.13 again

This should at least let you get 8.13 started up. If you can get that far, you can then install/update Jira Service Desk there as well. 

Try that and let me know the results.

Andy

[Steve Edwards]

I made sure to do both of your suggestions: manually applied the Service Desk Trial 30 Days before installing 8.13 and after installing 8.13 I stopped it and deleted the plugins.

localhost:8080 still won't start after doing the above and the atlassian.log file shows (bottom of this post) since the previous restart.

looks like maybe a "NoAttachmentDataException" is the problem now?

So for the sake of sharing what my current step by step notes are on how to get this far:

* (if reinstalling starting over: restore sql jiradb database with backup that already has tables deleted, UNINSTALL JIRA, then delete all files and folders in c:\program files\atlassian\)
* Install Jira 6.4, choose JIRA + Service Desk
* jira > system > restore .zip of previous jira 6.4 client backed up database of issues/projects
* install Jira 7.0
* install JSD 3.0
* go to http://localhost:8080/plugins/servlet/applications/versions-licenses
* UPDATE JIRA SERVICE DESK TO 3.0.11 by clicking "UPDATE" button
* MANUALLY change the LicenseKey to the Jira Service Desk 30 Day Trial
* install jira 8.13
* C:\Program Files\Atlassian\JIRA\bin\config.bat , verify SQL is correct, "SAVE" no matter what to forcefully fix something per atlassian.log
* stop jira, delete 5 plugins that are bad, start jira
* http://localhost:8080/secure/ConfirmNewInstallationWithOldLicense!default.jspa
* I chose "new eval period" but not sure if manually applying license key would be better?
* localhost wont start… rebooted
* **NoAttachmentDataException**




We have decided it is not worth any more time spent trying to fix this issue and will live without Service Desk issues being imported.  I appreciate your help @Andy Heinzer  , but this has been a huge time suck trying to get this to work, and need to avoid the sunk cost fallacy. I keep thinking we are at the final problem and then another one shows up. I give up! ;)