File revision and source control system moves

Determining how long it will take to migrate source and revision history is usually tricky for me to answer accurately. 

Depending on the source and destination source control systems there may be some scripts or tools to help automate the task but my expertise is that these tools usually need some level of customization.

With this in mind I stumbled onto the announcement below that the Perl source has been moved from Perforce to Git.  The tools required to make this happen took over a year of part time work to develop!  I do not have much more context than that.  My guess is that the history and size of the code base was not the time consuming part.  It was probably the development of the “layering” algorithm to get each revision from Perforce into the Git repository accurately.

In true open source style, Sam Vilain converted Perl's history from
Perforce to Git. He did the work both in his spare time and in time
donated by his employer, Catalyst IT. He spent more than a year building
custom tools to transform 21 years of Perl history into the first
ever unified repository of every single change to Perl.

use Perl | Perl 5 now uses Git for version control

 

When I’m asked by an organization to move sources from one source control system to another I quickly confirm if source history needs to be moved as well.  This may seem like a firm requirement in all cases but when balanced with the additional time required to move the history most organization see more value in brining over a current snap shot of sources and leaving the old repository online (but read only) for to review history and servicing.  Depending on the product, dev culture and servicing requirements the old repository can be moved to offline storage after some time.