nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Is cloud to cloud migration from sandbox to prod supported?

Paul O_Shaughnessy

We have found a project that was deleted some time back in production but now needs to be restored. Thankfully, we have a copy of the project in our sandbox instance.

'Migrate cloud site [Beta]' seems to support this use-case and I can select the individual project in sandbox to migrate to prod (where is has been deleted). All the pre-checks pass and the migration is estimated to be 1-5 mins. Great!

But I have some questions about users: I can see that the migration will always include users and groups but since our organisation uses managed accounts (via Atlassian access) we are already in sync across prod and sandbox. Does this mean there will be NO user/group changes? Will existing group membership on our production instance be altered. In this particular use case, I really don't need any user/group changes (and I certainly don't want any doubling up on users/groups). Ideally, I'd like to move the project and not touch users in any way

Comments

Steven Rhodes

I have noticed that when importing back into production from sandbox, it duplicates so many things and there will be a lot of cleanup. I'm talking all the custom fields, issue types and screens used in the project. Also all users and groups despite not wanting that. You may end up with a lot of copies of things with (migrated) after the title.

See https://support.atlassian.com/migration/docs/how-the-jira-cloud-migration-assistant-links-your-data/

I ended up migrating the project to a fresh instance and cleaning up users/groups using BulkOps, and then migrating it back into production.

Paul O_Shaughnessy

Thanks @Steven Rhodes . Sounds like a lot of trouble then! It's a bit of a shame that it can't be done (yet). I might give your workaround a go.

Paul O_Shaughnessy

Just to round out the discussion.

In my case, re-instating the project from sandbox was more about the project data than the project structure so I simply created the project again in prod; re-assigned issue, screen and workflow schemes (which were still usable) and then added in the data using the external system import functionality having exported all issues in the sandbox.

Steven Rhodes

ORIGINAL POST: November 2022

Its a lot of work because it creates copies of every custom field back in your production environment. You have to delete these manually one by one. You can luckily filter on this. I think in the last year the Cloud API has allowed the deletion (or trashing) of custom fields so if anyone has a solution using that it would be great.

The schemes which are migrated back in are duplicates of the ones used in the project so thats an easy cleanup. Using BulkOps to clean up the users is ok, but it needs to be chopped up into 1000 row CSVs, and the group deletion is a pain because Atlassian cloud does not have a group export, and the API call (https://yourdomain.atlassian.net/rest/api/2/groups/picker?maxResults=10000) outputs JSON which is just as much work as copy pasting from the UI to get it in CSV form. Again, help would be appreciated in this department.

EDIT: August 2024

Atlassian have fixed the users part which saves a lot of work. However, all groups still get copied. In addition _some_ extra issue types get migrated but not all. But for Issue Type Schemes, Workflows + Schemes, Notification Schemes, Permission Schemes, Screens + Schemes, it only copies the ones related to the project you are migrating. The custom field problem does still remain, and deleting 500 custom fields manually is no fun. Still, the manual cleanup took 1hr once I was used to the process.

Welcome!

It looks like you're new here. Sign in or register to get started.