Execution run into errors

[Nickelaer]

Hi Natenho,

I have tried the tool on a MacBook Air (M1).

For this I had downloaded and unpacked the following file:
go-jira-migrate_1.0.11_darwin_arm64.tar.gz

In my test I wanted to migrate a team-managed project, which is not yet present in the target instance. This resulted in the following message:
2023/10/04 10:31:59 Create metadata not found for AM at target.atlassian.net, make sure the current user has access to create issues

After that, I had also created a team-managed project in the target instance and wanted to migrate there, but the following message came up:

panic: runtime error: index out of range [0] with length 0

goroutine 1 [running]:
github.com/natenho/go-jira-migrate/migration.getBoard(0x14000132000?, {0x16bd339e0, 0x2})
	/home/runner/work/go-jira-migrate/go-jira-migrate/migration/migrator.go:254 +0xf0
github.com/natenho/go-jira-migrate/migration.(*migrator).Execute(0x14000132000, {0x104307200, 0xe})
	/home/runner/work/go-jira-migrate/go-jira-migrate/migration/migrator.go:178 +0x134
main.main()
	/home/runner/work/go-jira-migrate/go-jira-migrate/main.go:93 +0x7a4

Cheers
Frank

[natenho]

Hi @Nickelaer, I'll take a look on that, thanks for the details. Probably there is something missing in the target that is not being properly checked by the tool. Please review the Recommendations.

[natenho]

@Nickelaer it seems that the board is missing. Please, try to create a board exactly as the source project and let me know. I will fix the runtime error.

[Nickelaer]

Hello Natenho,

thanks for the quick feedback.

Yes, a board is defined in both projects, but the settings are not the same. Now, I have readjusted the board and the workflow in the project of the target instance, and the settings should now be identical.

Boards:

Workflows:

Now I get the message that there is no source board.

2023/10/25 08:23:48 could not get source board: no boards found in AM, at least one board is required

Testet with the following file:
go-jira-migrate_1.0.13_darwin_arm64.tar.gz

And here is my call on the command line:
./go-jira-migrate -source https://SOURCE-JIRA.atlassian.net/ -target https://TARGET-JIRA.atlassian.net/ -user your-jira-user-mail -api-key xxxxxxxxxxxxxxxxxxx -source-project AM -target-project AM -query "project = AM order by key"

Is it correct to use the user's email for the executing user?

I'm still smoothing out the deployment plans and permissions and will reply.

Cheers
Frank

[Nickelaer]

Hi @natenho,

one additional info:
The projects are Jira Work Management projects.

Cheers
Frank

[Nickelaer]

Hi @natenho ,

the deployment plans and permissions in the source and target instance/projects are now equal.

Cheers
Frank

[Nickelaer]

Hi @natenho ,

this has a Atlassian employee today announced in the following issue (https://jira.atlassian.com/browse/CLOUD-11467):

Hi everyone!
I'm a product managed on cloud-to-cloud data copy and I'm glad to share that we're shipping support for team-managed Jira software and work management projects. With this, customers will be able to move team-managed projects from one site to another easily by following the steps shown here: https://support.atlassian.com/migration/docs/perform-a-cloud-to-cloud-migration-for-jira/

We are currently rolling out the feature and should be 100% rolled out by November 15, 2023.

In case you're interested in a similar experience for Jira Service Management projects or Confluence spaces, please reach out to [smehta2@atlassian.com](mailto:smehta2@atlassian.com) so that you can sign up for the Early access program.

Thanks!

Cheers
Frank

[natenho]

@Nickelaer glad to know that! A "little" late feature for me though...but hopefully it helps you! Please let me know if it works properly so I can archive this project, as it won't be useful anymore ;)

[natenho]

Hi @Nickelaer, were you able to migrate using the new feature of JIRA? Can I consider this project dead? :)