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
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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).
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It's cool that you ask this precisely now, check these resources:
I cannot provide further info but hopefully, any of these resources will help.
Cheers!!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.