Possible solution to moving all project data to a new instance
2 answers
I think that should be OK. However I don't believe this is one of the supported scenarios for server rename.(Pilot to Production or Production to Test) In addition deleting data in the repository is a lot of manual work, so if the repository is not too big you can probably just keep the extra data and just hide them so that users don't see it?
For removing scm data from repository
https://jazz.net/library/article/1006
There is a RFE for component deletion, see more information below.
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=163568
For Work item deletion:
https://www-01.ibm.com/support/knowledgecenter/SSYMRC_6.0.0/com.ibm.team.workitem.doc/topics/t_deleting_work_items_web.html
If you do not have any external references to artifacts in the repository you are splitting, then this approach might work, but since it is not a supported mechanism, it has not been tested at all by the product team (perhaps someone else knows about known issues, beyond the one I mention above).
Comments
I am thinking if I am moving 2 projects to their own repositories, I would copy everything twice, and rename the data in each new instance. And it would probably be important delete the work items from the original server, which will still be running for the remaining projects, so people do not end up reading an old version of the work item. External URLs on a wiki for example would need to be updated for the 2 moved projects to look to the new server name. The work item numbers would remain the same.
Since server rename and deleting content is supported, it seems like all of this is a supported. I am not clear on what would not be supportable if we did this
The underlying server rename machinery maintains translation tables that automatically map URL's to their "current" location. With the approach you describe, some things will work, some things will obviously break, and some things will seem to work but will break in obscure ways. Since this approach is neither supported nor tested, it isn't something I would recommend for any production repository.