Skip to content

TFS source migration opinions

We are often asked about source migrations that we have done for other teams. Below is an answer we posted to a thread on LinkedIn. We hope this helps you if you are considering migrating from another version control system to Team Foundation Server.

Our team has done numerous source migrations in the past. Our approach agrees with other posters in that taking a snapshot (without history) is generally a much more fruitful endeavor. Developers are tied to their source history, but time and time again we apprehensively convince them that history will not be majorly missed and sure enough the development team is ultimately happy. We recommend the legacy system be kept around in a read-only capacity to look up older changes, assuming licensing restrictions make this feasible.

One of the benefits of migrating source systems is that you get a chance to start fresh. We only take branches that are actively being serviced, and it is an opportunity to structure branches according to a recommended model. There is some learning curve for the team to operate in this new world, but they get by that fairly quickly. We have tools that will set up the branches appropriately using the snapshot approach.

Our experience with the TFS Integration Tool has been reasonable. We have done lots of migrations from TFS to TFS (multiple combinations of TFS 2008, 2010, and 2012). We are currently exploring the adapters for ClearCase. This would give you history. We have also migrated history from Seapine Surround as well as Visual SourceSafe, and done snapshot migrations from Surround, SVN, CC, and PerForce. BUT, taking history is much more time consuming and risky. We generally recommend the snapshot approach. Even though it seems like a non-starter now, trust me, the team will quickly get past that when you realize the benefits and cost savings you typically get with TFS version control. Plus, you end up building your new history relatively quickly!