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; } } }

Clone Project and issues

Clayton

Hi, I have a client who would like to move a few Jira software projects into a new site. I will look to use the 'Copy Product Data' feature.

Before I do so I would like to test it using a clone of their project with related issues. Can anybody advise me what is the best way to do this please?

Thanks

Comments

Nikola Perisic

Hello @Clayton

If you have the premium version of Jira, you can use sandboxes which copies the production data. You can make any changes you want without affecting the production sites.

Võ Thị Ly_h4ujkx

Hello @Clayton

Please refer to this guideline https://support.atlassian.com/migration/docs/what-gets-migrated-with-the-jira-cloud-migration-assistant/

Chiara Squilloni

Hi Clayton,

I survived a cloud migration from server and I can share my experience.

My organization used jira server since 2015 and we massive use some apps that we did not chose in cloud enviorment.

So, first of all, you have to know point out what are the difference between the infrastuctures, if the projects you have to migrate have different personalization and in wich way they are implemented.

Customers need to switch from server to cloud like some kind of magic, and we, as jira administrator, have to make this magic appens!

As you can see from the article posted by @Võ Thị Ly not all is copied, if you alredy use automation in jira server for example this automation are not copied. All the fields are copied, and *if a field does alredy exists* this will be copied with an additional "imported" (or something like that), so you have to smoot the transition using an automation to fix this.

Another thing you have to keep in mind is that if you use particular custom workflow you mabe use different way to implement that. For example in my company I use "Email this issue" for email notification and the logic is a little different from server to cloud and *the app data are not imported*.

I also raccomend to use a sandbox enviorment as @Nikola Perisic suggest you if you can. If you can't you can create a new project for test chosing another name and than change it.

Wish you luck!

Arkadiusz Inglot

Hello @Clayton

Fortunately I have some semi-automated migrations done so far, thus:

Before you migrate, on site you are migrating from:
1. Review your Custom Fields
  1. Delete all unused or mark them in description - put there a string, which will be easy to search for on new instance.
  2. Eliminate duplicated names - resolve the conflicts before the migration
2. Review you Permission Scheme
  1. Check used Project roles & groups
    1. Make sure you are not migrating any unused roles or broken permission scheme.
    2. Make sure there are no conflicts on ne
3. Review the Issue Types - does you project really need all of them along with the screens?
  1. Less Issue types = less screens = less data migration
4. Export you most critical automation rules to json file.
  1. Depends on amount of rules - it may be easier to download them, edit and import manually. The editing process is much faster than using Automation for jira (sometimes).
Before you migrate, on site you are migrating to:
1. Review groups & roles
  1. Check for any conflicts between old and new site. If groups are consistent and naming is correct.
2. Check installed plugins.
  1. Is your old jira site project using Tempo? Is it installed on new site and configured properly?
Take a look there:: https://support.atlassian.com/migration/docs/migrate-users-and-groups/ and decide what option would fit better for your migration process. I'd personnaly like to have it clear and reassign the groups once again (with a clear mind that its updated properly). If you have configured API, you can assign the groups for large amount of members. If not - I'd recommend it for around 100~ users as it may be frustrating to reassign the groups manually.
After you migrate, on site you were migrating to:
1. Clean up all the trash, which was migrated, but in general you dont need it:
  1. Migrated project roles (depends)
  2. Project categories (depends)
  3. Custom fields
    1. All which (description contains “migrated” and project assigment = 0)
  4. Groups (depends)
  5. Remove the appended "Migrated on <date>" in:
    1. Field configurations
    2. Scheme descriptions
    3. Workflow, Screens descriptions

Keep in mind that project migration is not only "tasks" in project. Jira needs to migrate te structure to build and apply schemes - it sometimes recreates the data which you already have on your new site and unfortunately makes a duplicity.

And its the best time to force some clean-up, changes, new naming policies and so on.

Fingers crossed!

Steve Rhodes_6b02uv

I assume this is a Cloud to Cloud migration?

As this is a new site, i'd recommend using the Copy Product Data feature but first into a fresh trial of Jira Premium, and then from there another migration to the destination. The reason being that when moving a single project or handful of projects, the copy product data feature will copy way more than you need, and you will need to clean it up. Otherwise you will end up with a mess on the destination side. Some of this should be cleaned up in the destination, and some in the trial instance. The things with "migrated on" and "(migrated)" should be cleaned up in the destination, and the custom fields, issue types, sub-tasks should be cleaned up in the trial instance so that they don't get migrated to the destination.

Items you will definitely need to check that need a cleanup:

Custom Fields (delete unused)
Issue Types (remove all unused Issue types)
Sub-Tasks (remove all unused Sub-Task types)
Groups (delete all groups with zero members)

At the destination instance:

Permission Scheme (rename “migrated” scheme to project name)
Assign Default Permission Scheme to project
Delete migrated scheme - e.g. default permission scheme (migrated)
Delete Administrator (migrated) and atlassian-addons-project-access (migrated) role
(This is a lot quicker than editing the migrated permission scheme to switch the migrated roles for the existing ones).
Issue Linking (swap “migrated” with current links)
Priority Scheme (rename “migrated” scheme to project name)
Notification Scheme (rename “migrated” scheme to project name)

These things will all have "(migrated on)" descriptions and can be removed on the destination:

Statuses
Custom Fields
Screens
Screen Schemes
Workflow Schemes
Issue Type Screen Schemes
Field Configurations
Field Configuration Schemes

The Copy Project Data is still a work in progress, but it does work, and for one off jobs is a lot easier than CSV exports. Good luck!

Antoine LACOMBE

Hello @Clayton ,
Generally, the complexity of a JIRA site increases over time. This complicates support, maintenance and a common language between teams.
A migration is an excellent opportunity to simplify and harmonize practices.
I advise you to identify all the JIRA objects that you want to harmonize during this migration (workflows, custom fields, issue types, priorities, etc.).
'Copy Product Data' is a very cool feature.

Warning with all the self-managed jira projects that you might to transform first into company-managed projects.

Alex Akilov

As was mentioned in the previous responses, the copy product data feature will introduce duplicate objects such as custom fields, permissions, roles, etc every time you run the copy product data tool. Therefore, I wouldn't recommend doing it repeatedly (e.g. move x projects now, y projects later, z projects after that). Each such migration will introduce additional duplicate objects that will need to be cleaned up. If you're only doing it once, then this is a viable approach. Otherwise, I would recommend using a marketplace solution such as Revyz, CMJ, Salto, Exalate, etc.

Clayton

Thanks Nikola - Yea makes sense. Just out of curiosity, Atlassian does not have native functionality to clone entire projects and related issues it seems?

Clayton

Thanks @Steve Rhodes ! When you say a fresh trial of JIRA premium do you mean a sandbox?
My understanding is that if I create a new site and activate a trial I will be limited in terms of numbers of users etc

Chiara Squilloni

Amazing and complete answer! This must become an articole!

Nikola Perisic

Hi @Clayton

No, you can bulk move issues from one project to another. For cloning you would need to use an app. Good one is Deep Clone.

Clara Belin-Brosseau_Elevatic

Hello @Clayton

To answer your question about cloning entire projects and related issues, if that’s something you need to do, I would recommend using our app Elements Copy & Sync that allows you to clone and sync a full hierarchy of issues with all their content (summary, description, custom fields, comments, attachments…).

You can check the guide here.

The app is for free during 30 days (and it stays free under 10 users).

Luka Hummel - codefortynine

Hi @Clayton

For cloning entire Jira projects with related issues, across instances, you might want to consider using our app Deep Clone for Jira. Deep Clone allows you to clone projects, including configurations, associated issues, while mapping custom fields, making it ideal for testing or migrating to a new site.

It also allows you a more granular control of what to clone than the default 'Copy Product Data' feature. Additionally, Deep Clone simplifies the process by eliminating the need for manual cleanup of duplicated fields or permissions after migration.

You can read more on how to clone projects across instances here.

Vish Reddy {Revyz}

Hi @Clayton

I am from Revyz, Our Revyz data manager for Jira app supports multiple use cases including copying specific projects including its data and or just configuration from one cloud site to another.

Happy to give you a demo if you are interested, I could be reached at vish.reddy@revyz.io

Thanks

Vish

Welcome!

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