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

Best method to migrate certain issues including all attachments from datacenter to cloud

Valentin Morlock

Hello,

we're trying to migrate a set of issues from a different, on premise, jira-instance to our jira cloud instance. It's not a whole project but only certain issues, and we'd prefer to include as much metadata as possible, and also e.g. attachments. I've learned about the CSV export + import, but I'm wondering if there are better ways to export and then import a set of issues (not a full project)?

Best,

Valentin

Comments

Christof Hurst

Hi,

I would do (and done several times) a standard migration via Jira Migration Assistant to the sandbox. In parallel set up new project in PROD with target configuration. Then make a migration from Sandbox to Prod via DeepClone App with the filtered issues. There you can make very much configuration to get the perfect result in Prod and can leave all the mess from DC behind in the sandbox.

BR Christof

Huwen Arnone [Deiser/Devoteam]

It's cool that you ask this precisely now, check these resources:

A webinar (tomorrow) related to data management and will talk about this.
This blog post might be helpful.
This other blog post might be useful.
This solution in the marketplace might be useful.

I cannot provide further info but hopefully, any of these resources will help.

Cheers!!

Michael Blake_d0icz8

create a dummy project, move the issues to that project and migrate that project to the cloud. On the cloud, move the issues to the specific project as needed. Then delete the dummy project from the cloud when it no longer has any issues.

Cesar Duran

This is a great approach but the issue keys are going to change, make sure you create a custom field called "Previuos Key", use Jira Automation to copy the current key, and then move the tickets to the new project.

Mark Hansens

Thank you for this insight. Sort of a follow-up question. Currently, I have only been a Jira user, essentially. But in this move, I will become an Org Admin and probably Product Admin. Any tips on what training would be good? I am looking into a couple of the Jira certifications, but not sure which would best for me. Thoughts?

Rob Little_fwnpch

Hey Valentin. I'm Rob, and i work for a Platinum Solution Partner and i'm happy to describe how I've do this exact same process when i'm unable to use the JCMA tool for any reason in a migration.

Setup a project in the cloud.
Setup any custom fields, screen schemes + screens, workflow schemes + workflows, status’s, etc, to match the jira on prem project level configuration.
1. Note - You do not need to manually setup components if they are in use. These will inflate with the csv import.
Perform a csv export with all fields from on prem, using whatever filter you want to get the subset of issues in the project. Note server on prem defaults to 1000 results, but you can edit this setting by following this link https://confluence.atlassian.com/jirakb/filter-export-only-contains-1000-issues-in-jira-server-191500982.html
In cloud, import the csv using the old jira import wizard

NOTE - at this point, you would be inserting the server values, directly from csv exports from server. However, things like usernames are not the identifier in the cloud. Email is. So there’s a few things a custom ETL script could be developed to do.

This ETL script would run against the on prem csv export file.

It would create an almost identical file for cloud csv import.

The ETL would search multiple columns for username identifiers, look up that person’s email and/or accountID against the cloud (which presumes access is provisioned for similar/same users there), and then updates the references of username to be either email (first choice), or accountID (fallback), and in the case it doesn’t find anyone, a default user can be used (via their cloud email, hardcoded as a fallback in the script.)

The resulting slightly edited file will have username or accountIDs instead of the original username from server, which won’t resolve or mean anything once imported to the cloud.

At this point, you can proceed with 5

5. At this point you will choose your csv file, and then also a configuration file. Note - if it’s your first time doing this, you will need to ‘map’ the configuration file for the first time in the subsequent screens. Once you map the csv inbound fields to the cloud fields, you can save the configuration file for subsequent use.

6. Execute the import and check the results.

Fantastic. If everything worked, you now have the issues and as much metadata about them as possible with csv import/exports, imported to the cloud! But now we need attachments.

A custom script can be written to use the ETL scrubbed csv file as import, and then perform the following set of actions, in a threaded pattern (I usually give the script 10 threads).

For each row in the csv:
- Check cloud if the attachment exists already via API request. If so, move on (we don’t want duplicates)
- If it does not exist in cloud, request the attachment from the server api
- Download the attachment binary via server api
- Upload it to the cloud via api
- Delete the local downloaded binary
- Repeat

note - the script needs to handle 0...n attachments values per row! ie: any issue can have 'n' attachments, so there will be multiple attachments columns in the csv!

With the threaded nature and early-exits on the existence check, this chugs along pretty nicely.

I hope this helps you get further with this. You could always enlist the help of a Solutions Partner like my employer to assist as well, we'd be happy to help.

Christof Hurst

Hi Mark,

Is very hard to say what to learn. Most of the knowledge is by doing this a many years in practice. In fact doing a certification won't help a lot in this case. I was many years active as consultant in different companies and actually also in my own.

I could help you in a professional way and teach you in practice step by step if you want. But know that administering a cloud site in a professional and consistent way is not easy for beginners.

BR Christof

Christof Hurst

But then you have many old and unwanted stuff like schemes in your prod instance. It's always time consuming to clean up after such a migration.

Piotr Witka

Please also try Configuration Manager for Jira (CMJ) plugin. Create a snapshot including selected issues (JQL filter) from source system. Deploy snapshot in Cloud system to new project. Move issues to target project and delete one that was created by CMJ. I consider it very convinent when moving issues or project configurations between Jira systems.

Welcome!

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