Dividing a Team Project
As you use Team Foundation Server to manage multiple team projects, you may encounter situations where it is desirable to divide a single team project into two (or more) separate team projects. Dividing a team project might be appropriate when:
The process guidance suggests or requires it.
You need different check-in policies for a portion of the team project.
The team project is approaching the maximum size limitations supported by Team Foundation Server, and it is important to plan for further growth in the team project.
You must determine whether the original team project continues and a new branch is created for the second team project, or whether two (or more) new team projects are created and the original team project is no longer used. The remainder of this topic assumes that you are continuing to use the original team project and are branching a new team project from it. For more information on creating two new team projects, see Moving a Team Project from One Version to the Next.
Create the Branched Team Project
Start the branching process by using the New Team Project Wizard to create the second team project. Follow the instructions on the wizard pages, filling in the name and other information for the new team project. When asked to specify the source control settings, create a new source control branch from the old team project. For more information about using the New Team Project Wizard, see New Team Project Wizard.
Move the Work Items from the Original Team Project to the Branched Team Project
Move the relevant work items from the original team project to the branched team project. You must copy the relevant work items to the branched team project one by one (Team Foundation Server does not support the bulk copying or moving of work items across projects). For more information about copying a work item from one project to another, see How to: Copy a Work Item.
Note
Making a copy of a work item sets the status of the new work item to Active by default. If you have work items in the original team project with a status other than Active, and you copy these work items to the branched team project, be sure to set the status on the new work item to the same status as it had in the original team project.
Alternatively, you could use Microsoft Excel to bulk copy work items from one team project to another. Although the bulk copy would copy the current information in the work items, it would not copy the work item history, attachments, and links to the branched team project. For more information about bulk copying work items using Excel, see Working with Work Items in Microsoft Excel and Microsoft Project.
Move the Documents from the Original Team Project to the Branched Team Project
The fourth step in branching is to move the relevant documents from the original team project to the branched team project. You can copy the documents to the new project by dragging and dropping the documents within Team Explorer. For more information about copying documents from one project to another, see How to: Move or Delete a Document or Folder in Team Explorer.
Set the User Permissions for the Branched Team Project
It is important that you correctly set the permissions for the branched team project. You will need to set the permissions on each item one by one (for security reasons Team Foundation Server does not support the bulk copying or moving of permissions from one project to another). For more information about setting permissions, see Managing Permissions.
Create the Areas and Iterations for the Branched Team Project
The team project structure and classification used in the original team project may or may not continue to be appropriate for the branched team project. You must create the areas and iterations for the branched team project one by one (Team Foundation Server does not support the bulk copying or moving of areas or iterations from one project to another). For more information about creating areas and iterations, see Setting Initial Project Areas or Iterations.
Create the Check-in Policies
The team project check-in policies used in the original team project may or may not continue to be appropriate for the branched team project. You must create check-in policies for the branched team project one by one (Team Foundation Server does not support the bulk copying or moving of check-in policies from one project to another). For more information about check-in policies, see Working with Check-In Policies and Notes.
Create Alerts
If you are using alerts in the branched team project, it is important that you set these event notifications correctly. If you want to continue the same alerts used in the original team project, you must create the alerts for the branched team project one by one (Team Foundation Server does not support the bulk copying or moving of alerts from one project to another). For more information about creating alerts, see Setting Alerts.
Determine if a New Backup is Appropriate
Because the process of dividing a team project, copying work items individually, and recreating permissions, areas, iterations, check-in policies, and alerts can take a significant amount of time, it is important that your work be protected from loss due to computer hardware failures. You may want to check with your Team Foundation Server administrator to determine if a special backup of the server is warranted.