Anyone who has downloaded the migration guidance from http://www.codeplex.com/tfsintegration or has spoken to any of the Rangers involved in this project will know that the second anyone mentions history as part of a migration, the atmosphere cools down by a few degrees, frowns appear and hectic discussions commence on whiteboards.
To begin, why do we need history?
Ask most people and they all reply that history is important. Historians will say that we need to know our history, where we came from, what challenges we had and conquered … they get very passionate and serious when we start to question or ignore history. I will never forget my history teacher in high school … which in itself is part of ancient history … who insisted that we knew names and dates for all historical events, while the likes of Willy questioned the value of knowing on which day Vasco da Gama actually sailed around South-Africa for the first time, or when the insane battle for Stalingrad was lost by the German forces.
Now a few decades later in ‘history’, we are again asking partners and customers as to why history is important in terms of their source control management environments. While most will have similar arguments as the historians arguing that the history is important to know what makes up a solution, our finding is that most will insist on and keep history, but work predominantly with the latest known good version.
A really good argument for keeping history is in terms of intellectual property, where a precise audit trail and ability to drill down to the origin of the solution is often mandatory.
However, if this is not a requirement we nudge you to the tip-of-the-iceberg (also referred to as starting over or from scratch) with tenacity, or worst case to a partial or focused history (we are still coming up with a suitable name) where you cherry-pick the history that is important.
To continue, why does history scare us in terms of the migration strategy?
We have been using Team Foundation Server (TFS) to TFS migration and synchronization in the Pioneer Dogfood environment for some time now and are busy in non-TFS to TFS migration and synchronization environments as well. Through all of these adventures is has become apparent that migrations vary greatly in terms of complexity and size, that gremlins emerge even after comprehensive assessments and preparations, and that no migration is a simple drag-drop-and-click pleasure excursion.
Some typical gremlins that spring to mind:
- If the “source” from which we want to migrate data from has a complex branching strategy we need to assess whether it is appropriate for the “target”. If not, we need to define the appropriate branching strategy and appropriate mapping.
- If the “source” supports features that the “target” does not support, for example labels, then we need to assess the impact and the work-around.
- If the “source” consists of data accumulated over 20 years
- … we are looking at migrating (re-executing) the historical events of 20 years, which potentially takes substantial time.
- … we need more hardware, processing power and storage capacity on the “target” … not to mention the maintenance and support resources.
- If the “source” owner does not really know or understand the exact requirements … and none of us do … surprises, complexities and compromises start queuing.
- If conflicts occur … and they typically do … the human intervention, effort, processing time and cost increases.
- … Grant could add tons more, as could all of the Rangers and members of the TFS Integration Platform team.
We all start off by assuming that a move from point A to point B will be straight forward, only to get stuck and realising too late that no documentation, no guidance and no assumption can replace a detailed assessment and analysis of all possible factors involved in a migration … especially the need for history. What we cannot define at this stage and I doubt anyone ever will, is the definition of “all factors”, which means we will always welcome the odd gremlin or odd limitation.
I have watched a custom adapter development team run into unexpected issues and I know how challenging the new WSS Adapters have proven to be. At first it all sounds so easy and straight forward, but the moral of the story is “migration and especially synchronization is not an easy adventure”! Spend time understanding the platform, spend time understanding the source and the target environment and in particular … spend “lots” of time testing with real data.
To conclude, what are the Rangers planning in this area?
The following external Rangers are active feature leads of the dream team embarking on a new adventure to deliver more focused guidance for TFS-TFS, ClearCase-TFS, ClearQuest-TFS and Perforce-TFS migrations, covering important planning strategies, migration scenarios, question & answers and consolidating experience and knowledge from the field in checklists, illustrations and templates that will allow you to assess and plan your migration adventure.
We will start with the base questions we posted here, consolidate the experiences, knowledge and “oh” moments we collected in the field and deliver the base guidance needed to perform a migration assessment. Whether there is a suitable migration tool for your requirements and which scenario to pursue will still remain your call, but we hope that the guidance will make your call a bit easier to make. Note we are saying easier, not easy … because, we do not believe that there is an easy migration.