How to migrate attachments while simultaneously upgrading and changing servers?

[Will Sheppard]

We've moving from Jira v4.2#587 (Linux) to v6.0#6095 (Windows) via a .csv export and import.

Attachments don't get automatically migrated, so what steps do we have to take in order to have all the attachments available in the new system?

What we've thought of so far:

Wondering if it's possible to move the whole attachments directory to the new server, and make the files available? Then we could write a script to somehow add attachment links to already-existing attachments? I couldn't see anything like that in the API docs.

We can work with the documented POST /attachments call to the API, but that would involve re-uploading all of our attachments, and we'd like to avoid that if possible.

P.S. We're already planning to re-create all the issue links (which also don't get imported) by scripting some API calls.

[Nic Brough -Adaptavist- · Accepted solution]

Ok, so it's a merge. CSV might be the best way to do it then.

As you know, attachments are kept on a file system somewhere, and to get Jira to use ones for the issues you are migrating, you'll need to populate the table that says "this issue has that attachment". You can't just copy them to the file system, you need those links as well.

I'd be strongly tempted to do this with Jelly (as I've done it before). You copy the attachments you need to the target Jira server (a temporary area, NOT the Jira attachments directory). You work out the mapping you need to do, and then post that into a line of Jelly.

For example, if your CSV import contained issue ABC-123 with attachment .../attachments/ABC/ABC-123/MrFlibble.doc, and it imports as XYZ-456, you need to feed that into Jelly.

Specifically...

<JiraJelly xmlns:jira="jelly:com.atlassian.jira.jelly.JiraTagLib">
  <jira:AttachFile key="XYZ-456" filepath="/tmp/attachments/ABC/ABC-123/MrFlibble.doc" option="override"/>
</JiraJelly>

You can do hundreds of attachments this way, reasonably quickly, and you can generate it from a "find" command piped into a spreadsheet for a bit of hacking. Once you've got all your attachments done, you can kill off the temporary data.

Note that this can make a Jira system run a bit slow while it's churning through if you do a large batch, but you don't need down-time or re-indexing.

[Jens Kisters __SeibertSolutions]

Hey, that sounds very interesting.

where does the file name come from?

From the files in the filesystem you cant even tell what the file extension is.

Can the file target file name be specified?

[Nic Brough -Adaptavist-]

That's an old post, and it's changed a bit since then.  Jelly has gone and the attachment stuff restructured a bit.

You'll need to have the original data when the files were uploaded to get the names.

[RicardoA]

Hi Will

Why are you using .CSV export and import instead of the backup xml itself? The backup will bring all the informations and link to the attachments. And as you mentioned you just need to copy the attachment folder and paste it in the new <JIRA-HOME>/data/attachments.

Please refer to this documentation: https://confluence.atlassian.com/display/JIRA/Backing+Up+Data

If you still want to use the .CSV export and export procedure, there is this documentation: https://confluence.atlassian.com/display/JIRA/How+to+import+attachment+using+CSVthat will help you to achieve it.

Hope it helps,

Ricardo Carracedo.

[Will Sheppard]

Thanks Ricardo - that page only describes how to migrate a single attachment - how would it work if an issue has several attachments?

[Will Sheppard]

Also, in Jira 4 only image attachments seem to be listed in the Excel file, not other types of attachments. And when the .xls file is saved as a .csv, the links are lost.

[Nic Brough -Adaptavist-]

This sounds like you're doing too many things at once, and in the wrong way. You're doing a move of hardware, and an upgrade and apparently a data migration/merge as well.

Ricardo is spot on here, but I suspect you need to step back and think about what you're doing overall, rather than just jump into it.

Could you explain exactly what you have now and what you want to end up with? CSV is a very poor way to do most of this stuff unless you're actually trying to *merge* data, in which case it may be the best option (although that's still unlikely...)

[Will Sheppard]

We are doing several things at once, but we have good reasons for doing it this way!

[Nic Brough -Adaptavist-]

Nah, it's ok, it's just a merge and there's no need to worry about hardware or upgrade - CSV bypasses the need for those in this case.

[Will Sheppard]

Nic, your jelly comment should be an "answer" so that I can accept it, and this answer should be a comment!

[Nic Brough -Adaptavist-]

converted it now :-)

[James]

We are also tring to migrate issues without doing a backup/restore because we are also making major changes to the the structure. So we only want to migrate issues, comments, links, attachmetns, etc. We have the comments and links worked out but attachments are a problem.

I performed a backup from JIRA OnDemand but the zip file that is created stores all of the attachments named with their attachment ID rather than the oritinal file name. This means that the original file name is lost as well as the file type. Which of course would make the imported attachments unusable.

It is as though the OnDemand backup is designed to make migrating attachment in the way this thread discusses impossible.

Any suggestions?

Thanks

James

[Nic Brough -Adaptavist-]

I admit to stealing the example code from there. As usual, when it comes to Jelly :-)

[Will Sheppard]

Jelly looks like exactly what we need, thank you Nic!

I have now discovered the jelly documentation.

[Will Sheppard]

@Ricardo / @Nic We have a very large and complex Jira instance with many hundreds of teams, all with different workflows and settings. We've taken this opportunity to simplify our workflows, fields and other settings in the new Jira - that's why we're using .csv to migrate - because we only want tickets to be be migrated, not all the other jira stuff.