回答:
いくつかの移行の個人的な経験から移行の質問に答えるには：
現在のバージョンのソフトウェアをベースラインとして新しいソース管理システムに入れて、そこから作業することを恐れないでください。
ほとんどの場合、履歴は必要ありません。つまり、統合中に実行するタスクが1つ少なくなり、問題が1つ少なくなります。
活発に開発されているファイル/プロジェクトは、すぐに新しい履歴を生成します。そのため、変更が行われた理由を調べる必要がある場合、最近の変更であるため、履歴が現在のリポジトリにある可能性があります。
移行前に安定していたファイル/プロジェクト（すべてが等しい）は、移行後も安定したままであるため、履歴を参照する必要はありません。そのような古いファイル/プロジェクトの履歴を持っているバグを調査する必要がある場合、実際には何のメリットもないことがわかりました。古いリポジトリを1年6か月利用できる限り、そのような場合に参照があります。
管理側では、主に次の質問です。
プロジェクト側では、次の問題もあります。
フリーウェアであろうとなかろうと、「無料の」ソフトウェアではなく「無料のスピーチ」（あなたが自由に選択して展開できる）のように「無料」のソフトウェアであることを覚えておいてください、バックアップ、管理、サポート、...）
上記の基準は、VCSを保持し、放棄するものを決定するための開始点です。
ただし、後者の場合、次のことを考慮する必要があります。
異なるシステムを統合する必要が本当にありますか？私たちのチームでは、各プロジェクトは独自のリポジトリに存在するため、それらの履歴は独立しています。ここでは、Subversionの下のいくつかのプロジェクトと、mercurialの下のいくつかのプロジェクトで、それらの間に依存関係があっても問題なく動作します。
あるVCSから別のVCSに移行することを選択した場合は、利用可能な変換ツールを確認してください。私の経験から、プロジェクトの履歴を削除する技術的な理由はありません。
私は何かを理解したと思いますが、それは質問や他の答えに暗示されていました。VCSは依存関係の管理にも使用されているという事実です。svn:externalsあるレポ（依存関係）を別のレポと統合するなどのVCS機能を使用することは非常に一般的であることを知っています。
私たちのチームが2つの異なるシステムの橋渡し（または統合）の必要性を感じない（技術的な）理由は、依存関係を管理するための別個のツールがあるためだと思います。レポはお互いを知りません。
たくさんの良い答え。考えるべきもう1つのことは、VCの切り替えが非常に重要であると考えて、チームメンバーに逃げさせないことです。移行、学習曲線などにset折がありますが、問題が多すぎる場合は、能力や協力のレベルに疑問を呈する必要があります。