The other day a question came from a colleague, that sounded like this.
My client has been using TFS for many years now and has a production deployment consisting of about 4 TFS 2008 servers containing about 50, 50, 25 & 25 team projects respectively.
Now they are in the process of migrating to TFS 2010 and they want to understand the options: their eventual goal is to move all the team projects to one very large TFS 2010 instance.
This is my response, as it could be useful to others.
In your customer scenario you have to choose between:
- A full-fidelity migration, mapping each TFS instance to a separate collection, or
- A loose data migration, moving data around.
In the first case, you use the upgrade wizard for the first server, then repeat the process using tfsconfig import.
In the latter case, you use the Tfs Integration Platform. Don’t be distracted by finding it on Codeplex: there is also a supported version in the VS Gallery and is routinely used internally at Microsoft.
In my opinion, you should ask the customer what they really want to achieve and when. Here some possible approaches to the problem:
- Piecemeal: you create a new instance of TFS 2010 and move a team (create an new Team Project and check-in the code) at their ease leaving history on the old server
Pros: easy to implement; zero downtime
Cons: slow and need more resources
- One Team Project Collection for all: use integration tools
Pros: simplified view and management; less resources
Cons: they lose some history; more work to implement
- Multiple Team Project Collections, one from each old server, plus a “consolidated wharehouse” Team Project Collection: an hybrid solution that uses the out-of-the-box upgrade/import feature, with the integration tool you consolidate the data in a new Team Project Collection for reporting and other consolidated views
Cons: need more resources, e.g. one Controller per Team Project Collection
You can also think of a mix of these strategies, selecting the best approach for different teams.