I have the following understanding: that the warehouse (data cube) of a TFS project does not share or integrate data from the warehouses of other TFS projects.

If my understanding is correct, then this creates a conflict in our organization. You see, a TFS "Project" is associated with a project plan (MS Project). A project plan has a begin and end date. So when our "widget" project has completed (reached its end date), and we then move onward to a service release for our widget product, this means we have a new project plan for the service release, which implies we have a new TFS "Project."

But in creating the new TFS Project for our service release, the new project data we are collecting (requirements, defects, etc) is isolated in its own warehouse or data cube, and so we cannot run trend reports that span the life of the product across the multiple projects. Not to mention the fact that regression testing can be awkward, because we either have to make copies of all requirements and test cases into the new TFS Project for our service release, or we must annotate such work items in the prior TFS Project (indicating which test cases are deprecated for the new service release), and expect our teams to reference both TFS projects.

If my assumptions and inferences are correct, it seems we would be better off keeping multiple projects (like the base product and future service releases) all inside just one TFS Project. Is this how others are dealing with this matter? In other words, perhaps we should not treat a TFS Project as a thing with a begin date and an end date.

Any insights or philosophical suggestions would be appreciated...