October 25, 2012 
A while ago somebody asked me for an easy way to move source from one TFS to another. He struggled with that, because TFS kept asking for the old server.
Even when he removed all the *.vssscc files and unbinded the solution with [Change Source Control] the old server popped up again and again.
I created an easy step by step guide that makes moving from one TFS to another TFS a piece of cake..
The main problem is in the workspace. A workspace mapping contains a reference to a local folder. A local folder can only be part of 1 workspace, regardless of the TFS Server it belongs to. This makes sense because if this is not the case, you can have source changes from other servers modifying your code.
Read more about workspaces in my previous posts:
Situation
For this purpose I created a Team Project on my own DefaultCollection called [MoveSource_SourceProject]. In this project I created a solution with 1 class Library call [TestMoveSource].
Then I created a workspace that mapped this DefaultCollection project to a local folder.
For the target I repeated the steps.
I created a new Team Project [MoveSourceTargetProject] on another TFS Collection, called [PlayCollection].
I did not create a workspace for the target project.
Change TFS Server, without changing the location of the source
To change only the TFS Server we need to do some things do make this happen.
- First we need to make sure that everything we want to move is checked in
- Then, remove the workspace on the source server. Nothing will be deleted on your disk. If you do not trust, try to do it with a newly created dummy workspace.
- It pops up a dialog that all pending changes will be lost if you continue. Since you checked in at the first step, press OK to continue.
- Now, your solution is unbound from source control
- Go to your target server, and create a new workspace which maps the new location to the “old” source folder
- When it pops up a dialog to Get the latest version because the workspace changes, press [No]. We do not want to mess up our current folder
- Open the solution from the “old” (or actually current) location by double clicking the solution file
- Right click the solution and choose “Add Solution to Source Control” on the context menu
- TFS Automatically recognizes the workspace mapping and adds the file to the correct server.
- Check in your changes and you’re done !
Hope this helps!
The Road to ALM 
Thanks for the guide… it worked perfectly for me.
Is this method supposed to preserve the Change History??
No, you need the Integration toolkot for that..
Could you use this to “sort of” keep two TFS instances in sync? For example, if you had a local TFS instance and a remote/online TFS instance, would you be able to make changes to the code, update it on the remote server, and then disconnect from the remote server, reconnect to the local server, and then update the changes that were made on the local server as well?
I ask this because the organization I work for has an internal TFS instance, but will not allow access to it externally. I’d like to do a “work-around” so that I can work externally, but still keep the internal TFS instance up-to-date.
Thanks
Hi,
Maybe this will work but this scenario is not ideal for that. In your case I would do it like this. Create a workspace to the remote server and one to the local server and make sure they contain the same stuff. Easiest way is to create Local workspaces (TFS 2012). Then create a simple batch file that copies all the stuff from your remote workspace to your local workspace and use the TF Add command to add everything and TF checkin command to check-in. Then you will also maintain some history between the files.
If you cannot use local workspaces, just use tf checkout to first checkout all the files and then overwrite it with the new ones.
Hope this helps!
But it loses the change history up to this point. Which could be (say) 10 years of changes by skilled engineers, on a product used by thousands of customers. You didn’t think that was an important detail to mention in your post? If I just wanted to keep the LATEST VERSION OF SOME FILES on a server, why would I use a version control system?
Thanks for your comment. The idea of this post was to clarify the things you need to do when you want to checkin a solution on another TFS Server and avoid the errors you get. Based on the CAPS LOCK yelling this was not completely clear to you and you expected a real migration scenario. My apologies when the post or title confused you.
To do a migration between TFS server and preserve history, you’ll need the TFS Integration platform which you can find here: http://tfsintegration.codeplex.com/
I hope this helps !
Very appropriately replied 🙂
I have one query though.
My current solution is on TFS 2010 and I need to migrate that to TFS 2012. What I understand is that I need to preserve the history while migrating. Do I need to consider anything else that might prove to be a constraint after I do the migration (with history intact)?
Thanks!
When you migrate the tfs 2010 collection history is preserved. When you move to anther tfs you need to use integration toolkit. Please consider carefully because it migrates revisions but not date stamps. Always ask yourself do I really need the history.
Hi,
Thanks for the detailed guide.
How do I copy or migrate source control from one domain to another client’s domain? I know TFS Integration tool works if I have migrate from one team project collection to another team project collection within same domain but does that work for external domain as well? I have a requirement to migrate TFS source control from my company’s TFS to Client’s TFS which are totally in different networks.
Otherwise, do you know if TFS Full backup will work when I restore the backup at client’s TFS? I assume, this will copy the work items as well but I don’t need to copy work items to my Client’s TFS. All I need is to migrate the Source control with Change history. Please help me if you know the process.
Your help will be much appreciated.
Thanks,
If you want to move to another domain with History, and you have the possibility to do a migration I would do that. You can set up a new TFS in the new domain and do a migration or detach/attach collection. I think
A domain migration where you can do user mapping etc. is the best approach here.
is this working for tfs 2013 to 2015 tu?
TFS 2013 rtm and 2013.4 to 2015 yes.