I'm not an Infra person, but my experience from the Flex migration is that the XML format must be exported from the same version of JIRA, even down to the x.y.z of the version number. That's because the XML entities cross reference each other and each version of JIRA can contain differences in entity names.
I didn't try Excel because I had 32,000 issues to deal with most of which had attachments, but you might find that Excel is the right way to go. I would get the excel from your version of JIRA, then look at the documentation for the Apache version of JIRA and make sure the format looks the same. Tony from Infra would probably be even happier if you did set up your own test JIRA instance (of the same version as Apache) and tested the import yourself. On 4/2/13 11:40 AM, "Kevin Minder" <[email protected]> wrote: > We only really care about the title and main description. We could even > live without the comments. We only have 44 issues in the old system so > it seems like finding a "bulk" way to do this is only meaningful if it > would "help the next guy". I'd be happy to craft whatever input formats > the Apache Jira can import. I can get XML and Excel out. > I'm still not clear on what can be imported. > > On 4/2/13 12:09 PM, Alex Harui wrote: >> FWIW, Flex wrote an app that hit the SOAP interface of the original JIRA >> base and imported issues into a test instance of the correct version. Then >> the test instance got exported and sent to INFRA. Some things get lost >> because user ids don't match up and voting info therefore can't be >> preserved. >> >> >> On 4/2/13 8:52 AM, "Tony Stevenson" <[email protected]> wrote: >> >>> On 2 Apr 2013, at 16:17, Kevin Minder <[email protected]> wrote: >>> >>>> Hi Tony, >>>> Discussion inline below. >>>> Thanks! >>>> Kevin. >>>> >>>> On 4/2/13 11:05 AM, Tony Stevenson wrote: >>>>> Kevin, >>>>> >>>>> There are several big painful gotchas to be aware of here. >>>>> >>>>> - If we import, and you already have a JIRA project they will be tagged on >>>>> the end of your current issues, and not in the number order you might >>>>> expect. >>>>> >>>> I'm not concerned about the imported issues being assigned new numbers. >>>>> - The project KEY you export from cannot be the same as you import into, >>>>> this will cause overwriting or a failed import. >>>>> >>>> These will be coming from issues with keys like BUG-NNNN and I assume they >>>> will be imported with keys like KNOX-NNNN right? This is fine. >>>>> - Attachments must be provided at the time of the initial import >>>>> >>>> I don't think we have any attachments so this should be fine. >>>>> - The version from which you export must be exactly the same version we >>>>> import into (double check this before shipping us anything, please). >>>>> >>>> Apache: Atlassian JIRA (v5.2.8#851-sha1:3262fdc) >>>> Hortonworks: JIRA >>>> (6.0-OD-09-3#6060-sha1:a4642c9a73ee448a9294273e0bad12d9670c7015) >>>> >>>> I guess this is a deal breaker? I was assuming that we would use XML as >>>> the >>>> interchange format. So you are saying that an XML export from 6.0 can't be >>>> imported into 5.2.8? >>> Correct, v6 OD is their on demand service. We have never done this, and the >>> JIRA importer will barf if the versions are not identical. You might be >>> able >>> to to as Atlassian, or export in another format, but we have not done of ore >>> those before and we may discover new gotchas along the way. >>> >>> >>> >>>>> Tony >>>>> >>>>> >>>>> On 2 Apr 2013, at 14:34, Kevin Minder >>>>> <[email protected]> >>>>> wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> I'm a committer on the Knox podling project. We are discussing possibly >>>>>> trying to do a bulk import of the exting Jira issues in an external Jira >>>>>> system. I can see how to export them from the external system but it >>>>>> looks >>>>>> like I don't have the privs equired to do an import. Is this even >>>>>> possible? If so, what is the processes? >>>>>> Kevin. >>>>>> >>>>> Cheers, >>>>> Tony >>>>> >>>>> ---------------------------------- >>>>> Tony Stevenson >>>>> >>>>> >>>>> [email protected] >>>>> [email protected] >>>>> >>>>> >>>>> >>>>> http://www.pc-tony.com >>>>> >>>>> >>>>> GPG - 1024D/51047D66 >>>>> ---------------------------------- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> Cheers, >>> Tony >>> >>> ---------------------------------- >>> Tony Stevenson >>> >>> [email protected] >>> [email protected] >>> >>> http://www.pc-tony.com >>> >>> GPG - 1024D/51047D66 >>> ---------------------------------- >>> >>> >>> >>> >>> >>> > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
