Need help with multiple server to cloud migration errors - cannot determine the problem

[Rob Horan]

I have been trying to migrate several projects from server to cloud.  So far I have been getting multiple instances of two error types:

• ERROR MISC project-import We couldn't import Issue MISC-123. Reason: NullPointerException: There is no step in workflow [Workflow Name] linked to status [Closed]. This caused 9 other items to fail.
• ERROR MISC project-import We couldn't import Issue MISC-321. Reason: Issue can be assigned to only closed sprints, and one active or future sprint during migration.. This caused 80 other items to fail.

In the first case, the issues belong to a workflow where Closed has global incoming transitions.  All statuses can go to closed.  There is no step name/status name mismatch.  No idea of what's happening here.

Unfortunately there is no guide to common migration errors that I can find, and I cannot determine what is happening here.  Are there any diagnostic/troubleshooting resources out there for server to cloud migrations I can leverage?

[Percy Yeung]

We are trying to do the same thing, and have run into the same exact issue. 

For us, we tested a migration last week that worked fine, but after cleaning up the cloud site and remigrating, this shows up. 

I went and made a new JIRA Cloud site trial and attempted a migration from the same server there and it was fine. I'm thinking it is something leftover from the first migration, on the Cloud side.

[Rob Horan]

Interesting. This is similar to my experience as well. Several of these projects had imported successfully and I wiped all projects and reimported. Is there a way to wipe literally everything?

[Percy Yeung]

I've tried wiping by hand and wiping through the API, but it's only been the projects themselves and not any other artifacts they brought with them.

As far as I've seen there isn't a way to wipe everything; and what makes matters worse is that we have an active ServiceDesk running on JIRA Cloud that is in production so we can't just nuke everything.

[Percy Yeung]

For the second error, I've received the following from Atlassian Support:

For errors like the following:

2020-08-13 14:04:41.666 ERROR XXXXX project-import We couldn't import Issue XXXXX-116. Reason: Issue can be assigned to only closed sprints, and one active or future sprint during migration.. This caused 35 other items to fail.

This is typically caused when you delete a project, the sprints that were migrated previously are not automatically deleted and stay on the Cloud instance. If you then make changes on the Server instance to that sprint like closing it and then choose to remigrate - the difference in state for the sprints will cause this error. The easiest solution is to go in and delete those sprints to allow everything to migrate again.

[Rob Horan]

Thanks!  In the solution, the easiest thing is to delete the sprints from the source?  I'm assuming thats the case since the project has been deleted from the target cloud instance.  What if you need that sprint?  Isn't that essentially destroying your source?

[Percy Yeung]

Atlassian support mentioned most people would delete it from Cloud. That is what I attempted to do (used the API to first iterate through my list of projects and get all the boards, then get all the sprints in the board, and then delete)

Do note that after deleting from Cloud, it didn't seem like I was able to reimport the sprints, even after deleting the project from the cloud and reimporting.

Waiting on clarification for this.

For the first issue, and those related to workflow schemes and permission schemes, at least for me, it stemmed from trying to manually clean up a migration by deleting some of the imported things. Apparently the migration assistant keeps track of migration attempts and the things it has already put into the cloud. Wiping the whole cloud instance and reimporting is not an option for me because we use the same domain for ServiceDesk right now, but that seems like it is the preferred approach.

Atlassian support escalated my ticket to the dev team, seems like there is some sort of database cleanup on their end that needs to happen in order for this to happen now since the act of me cleaning up those permission/workflows left it in an unstable state.

[Rob Horan]

How does one go about wiping the entire instance?  It might seem like a dumb question, but I can't find instructions on how to do that.

[Percy Yeung]

https://confluence.atlassian.com/cloudkb/reset-and-delete-all-data-from-your-cloud-site-691012037.html

[Rob Horan]

See this is confusing.  When I tried doing this I got this page saying they're sorry to see me go, etc.

So... what's actually happening?  Is the account being closed?  That's not what I want.  I just want to delete the data.  

[Rob Horan]

@Percy YeungSUCCESS - here are three things I think that helped tremendously

1. We worked with Atlassian, who provided a script for deleting all of the migration artifacts from the server instance
2. we wiped the cloud instance, using a zip file Atlassian provided to wipe the site
3. we used version 1.4.0 of the migration tool, which seemed to address a number of issues

How have your efforts been?