With Team Foundation Server 2010 lurking over the horizon, there are many of us thinking “how will we move from our TFS 2005 and TFS 2008 environments to TFS 2010”. A valid and good question and one that has been the topic of a number of posts around the TFS Migration Tool. As with everything in information technology there are many options to chose from and it often depends on “you” and “your” operational and often business environment.
Looking at the TFS Migration Tools – Migration Guidance we see the option of migration and synchronization. We will include a few excerpts from the guidance in this post.
Before we ask ourselves whether to use the one or the other, let’s quickly define what we mean with migration and synchronization.
Migration 101 … moving from one system to another, either of which may be a TFS Server in the context of the TFS Migration Tools.
Synchronization 101 … mirroring one system with another, either of which may be a TFS Server in the context of the TFS Migration Tools. See VSTS Rangers Projects – TFS Migration Tools: Where has the link relationship vanished and why? for some scenarios.
So, should we migrate or synchronize?
… it depends :) If you have a heavy investment and dependency on existing tooling you may be looking an extended periods of time needed to migrate the complete environment. Alternatively a small team with moderate dependencies on existing tooling and environments could migrate quickly. The latter obviously favours a migration moving from one to the other, switching off the old and embracing the new, whereas the former leans towards a phased migration and synchronization to minimize the impact. Always ask yourself, can I tell the team to go home and enjoy the weekend, come back to work on Monday and resume work as if nothing happened … with a small team the complexity and chances of success are much higher, compared to a 3,000 strong team … if just 10% of the larger team is unable to work, the business impact is already disastrous.
We are not answering the question though and the reason for this is that there is no clear cut answer or best option.
The recommendation, however, is to use a once-off migration where possible. If you can move your environment all at once, you pay an upfront price and need not worry about ongoing synchronization and associated maintenance. If the risk and cost of running an ongoing synchronization solution is less than the risk and cost of a once-off migration, which may include downtime and the re-development of tooling such as a build lab, then you should consider synchronization.
Recommendation is to use a once-off migration.
More about the Migration Option
- A big-bang migration is generally best for small teams with manageable process-related tooling needs.
- While a migration can have a considerable short-term impact, the ongoing maintenance cost is close to zero.
- When planning migrations chose from:
- Tip of the iceberg migration. We backup everything and migrate only the tip of the history iceberg. Remember, history is seldom missed and a secure backup is more than adequate.
- Shallow migration. We limit the amount of history we migrate from source to target, which requires aggressive scoping of your history. Avoid migrating years of outdated data!
- Full migration. We are pessimistic and migrate everything. We wee to realize that a migration of history will potentially take a long period of time
Whether you chose migration or synchronization scenarios, you should view the process as a business-critical process, which must be stable to avoid impact and work stoppages. Carefully consider:
- Deployment planning
- Disaster recovery planning
- Roll-out (fall-back) strategy
- Support and maintenance of infrastructure
If there is one certainty, it is that the migration and synchronization scenarios will negatively impact the existing and the new TFS server infrastructure, as well as team projects and project members. Careful planning and execution is essential and processing should be avoided during critical project phases, as the potential impact will be compounded! Again ask yourself … what happens if the team is unable to access their data? Imagine 3000 developers a week from a critical milestone and unable to access their code … not a beautiful sight!
Next time we will look at synchronization options and the guidance as it stands today associated guidance.