Musings on immigration

I am back after long hiatus and this time I'd like to talk about immigration. Just joshing - about migration really (though immigration is a hot topick too :).
I do hope that many shops working with Visual Studio that still do not have TFS in house are considering evaluating/purchasing it. And even if the question of featureset is satsifactory, the issue of migration is bound to arise.

Actually, first question usually is - do we migrate the history and legacy code, retaining the structure, including the artifacts from bug tracking system or should we start with clean slate green field repository?

And at that stage I think some facts and possibilities get overlooked.

History
When talking of history of all changes performed on the certain codebase for whatever number of years it appears people tend to hugely exaggerate its importance. Try to ask average developer - how often do you look up the history revisions? And how often those revisions are truly historical (not the one before latest)? Chances are (if the guy is not responsible for maintenance of legacy code) that the usage is fairly occasional.
Now, let's suppose that history is not migrated, but that previous repository is readily available for whoever needs that data. Would that not be a feasible solution for occasional usage?

Legacy code
Do you want to have all code in the same repository? On impulse, everyone answers yes. But do you really? If there is virtually no maintenance, and putting the code in new repository means that defect fix procedure, build scripts etc. needs to be updated, it might well be time consuming. So would it be better to have all code ever developed in one new repository? Certainly so. But would it be easier to leave maintenance only code in old repository? Probably yes.

Bug tracking
With the great number of bug tracking systems available (and many of them developed in house) question of migration may be very well dependent on the person performing it. But even with such person available, the same question is relevant as with history - are all those closed defects absolutely required? And do we need those 200 fields that anybody hardly ever use?

So by now I think you catch my direction. While migration of all data from one system to another is the best solution, it is rarely available - and that due to multiple reasons. And in my personal opinion (leaving internal company politics aside) some sacrifices can be made and even may be beneficial to the whole process. Just imagine your source code repository without all legacy crap lying around, restructured logically and not forest of folders that are there due to "historical reasons".

Of course the situation I describe is simplified a lot. And it is apparent that in large organization there will be the need to have both history and legacy code transferred to the new system. But instead of trying to take and transfer everything as is, it might be better to consider an alternative. To me the alternative is this - having old system repository online and accessible (perhaps read-only) after new system is introduced, and starting new repository from the ground up. Or at least consider that for some projects.

And that no migration/limited migration scenario may be especially relevant in case where there is no bridge between source/target systems. For example, how do you migrate from MKS to Team Foundation?

Overall, I do not advocate the "throw the old embrace the new" approach. But I felt in several cases (where people passionately demanded revisions history for five years in new system without ever using it in the old one etc) that alternative should be at least examined. And sometimes doing no migration can be actually be for the better! Dont you think so?