|
[
Permalink
| « Hide
]
Tim Eck added a comment - 24/Dec/04 02:25 PM
I'd be happy if there was at least a documented/available method for restoring single projects (ie. it could be some sort of manual process and/or unsupported script)
Hi Asgeir,
Thanks for the update. Please note that we do have issues with over 100 votes at the moment, and we would like to address them first. Just for information, if you need to 'move' projects between JIRA installations one way of doing this would be to find all issues of a project in teh Issue Navigator, add as many columns as needed to your Issue Navigator list, export to Excel, save the result as a CSV and tehn use JIRA's CSV importer: Ability to customise columns exported to Excel has been implemented in JIRA 3.2. Thanks, How do you suggest we migrate the userbase in such procedure?
You are right, the users and groups will not be exported as part of the CSV. At the moment the only thing I can suggest is creating scripts that copy the information from one database to another or from the XML export. We do have Jelly tags that can be used to create users and groups, and they might be some help:
http://www.atlassian.com/software/jira/docs/latest/jelly.html 
Your suggestion also loses attachments and task linking. That's a major loss. I'm looking at that now as I've been required to move our 1000 task project to a different Jira instance but can't afford to lose these items.
Dear JIRA support,
we would like to force this issue, Kind regards, We also need these feature.
We deleted all issue from last year to optimise JIRA usage. Thanks, Hi JIRA support
We need this feature too. I'm in the process of migrating projects from Fogbugz to JIRA which is a taks your FogBugz importer handles very well. Unfortunately, we do not like the "big bang" method - rather we want to migrate single projects when we find it suitable. One way of doing this is to migrate a project to an empty JIRA database, export it to Excel, save it as a CSV-file and import it to the real JIRA database. However, if you do this, you loose attachments, issue links and comments. The first two I can fix by hand but it is a no-go to loose all the comments. Much of the information in an issue is contained in the comments - so this is where I'm stucked. Regards We too have the need of exporting a single project with all attachments, comments etc. So we are capable to put import a project on a different instance of Jira (moving from our company installation to one of our customer(s))
Regards, Ray Hi!
I'm on my vacation and will be back at the office on July 30th, 2006. If you got this email after sending a message to an email list I've subscribed to, please accept my apologies on behalf of the autoresponse-system. Thank you, sulka we too need this to move projects between different jira instances
A recent post to the forum (by Nick Menere) said:
Unfortunately, there is no way to backup on a project by project basis. It is extremely technically difficult due to the configurations associated with a project and how they could manipulated between the back up and restore. I'm not sure I understand all of the technical difficulties presented, if you avoid storing or restoring the project definition itself (i.e. schemes associated with the project). Just import the issues as is. The steps would be: Then have potential bells & whistles like: Hi!
I'm on my vacation and will be back at the office on July 30th, 2006. If you got this email after sending a message to an email list I've subscribed to, please accept my apologies on behalf of the autoresponse-system. Thank you, sulka Neal,
Though what happens if steps in a Workflow have been deleted (or an entire workflow has been deleted). If a project that relied on this was imported, what would it use? Cheers, I did think of workflows etc. - I just don't see it being such a big deal. The issue's state in a workflow is not saved - just its status. So you only have to worry about statuses that don't fit into the current workflow.
Say you have an issue whose status is "Re-opened", and there is no way to get to that status using the new workflow for the project. So, you prompt the user to pick a status. You already do that when you associate a workflow with a project, so you already have that logic. Other schemes are also no issue. Because the key to my point is that you don't have to save and restore the schemes that were once associated with the project. The admin would have to be responsible for setting those up again when the project is re-created. All you need to do is import the issues. And, again, same goes for custom fields. JIRA is already smart enough to handle custom fields being added and removed. I think you're thinking of doing too much which is to somehow preserve all the proect info and schemes which might be shared, when most of the users waiting for this issue would be happy with a simple import/export of the issues themselves. Am I wrong? Personally, I agree with Neal. I'm most interested in this feature as an "archive" function. So that we clean up the database by removing old, inactive projects. If we needed to restore a project, we most likely would be doing it for historical purposes. Thus, we would just need to see the data and we wouldn't be changing it (e.g. stepping it through workflows, making comments, etc...).
I, of course, don't have intimate knowledge of the internals of Jira. However, the only tricky thing I can think of is that the restore function may need to re-create users. Neal, Erik,
We do actually store the workflow state of each issue. I think the best way to do it would be store a copy of the workflow with the project and when importing, do a workflow migration from that to a current one if needed. But then there are other issues with Issue securities and not to mention Issue Types. It would get real messy. It is almost like you would need to store a deep copy of all the schemes and then perform a migration for each one on import.... Could get real dificult as I don't think the code would handle deleted Statuses, Issue Types and other things that well... I don't see any part of this as optional, this is all to get it into a working state. As a first step I would be happy with something that would allow you to export issues and import them into a project on another database. It could work a bit like the move issue functionality. There would need to be a solution for missing / deleted users though. M
Most of our projects use the default configuration (workflow, permissions etc.) so this would work fine for us. My vision of this would be essentially the same as:
So you end up with all workflows, permissions, status, users, etc but only one project. Thus anyone could create a new Jira instance, import this backup and only have one project but it's ready to go. Importing back in to an existing Jira instance with other projects would obviously require some merging, adding or re-mapping of missing statuses, users, workflows, etc. Dear Atlassian engineering,
The whole concept of migrating projects is clearly an important piece of functionality that is crutial to an enterprise setting. As an example, "we" currently have 6 production instances with 3000+ users and 500+ projects - this is only going to grow. We have split our existing instances a number of times already which involved XML exports/imports, duplicating DBs, and deleting projects manually - a very time consuming and manual process. At present there is no way to migrate a project from one instance to another and in a sense we are stuck with what we have despite frequent requests to move or archive off projects. Also as DBs grow Jira is naturally going to slowly grind to a halt so some mechanism of selectively migrating, depracating projects is necessary. The problems involved in migration have been highlighted in the comments above - true, one would have to have a mechansim to do a "deep" migration of a project and all its dependent schemes/settings and validate the integrity of a migration - this is not easy. Still the problem remains and is a crutial one to crack. So, Jira engineers, you need to come up with a workable solution to this problem to further improve this fine product. In the first instance, would it not be possible to at least identify the moving parts and allow for migrating them in some fashion and when importing do an integrity check so as to assign the requisite schemes/configs ? I understand that features like custom issue types map globally to unique IDs and are picked up by issue type schemes so this would necessitate a remapping for migrated projects - that's a complexity that would need to be delt with. Same would presumably need to be done for workflows. Perhaps to do this cleanly would require a redesign of Jira's DB schemas - still the migration of projects issue is not going to go away and needs to be addressed in a sensible manner. So, please, put this feature request in the pipeline as high priority - it will make life a lot easier for most of your customers. Cheers, Bernard OK - well I can see there is a need for this. Again, I just don't see this as being a monumental effort. When you import the file the contains the issues, you do a pre-pass to identify things like missing users, statuses etc. - whatever you think could pose a problem - and you can even force the importer to set them all up first. For example, I import issues assigned to "joe" with a status of "Verified". The pre-pass says "Sorry, 5 issues involve unknown user 'joe' ". So, if the user "joe" is in the assignment history, or reporter, or assignee of the imported issue, you'll have to address that first by adding the user. Put the onus on the administrator and not on trying to figure out how to fix all the data coming in. Same for any situation - unknown status etc. I'm not sure what you mean by "We do actually store the workflow state of each issue." but it doesn't matter anyway. Any situation that you can't resolve is the admin's problem to sort out. In a simple case of archiving and restoring or migrating, it'll satisfy most of the people waiting for this feature. Once it's in place you can slowly add additional features like auto-migrating to a specified status like when you associate a new workflow with a project or import issues via CSV. All the smarts are already there.
Besides, there are many ways to get issues into the same state - by changing the workflow of a project, by deleting a user with no reported or assigned issues, etc. So the integrity issue isn't new. I think one of your fine developers could probably get it 75% done on just one Fed-ex day I would like to add my voice as well. I agree with Neal. We need at least something. Just exporting/importing the issues and let the admin sort out the details, while not ideal, would be a step in the right direction. It is great that you are concerned with getting every last little detail taken care of in every possible scenario, but I'm wondering how many out there are using all of the extra features and customizations you are trying to accomodate. If you release a feature that doesn't have all of the obscure scenarios taken care of, then at least some of us can do what we need to. If such a feature were released, but it didn't work for my exact situation I would be disappointed, yes, but I would be no worse off than today where I have no export/import functionality whatsoever. With such a feature release at least some of us would be able to use it. With no such feature release, NO one can use it.
I think Neal's got the right idea. Give us at least something, even if the administrator has to sort out the details and deal with the exceptions. Hear, hear!
 An incremental approach to this is definitely a way to go. Hi!
I'm on my vacation and will be back at the office on July 30th, 2006. If you got this email after sending a message to an email list I've subscribed to, please accept my apologies on behalf of the autoresponse-system. Thank you, sulka This is imperative to do. Projects die, projects end, they clog up the database. Gotta go. But should be able to restore any time. Just want to pick a project to administer, perform a one button click to do this and make a tidy export package file, all zipped up and ready to restore as easily as one can restore the entire JIRA repository from XML. All the workaround discussion here sounds hard and tedious. We cannot devote that much time to JIRA care and feeding.
This would be a very useful feature. We just started the CelxtiXfire project at Apache and are in a bind because we can't migrate any of our JIRA issues to their server.
I am on annual leave until September 4, 2006.
For assistance, please contact the TSG Helpdesk: http://www.buseco.monash.edu.au/techserv/help/index.php The Trails project is in a similar bind – can't move the bug DB from somewhereville to Codehaus.
I am also very interested in seeing this issue resolved as it is blocking for the adoption of JIRA in my current project.
Thank you. Nicolas This issue is causing major head aches for us, too.
Hi there
One thing that's got me scratching my head... Jira ships with a script to import Bugzilla projects. How come it doesn't ship with a script to import JIRA projects? Short term, would it be possible to mod the Bugzilla import script to point at the various equivalent DB / file-system resources for a Jira install? My Java talents are not good enough to do this sort of thing myself, unfortunately. Just a mark that apart from the 140+ votes that this Issue's got, we also need this feature in order to proceed.
Dear JIRA Team:
Would be absolutely wonderful and very, very useful if this feature set could be implemented soon. REgards. Hi !
Just to insist a little bit Cheers, Please schedule a solution for this issue. I was really quite surprised to discover JIRA did not support project migration, and consider it must be a bit of a show stopper for larger heavier users. For me it is frustrating and disappointing.
Well, it's up to fourth place: http://jira.atlassian.com/secure/IssueNavigator.jspa?sorter/field=votes&sorter/order=DESC
. Please vote for this issue!
It would be great if this issue were given a suitable priority, much less assigned to someone. I decided to tackle this problem as I needed a solution too. With the help of the folks at Atlassian, I was able to come up with something that takes what's available in the Jira Jelly API and fills many of the gaps with direct SQL commands.
At the moment it is capable of migrating: Project See this page for instructions and more details including the list of current limitations, http://swizzle.codehaus.org/Jira+Migration Once again a major thank you to Jeff Turner and all the Atlassian crew for the red carpet support, I couldn't have done it without you. The way you guys support Open Source is just amazing. It would also be very useful for my organization to be able to import issues in bulk from Excel (csv).
My plan would be to import project requirements for tracking and then link them to verification tests for closure. Our organization also needs this functionality. As it stands, Jira is becoming increasingly cluttered with old projects which we would like to place in our archives. It would be very nice for us to be able to backup and restore individual projects. The only alternative we have at the moment is to backup the entire DB. If we ever needed to archive a project and then go back to look at it for something, it would be rather challenging to restore since we only own one copy of Jira.
Ethan.. you say:
If you inactivate a project, the only place the clutter is seen is in the Administration section (not to end users) and in the size of the database. So, while I can see the use for this feature, I didn't understand your point about inactive projects cluttering up JIRA. Neal...How do you "inactivate" a project? I've not been able remove project no longer in use from the various displays.
I set up a permission scheme with virtually no access. (Maybe only browse to administrators - or one admin).
Then I assign the inactive projects to use that permission scheme. They will disappear from everyone's view (except the one admin). Neal,
To strengthen previous comments and convice you guys that this feature is a MUST:
Bernard echoes my sentiment / situation quite closely. I've had the need to do (1) a couple of times already (and we've only been running our current install of Jira for a few months).
This isn't a "nice to have", it's essential. Especially for something being marketed as "Enterprise". JIRA friends: I think they get the message. Let's let Atlassian respond with their plans for this enhancement. The thread is starting to drift anyway as we are now finding out how to disable projects when that is beside the point. BTW: the permission scheme method is the most straightforward way to disable all access to a project without purging it.
Neal,
Thanks, that will at least alleviate confusion among my users, however it's really only a cosmetic fix to the larger issue. I really hope this feature gets added soon. We at SAIS are yet another organization in need of this feature. The export/import space feature of Confluence is SO nice. We had this problem in getting too excited/serious during our evaluation period and really needed to start our Issue Tracking over with our initial purchase. The Confluence migration was a snap, though, so we didn't lose any of that, which is where most of our effort during the evaluation period went anyway.
Hi
I'm looking at the work-around David Blevins posted a while back. Sorry to post a question about this here, but... well... I guess it's kind of related to the issue @ hand. When I run the script I get an exception, thus: Exception in thread "main" org.apache.velocity.exception.MethodInvocationException: Invocation of method 'getProject' in class org.codehaus.swizzle.jira.Jira threw exception class java.lang.RuntimeException : org.apache.xmlrpc.XmlRpcException: java.lang.Exception: com.atlassian.jira.rpc.exception.RemotePermissionException: No permission to perform operation. The user I am specifying in the -Dusername param is an administrator of the Jira system, and has full access to the project I'm trying to export. It IS finding the user to be a valid one (if I use a bogus user, I get a different exception to the effect that the user is bogus). Do I need to set some other permissions, somewhere? It's getting REALLY urgent that I merge these Jira installations, so would appreciate any help anyone can offer. Thanks – Hi Adam,
I think that if you are looking for some swizzle support, you should subscribe to there users lists, user-subscribe@swizzle.codehaus.org and I am sure someone will be able to give you a hand. Thanks, Guys this issue has existed for 4 years. 4 years?!!!
Surely it is relatively trivial to change the existing XML export to export only a single project. A day's work maybe? We really need this as we have to move from one open source Jira to another soon and we can't afford to lose our history etc. I see the swizzle-based solution but it seems like an ugly way to go about it, and I'd be very concerned about some data still not making it through. I have to agree, this looks to be a major issue which just does not seem to be getting addressed. What is the deal here? At the moment it is impossible for me to offload projects we have entered into our Jira DB, and then load them up back out of archives individually as needed. Consequently our entire archiving process for completed projects has been thrown off, and we have no ability to remove old projects from the database. Meanwhile, our Jira DB just continues to grow... this issue MUST be addressed!
For the amount of money we paid for this software, I'm stunned that this has been ignored for so long. Simply changing permissions so that users can no longer see completed projects is not an acceptable solution, in fact, it's not a solution at all. An update on this issue and plans for how it will be addressed would go a long way toward mending some fences here with those of us who have been in dire need of this functionality. Ethan,
Can I further understand why you need this? Once the project is hidden, is there still a problem for you? What is that problem? Exporting a single project, and importing it again isn't trivial. It requires handling all the issue types, resolutions, workflows, permission schemes, notification schemes, handling users that may or may not exist in each system, custom fields that may or may not be installed or turned on etc. There are partial solutions (see Swizzle above), but for us to do a 'full solution' (which is what you are asking for), is very complicated. In the meantime, I wonder what the specific problem is with you? Perhaps we can implement 'archiving' of projects, which leaves all the data in the database, but doesn't index the issues (so they don't turn up in searches), and hides them in the administration section? Scott,
The problem is, we use mySQL which has a 4GB limit and store a copious amount of projects in Jira. My main concern was in not being able to offload a project which we will most likely never use again into XML and then removing it from the DB itself. This would theoretically then allow us to easily insert an archived project back into the Jira build as needed, without worrying about DB size. At this point, after having checked my current DB size I can see that this most likely will not be a problem in my particular case for some time, so mea culpa on that... but the fact remains that in a large enough enterprise this lack of functionality could become untenable in the long term. Luckily, the attachments are not stored in the DB! I fully understand that there are multiple components to each Jira project, I create projects in it on a weekly (if not daily) basis. I suppose I just can't see how it could be so complicated to add this functionality (not that I don't believe that it is). I will check out swizzle and see if it will be an acceptable solution, but judging by the size of our DB I can most likely get by with simply removing decommissioned projects from view to most users for the time being. Frankly, I feel like if there is no hope of having this functionality added, there should be a thorough explanation from Atlassian as to why this is not feasible. I assume by the context of your comment that you are an Atlassian employee, but there really should be a way for users to recognize this. Thanks for your response. Cheers, E. Russell We need this feature to be able to move specific Jira projects from 1 Jira Server to another, without duplicating the entire storage.
As mentioned before, this seems a basic request. Note the 4 YEARS of demanding, 216 VOTES and 107 WATCHERS !! We often have customers who would like to run their own JIRA once they have been using it with us for a project. Some give up on it since it is impossible to automatically transfer their project's issues.
Scott,
Our biggest concern about this mission functionality is the fact, that we can't restore a single project. We have several hundred users that has the "bulk change" permission. If some i*iot by mistake deletes all issues in a project we will be facing severe problems since we cannot restore a single project. Regards, One problem we have is the fact that every project in the system makes administration more difficult. We've created custom schemas for a lot of projects that aren't being used anymore and cleaning up Jira is pretty difficult without losing data. If you go with the "archived projects don't show up in admin", that would partially solve the problem but wouldn't change the fact that if an archived project uses a schema (or custom field or...), that part of the config can be shared with another project and if we change the configuration, the hidden project's data might change.
For us, we'd like to remove the projects from the database with the intention of not bringing them back unless there's a really pressing need to get to some ancient historic need. Hence the data import doesn't actually have to be very elegant for our purposes, for example I think we could live even with the restriction of only being able to import to a new clean Jira installation. I have one central Jira installation, with several projects on it. I also have a couple of projects floating around on other people's Jira installations, which I need to merge back into my installation. I also need to split my own installation into two (which would mean a sale for Atlassian, btw). Until this issue is sorted out, I cannot do any of this. And this is not just a "nice to have", somehow I have to get all this stuff done.
And Sorry, Scott: what you're describing doesn't sound very complicated to me. You've got a finite set of assets which a predetermined degree of extensibility. It's your own system, so you already know exactly what needs to come from where, and what the end result needs to be. There might be a few moving parts, but it's all predictable. Sure it can't be done in a hundred lines of code, but equally it's not like we're asking you to build The Matrix. And at the end of the day, you've had four years to mull over what needs doing. And we need the functionality. And me - personally - not having that functionality is costing you a sale. This discussion has gotten a bit snippy, folks. How about we summarize the real need, sans geegaws, so Atlassian can discern the core functionality that is required?
1) Export raw project definition - name, code, description, etc. For import: 0) Import schemes, fields, etc to provide basic infrastructure the incoming project needs, or skip and use defaults Is any of this fluff? I have to concur with those who want to give their JIRA projects to others. Our clients could well want to take back the entire set of issues and track them internally. That would, ahem, mean another JIRA sale to that client, particularly if the export import is a no brainer. My mailbox is filling up with thread messages. Please, drive a stake through the heart of this vampire. POSTSCRIPT - why is this so hopeless? I am going to convene a meeting here at work to decide whether this issue is a showstopper for us, and if so, inaugurate a process to find a new issue tracking system. I would think, for a phase 1 solution, the export of projects can
include: 1.) A CSV file containing all issue data pertaining to the project. The 2.) Next, have separate export files (xml/csv) for the different If it means a quicker release to the user community, I would live with We need this heavenly. Its a case of "dead or alive" for this product.
I have to migrate two jira instances (with many projects and issues, different workflows) into a new instance. How can I do this without loosing data? Colin - hiding a project is quite simple. See my post above (22/Nov/06 04:28 PM). Just set its permission scheme so no-one can see it, and except for taking up space in the database - it's gone.
Ok - my mistake for not reading the entire thread - thanks for following Cheers, Colin Not having this feature really makes the current backup system lack. If a project is accidentally deleted and nobody notices for a few days, there is no way to restore that project without losing every change that has been made to any project in the install since the deletion. This makes the backups absolutely useless unless you are content with loosing info. In the case of an often used, many project production install, this is unacceptable. This feature should really take precedence over many of the trivial improvements that have been made on recent releases. Given that there are currently 236 votes and growing on this issue when is it going to be implemented?
In my humble opinion... Having the abiltity to backup and restore projects and creating "project templates" are two features that are essential to having JIRA work as a tool at an "enterprise" level. As a senior engineer, responsible for multiple projects, I must consider the "downstream" costs of the maintenance and support of a tool and its data. If the technical staff will be spending their time trying to get the tool to perform some essential functionalities through the use of work arounds and/or coding I may set that tool aside in my decision process because it will "cost" too much in labor and frustration. I believe that JIRA's market growth is impacted by not having features such as these that support data recovery and the idea of having projects (and other components) be able to move through multiple JIRA enviroments in a lifecyle i.e. Development->Test->Production. Food for thought...
Happy birthday, happy birthday to this issue...
4 years, that's the time of the maturity, may be the time of the implementation. Seriously, I'm a watcher of this issue for 2 years. Since this time, this feature miss me, and not a lonely guy. I am very surprised with the absence of Atlassian about this issue and their user, limit disdain. I agree with your remark ... I am, too, so sorry of this lack of reactivity of Atlassian in the development of "must win" evolutions like this one which would really set up Jira as an enterprise solution !!!
Pleas, thank you for Atlassian to give us answers and realistic evolution planning !!! (for Atlassian and for us, customers !!!) ---- Philippe Kernevez commented on Happy birthday, happy birthday to this issue... 4 years, that's the time of the maturity, may be the time of the implementation. Seriously, I'm a watcher of this issue for 2 years. Since this time, this feature miss me, and not a lonely guy. I am very surprised with the absence of Atlassian about this issue and their user, limit disdain. – Yes i agree philippe, software design can be a challenge but nothing is impossible if there is a drive for it, i just feel that there seems to be no drive for this feature,
i am in need of this feature for sometime now as well. Can anyone from atlassian shed some light to this ? This feature now ranks 3rd top most issues in the JIRA project. previous comments about needing 100+ votes are no longer valid please raise the priority of this issue to at least "critical", as the lack of this feature prevents true enterprise usage of jira
This is a good feature to just import/export a single project to another JIRA instance. We are currently looking for that feature to be installed for migrating one of our major project from one server to another.
Please incorporate this feature as this is really helpful in project migration . In that case we don't have to take a backup of whole database and delete each project except the one we need. I can see this is an often requested feature so just to throw my 2pence in - after recommending Jira to various offices around the group (who then went on to adopt Jira) we've now decided to move to the Enterprise version only to find that there isn't a built in way to do this. Bit disappointing. Any ETA?
I also must agree w/ Kola Oyedeji
I have also recommending Jira to various customers looking to improve there software development process (which more then one have purchased based on those recommendations) now at least one customer needs to merge two instances of JIRA into one and there currently s now good way to do this. I'm hoping they'll sort this issue too! I've added my vote...
I would love to see this functionality. Our production system is huge and I do not want to export everything to test a new plugin. Having the ability to export individual projects would be very beneficial. My vote is in and I'll be watching.
This has been open for 4+ years - I haven't seen any word from Atlassian on this. Is this on the roadmap, or will Jira never support this? I think this is one of the most popular issues and a major limitation in Jira for enterprise users.
It'll be good to hear Atlassian's thoughts/feedback/plan on this. We also need this issue to be solved as soon as possible.
Atlassian - when is this feature request going to be addressed ? I see a number of requests that duplicate this request or ask for other enterprise features, but all have been resolved/closed without scheduling. There is obviously large demand for this functionality. Are you intending to address this ? More importantly, when are you planning to do so ?
I've just been emailed by Jim Conaty @ Atlassian sales, reminding me to pay my annual maintenance fees (fees which are 50% of the licence price, apparently). I am boycotting the maintenance charges until Atlassian sort out these "popular" issues.
Far be it for me to recommend anyone else does the same thing. But that's what I'm doing. Enough's enough. in reply to http://jira.atlassian.com/browse/JRA-1604#action_73885:
I need to export the whole jira-project including components, associated customfields, associated workflows, associated views, permission/notification schemes, usernames ... The import process would be more complex und could have the following steps: Not to pile too much on at once, but #4 makes me think that perhaps this should be done at the same time as a better JIRA upgrade tool. Much of the environment checking-and-upgrading logic that you will need for a successful import is also needed for a smart updater.
I probably don't need to mention it, but Atlassian stands to benefit quite a bit from implementing these two enhancements. I could see it easily helping drive revenue on new installs and upgrades. In reply to http://jira.atlassian.com/browse/JRA-1604#action_87982
, I have also recently baulked at maintenance renewal on similar grounds.
Come on Atlassian, let's have some Legendary Service. A very good start would be a public statement posted here with a plan for how and when this issue will be addressed. It's a first step, but for me, it would restore a great deal of confidence. We too did not renew due to this an a couple of other un-addressed issues. Given the rate at which these issues are being fixed it is more cost effective to let your license expire and just buy a new one in 2-3 years when these issues get addressed. If it takes 3 or more years to address it will save us thousands in licensing fees.
To everyone watching
We are aiming to implement a project import/export feature as part of the next major release of JIRA, JIRA 4.0. We know this feature request has been active for a very long time and we sincerely apologise for the wait. Thank you for your patience and for giving us so much constructive feedback. We should have better communicated our intentions about this issue, and we commit to improving that in the future. We have attempted to carve out the most important elements of import/export into a useful feature that we can achieve in a reasonable amount of time. We've written a preliminary plan which you can view here: We value openess and this comment is an attempt to let everyone understand our plans for this feature, even though the limitations may disappoint some people. Let us know your thoughts. In the interim, we have documented existing solutions to some of the use cases for this feature. Cheers, Brett Jackson First step achieved. Thank you.
Hi,
Will it be possible to attribute comments to their authors maybe through a drop down list assignee/reporter? Thanks & regards I don't like approach described in preliminary, please see my comment there
. It solve only a small part of needed functionality. Can Atlassian explain step wise how the solution proposed at http://confluence.atlassian.com/display/JIRACOM/JIRA+preliminary+plan+for+project+import-export#comment-98402351
will help resolve the issue of moving JIRA Projects from a test server environment to Production Environments? Do all attachments to an issue get moved under the proposed solution? We will not be adding project configuration to the set of data to be imported/exported covered by this issue.
The ability to import and export project configuration is covered in JRA-7641 We obviously understand the correlation between these issues, however, we are keeping things It's best for us to get useful features for the widest range of users within a reasonable time frame and to do this we need an incremental solution, as suggested by Neal Applebaum: Key to delivering the stated goals is resisting the temptation to keep adding features Regards Brett, do you mean: JRA-7641?
-Stefan Thanks Stefan! my comment has been updated.
Great catch. Cheers Brett Just hit this today. Merging projects from some earlier version of Jira into a current install, mmmm. Any ideas when Jira 4 is ball parked for release?
According to this post by Anton
This is definitely a weakness in the product. In large organisations with multiple instances of JIRA running any restructure of the business posses major challenges in JIRA. This inability to move projects between instances is a real limitation to large corporate usage of JIRA as a foundation product for managing large programs of work.
I have seen the online archiving, its good but i want to backup/restore/purge only the old projects and restore them if required in future.
I do not want to keep the old projects in jira. but want to maintain the backup of them. backup entire jira projects may not be a good idea. Please do provide a solution as early as possible. Ok, not to pile on but since it seems the Atlassian folks are counting votes I thought I needed to cast ours. Our JIRA instances have grown rapidly from "black box" experimental to full-on production. As many others have said, not having the ability to migrate/restore etc ENTIRE projects (workflows, schemes, etc) is a major requirement for an enterprise solution. I won't say more since I think others have said all the needs saying, but this is crucial and not having this capability might bring us to a grinding halt. Thanks!
We are being bit by this lack of feature. OMG!!! I can't believe feature this doesn't exist!
We really need this feature too. In fact we were very surprised to discover this omission after investing in this software. While we attempted to be thorough in our research during the time available, I suppose the old ASS-U-ME rule applies.
 We also feel it would be very useful to have the capability to import/export templates and have a range of default templates which correspond to some common project management models. We would also like the ability to clone a project. We are also considering this feature as a must. We were surprise this is not available, considering that when deleting a project, Jira actually proposes a backup. No one said there the backup is global, which would have been very nice.
We still use in a lot of our projects Bugzilla for this reason. We can export a project from bugzilla and import this project into jira when it is ready to go into the support phase. This problem and also some other issues like Support for subcomponents (JRA-846) and Quick search on context (JRA-5484) and other issues prevent us to buy and use more Jira licences.
I still cannot find this issue at the 4.0 release list?! Hi,
We are working on a set of functionality outlined in: I see in
http://confluence.atlassian.com/display/JIRACOM/JIRA+preliminary+plan+for+project+import-export that the Enterprice Features ( custom fields , workflow ) are Excluded. Enterprice user pay US $2,400 for support & updates but the features in the enterprice version are excluded in an update!! It is a long time ago that there was an update for an enterprice feature.
Import en export without custom fields is useless for us. I suggest: stop with this issue and start with JRA 6757: This looks a better sollution: What you offer with this plan+for+project+import-export doesn't help. Hi L. Vermeulen,
Please note that the custom field values will be included in the project import that we are aiming to build for JIRA 4.0. Custom fields configuration, however, will not be automatically migrated. Due to JIRA's flexibility for project configuration, moving projects between JIRA instances requires quite a lot of logic and will take us some time to build. Due to this, as mentioned by Brett in an earlier comment: Cheers, We also (OceanInformatics.com and openEHR.org) need to be able to move Jira projects from one instance of Jira to another. I would consider this not a luxury, but a hard requirement for enterprise users of Jira. Custom field data needs to be moved with any project - indeed, a project should be able to be moved completely intact.
In terms of the admittedly challenging problem of moving the schema as well, which presumably must involve determining what bits of the source schema clash or duplicate the schema in the target Jira system, I would think that any reasonable diff and merge capability that could be made to Jira administrators could help - in other words, provide a way for a human to help resolve it if it is too hard purely in software (and I can see it might be in some cases). ----- The following is an automated response
----- to your message generated on behalf of gawain.bolton@thalesgroup.com J'ai quitté Thales Services le 18 avril, 2008. Thanks mate, I should probably go ahead and upgrade, it's a bummer that
the issue I really want is already fixed and in the 4.0 release. Thanks again Please ignore previous email, sent by mistake, thanks
This functionality is essential to a backup and archival scheme. Where the projects that are completed but need to be kept for Historical data recovery can be moved of the main production server and to an archive server. This would help to cut down on diskspace, database access etc. on the production box, and keep the engineering teams satified with JIRA, and off the JIRA admins back. I am of the same mind as all other 396 votes for this. It should be a high priority for JIRA to fix this. How about a time line as to when it will be done?
We have close to 200 projects in JIRA, as these projects become inactive we need a solution for migration these projects out of JIRA and into an archive instance. If after years of working in one tool, with no way to migrate and save data off, JIRA becomes sluggish when doing backups, indexing, queries, etc. Data backup sizes and attachment file system space becomes large and soon you start looking for a fresh solution.
Looking for a fresh solution is what I will do next, as the speed of the jira software development process tends towards zero.
I'm still waiting for several top voted jira issues to be resolved. Oh, look, we just missed the fifth birthday of this issue. Any hints for other solutions are welcome. We using a CSV export from Jira and Bugzilla. This can be import into Jira. This works but you know how to make an export and there is a bug in Jira CSV. The first isue you import must have the largest numbers of comment.
Dear JIRA Development,
Can you please update or comment all of the open top voted issues? Can someone at least just give a comment on these issues, for all i care just make a statement that implementing these issues will take another 5 years, then at least i only have to check all of these once every 5 years for updates. AWESOME!!! Its scheduled for 4.0! Cannot wait!
We understand the frustrations on this issue and with the time it is taking to deliver this functionality.
In light of this, we will now be addressing this issues in the next version of JIRA. To be more specific, we will NOT ship the next version of JIRA until this functionality is included. This release is currently planned to be delivered late Q3 / early Q4 this year. We have also revised the written plan which you can view here: http://confluence.atlassian.com/display/JIRACOM/JIRA+preliminary+plan+for+project+import-export Thank you for your open and honest feedback. Brian Lane I also request the ability to import/export projects for the purpose of moving data between a dev and production environment.
Dear JIRA support,
We too would like to force this issue. Please look into this to the earliest and let us know the time frame (if possible) by when this feature would be implemented in the upcoming JIRA versions. Thanks, Shankar Hi Shankar,
As Brian explains just above Kind regards, Hello,
We are happy to report that our plans of project import have NOT changed and we are including this functionality as part of our 3.13 release. We are still planning to release 3.13 in the late August / early September timeframe. However, there are still some objects that we have not included. For a more detailed overview, please take some time and review our plan located here: At this time, we will be resolving this issue. For additional objects that you feel we should focus on in a future release, please review the above plan and then vote and comment on JRA-4052. We will be using JRA-4052 going forward to help us prioritize which objects we would add next to the project import infrastructure that has been built in 3.13. Thank you in advance for your feedback. Brian Lane |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Resolved
Major
Import / Export (backup / restore) individual projects
