I never worked in an organization where all the history was transferred to the new system (because of cost or technical hurdles).
So basically, even if the 2 systems are available for some times, the old server end up being decommissioned. So it means you have effectively lost the older history. This is not always that bad, but some times you'd like to know why something was added/designed that way because it does not makes sense, and you cannot use source control to help you. So each change of system incurs a loss of knowledge.
I don't say it is a good idea to have the same system for 30 years but at least you know where you are coming from.
The second point is that during the transition phase you have to maintain the 2 systems in parallel. Even you don't need to touch the old system often, every patch added to the old one need to be ported to the new one, and since systems are often not compatible (and don't play with the same kind of data structures), you resort to patch/manual merge that are kinda error prone, so this is a bit dangerous. It would be technically possible to import the legacy systems in the new tools, but it is often not done either.
So a perfect version control system would need :
- to effortlessly import all the legacy history
- to be 100% compatible with the old system to be able to do merge/compare across systems.
Frankly that sounds like impossible requirements.
So most of the time it is more an organizational issue (when to do the cut off, training, etc) than really a technical issue due to the tooling.
