I am absolutely with you on this. Therefore my proposal to have a cluster that is using the same name space which would be a prerequisite combined with project move. A little bit like a combination of distributed infrastructure with the way virtual guest can be moved around on their physical hosts. Here the virtual guest would be the project area where the physical host is part of the distributes cluster.

ok, now I get it.. but.. how does this help me for the current situation? for new installations I could define the data model differently to add some virtual namespace label. I suppose you define a new url model with the namespace id, and all those without it get special handling (redirect).

But you could probably avoid all that url naming impact with an internal location mapping indirection service.
Basically you register a project (in a central catalog) on a repository.. the locator service always looks them up, and the URL is only to the catalog. This is all repositories connected to the same jts namepace have a single registry of projects. you could initial build that as part of version migration and maintain it going forward with minimal code change. this would eliminate the exposed URL use impact. and you wouldn't have to fix the links except that the number changed..
always thought the workitem number should have been a handle to prevent this impact too.

This amount of data is pretty small (1,000 project names, and <~100 server names), and so could be maintained in multiple server instance caches (to eliminate cross system api requests to search)

Do you know what the actual status on this discussion/investigation within IBM is?
Is there a functional improvement planned?
Is there on mid or long term a architectural change planned together with the final vision of the jazz hub scenario?

the last status I saw was 'on the backlog', not scheduled for any release.
https://jazz.net/jazz/web/projects/Jazz%20Foundation#action=com.ibm.team.workitem.viewWorkItem&id=93151

we wrote our own tool using Pentaho, and it does much of the work.
history is the biggest problem. We would like to maintain the dates of the events, not just the sequence.  the fact that all the workitem numbers change is also a problem.

I proposed a design change (have JTS service provide the next WI number) that would help this for all the systems under a single JTS (almost all implementations). but it still won't help for cross JTS implementations (should be very small set). 

this is a 25 line of code change, with no new logic, only moving the service from CCM to JTS, and allowing remote access.

Sound very simple. But there is more behind the scene ongoing. If it would be that simple we have not discussed the issue for several years.

To name only some of the issues like common user base, common artifact name space and securing artifact content within the services and across integrations. Not sure if the needed use cases/requirements have been already written. Or if they have been all identified so far.

Would be great to get a vision/strategy on this presented by the IBM CLM architect.

if you use the same JTS, then you have one user base across all CCMs, one security model, ...

I never said this was ALL that had to be done. they would also have to change the UUID calculation model. and I suggested that they go to an indirection model, where the UUID points to a table and the table has the final resolving info. (the UUID algorithm routine would also be remoted to the JTS server so you could encapsulate all this exactly like is (should be) done today.
the lookup table size is puny. a million workitems times 16 bytes is noise in the grand scheme of todays data, and its access model works great for caching, as its 99% read.

the design really needs to be a single logical database, with multiple (re-entrant) engines in front for horsepower/scalability.  one logical CCM.
you could still keep the current separated server change request model for separated complexes (unique JTS's) required by security, etc..
if you need this kind of firewall separation, its unlikely the business would ever change its rules to allow combining.  (where you would be stuck by the current design limitations)

I am fully in line with what you describe. One other specialty is that we have found out over the years that the architecture and the way things have been implemented in RTC, RQM, RRC and JTS have not been aligned at all. In some case even the name is used and not the UUID, which brings other problems on the table. Search functionalists in one service are different implemented and by this bring different results instead of having one search routine reused. There are many of those examples.

At the moment the impression is, that the provided solution based on four architectures which have been glued together. We are disusing needed changes now since years and there is no progress been seen so far. The jazz hub is a new nice interface to the same underlying problems.

If there will be no change supporting the described needs in a common way this solution will fail not because it has not the functional capabilities it will fail because it has not the application operation capabilities needed to operate it in most likely complex Enterprise environment with its limitations.

This brings me back to the point who is the person with the IBM CLM strategy?

Hi Bruno, I think there is nothing consumable as of now.

The issue is probably that there is a huge amount of data part of a project. However, as mentioned, I think a lot of users would like to have a project move capability.

Some might want them across CLM applications - which again describes how complex this is. Do do you want to move only a RTC project, do you want a lifecycle project including other applications?

I think this is probably all contributing to the slow progress.

Thanks for the prompt answer.