TFS Integration Platform – Can I migrate from TFS to TFS or non-TFS to TFS?
On Friday we refreshed the TFS Integration Platform (TFS Integration Platform – Codeplex Site has been refreshed today!) and shortly thereafter a number of queries came in. Can I migrate from TFS 2005 to TFS 2008, from TFS 2008 to TFS 2010, from a non-TFS ALM system to TFS … the answer made me think, “again”, because although the answer is yes, it comes with a number of provisos, a number of restrictions and an explosive mix of maintenance costs and effort if we are not careful. The answer also conflicts with our recommendation to consider upgrade over migrate.
On https://www.codeplex.com/tfsiuntegration you will find documentation, guidance, the TFS Integration Platform and a TFS to TFS Connector. It is important that you download and peruse the guidance first, that you thoroughly understand your environment, your requirements, possible manual and/or automated solutions and that you evaluate, evaluate and evaluate again in a pilot environment before you go into production. Here is a copy of the planning poster that accompanies the guidance:
In the actual guidance you will also notice two very important notice text boxes:
… take this notice to heart and consider a manual solution, before opting for automation.-
… as highlighted, the recommended approach is to upgrade, not to migrate.
I spend hours trying to find a suitable analogy, but realised that a migrate is probably more natural to any of us. If we upgrade our car, we typically purchase a new vehicle and migrate the contents, consisting of humanoid passengers and tons of stuff from the kids. If we upgrade our house, we typically purchase a new home and again migrate the content, rather than upgrading the house while we live within it.
So, instead of finding an analogy I decided to assume a few different points of view (based on a joke I received from Robert a while ago) and try and convince you to consider upgrade over migrate instead. Again we ask the question … “Can we migrate from TFS to TFS or non-TFS to TFS? ”
- Optimist … the migration will be no problem and the benefit will be huge.
- Pessimist … the migration will be a problem and the benefit will be minimal.
- Idealist … the migration will one day be completely seamless and all you need to do is hit the migrate button.
- Nihilist … the data to be migrated does not exist, nor do we … so why migrate?
- Opportunist … there is an interesting adventure and potentially lots of consultancy hidden in the migration somewhere.
- Realist … the migration is a possibility, but the potential loss of data, the constraints, the maintenance effort and cost is potentially a substantial challenge.
The “realist” view comes from months of working with the product group, Rangers in the field and proof-of-concepts with users who believe that migration is the only option. Before you make a call to install and run the TFS Integration Platform and the family of connectors, think, think and think again. Create a set of manual use cases, which outline the manual steps you would process to migrate from A to B, the exceptions and associated configurations yourself, then test the manual use cases and only then create a set of automated use cases, which implement the manual use cases with a tool.
During this process, which appears to be very laborious, you will quickly realise the complexity, the maintenance effort and cost involved and identify issues and constraints before you hit the magic migration button in production. Once you start moving an ALM environment in production, you are committed and will have to answer to the developers, testers, program managers and other stakeholders if the ALM environment is not as it was before the migration.
So, while I have no analogy to backup our recommendation, I urge you to peruse the guidance first and adopt a “realist” point of view.
If we are using a virtualised environment we are in an even better situation for an upgrade, especially in terms of hardware upgrade to improve performance and increase he potential number of users … but that is beyond the scope of this blog post.
Upgrade over migrate, over synchronise …