On source control migration

If I had to pick a class of project more likely to have me groaning and clutching my head in my hands than any other, then source control migrations would definitely be on the list. The strange thing is, I have absolutely nothing against making changes to your toolset when there's a clear gain in productivity or capability to be had. My problem is the cultural factors that have surrounded almost every big push for source control migration I've been a part of:

• It's driven by a vocal minority of developers invariably preselecting as a solution the source code management they use for bedroom projects.
• The arguments against the existing system conflate user unfamiliarity with deep technical flaws in the system.
  The new system is presented as a universal panacea with zero flaws or caveats to be aware of.
• Little thought is given to the follow-up tasks of user education and migration of legacy code.
• The big problems cited are cultural rather than technical.

The last is the key, and why I don't like these projects. They're all too often a lot of effort spent going nowhere. If your team has a bizarre branching strategy, an illogical project structure and bad check-in etiquette on SVN, it's still going to have all of those problems in TFS, git, Perforce or a shared folder on the team server... plus the disruption of migration, plus the mistakes made by inexperienced users, and that's assuming you put in the effort to get everything migrated in one step rather than letting projects languish in "old" source control for months.

I don't think there's anything malicious going on here - there's sometimes a bit of laziness involved ("I want to work with the SCM I'm used to rather than learn a new one") but generally people are trying to solve a problem. It's just that installing a new source code system is easy compared to working at the prevailing culture which is causing clashes, lost check-ins and untidy source control. Address these and then move to a shiny new system once you have a good culture and can select the ideal tooling to lock it in.

So yes, I dislike source control migration projects. But I'd dislike them a lot less if they started with the following steps:

1. Educate the team on best practice for checking in, branching/merging, and resolving conflicts.
2. Clean up the existing source control system until it has a logical, usable structure.
3. Establish regular housekeeping of source control.

Not easy things. But they'll get you a lot further than installing some new software will.