システムの運用開始前には、データの移行作業が発生します。
新規のシステム立ち上げにせよ、既存システムからの入れ替えにせよ、今まで業務をやってきているのであれば、何らかの情報が蓄積されているはずです(商品データ、顧客データ、注文受付データなど)。
システムの運用に先立ち、これらのデータを新しいシステムに移行しておく必要があります。

最近は、データベースを利用して情報を管理している場合が多いですから、データもデータベースからデータベースへの移行になります。データベースのスキーマは変わっている場合がほとんどですし、データ量も少なくないでしょうから、移行プログラムなどを用意して移行する場合がほとんどです。
ここで色々な問題が発生します。

(1)旧システムのデータベースに関する仕様書がない
　「仕様書がない」とまではいかなくても、「仕様書はあるが、実際のものと一致しているかわからない」とか「実際のものと比較してみたら一致していなかった」ということがよくあります。(というより「ほとんど」がそうです)
　旧システムを開発した会社では管理されているはずですが、その会社とは縁を切って別の会社に新システムを依頼する、などの場合に発生する問題です。納品された仕様書をきちんと管理しているお客様は少ない、ということが言えるかも知れません。

　システムが稼動を始めて、何度かの機能追加や不具合修正を重ねていると、実際のシステムと当初作成した仕様書には「差」がでてきます。
　もちろん、機能追加では仕様書が作成されますし、不具合修正でも修正内容の履歴は残るはず。
　ただ、それらは「その都度、単体で作成」されて、システム全体の最新状態を示すものにはなっていないこともあります。
　お客様側でも、仕様書などはきちんと管理しておきましょう。

(2)データが仕様どおりに格納されていない
　実際に旧システムのデータベースの内容を調べてみると、色々と問題が見つかることがあります。
・不要なレコード
　システム内に、不要なレコードが余分に作成されていることがあります。
　レコードが不足するとシステムの運用に支障が出るため、すぐに発見されて修正されますが、余分にあるだけなら運用に支障はでません。
　データ移行やディスク領域不足による対策などを行なう場合に、はじめて見つかります。
　こういうレコードが「かなり多い」とデータ移行の障害になりますので、移行対象からはなるべくはずすようにします。
・不正データ
　システム不具合により、仕様と異なる状態で保存されているデータが見つかることがあります。
　たまたま使われていなかったり、別の不具合の影響で「不具合として表面化していない」などの理由でそのまま残っているものです。
　運用に支障がなければ、データはそのままにしておいても良いですが、移行プログラムを作る上で考慮に入れておく必要があるかも知れません。
・意図しないデータ
　何のためにあるのかわからないデータが見つかることもあります。
　もちろん、仕様書にも載っていないものです。
　「そんなバカな」と思われるでしょうが、これが意外と多いのです。
　その正体は、仕様変更に伴って不要になったデータ、不具合解析のために使用した一時的なデータ、例外的な集計処理を行なうために作成した一時的なデータ、などです。
　移行対象からは除外します。
・残っているテストデータ
　当初の受け入れテストや機能追加などの確認に使用したテストデータが残っていることがあります。
　こちらも、移行対象からは除外します。

(1)の仕様書については、設計段階で発覚することが多いので、早い段階で対策を立てることができますが、(2)のデータについては実際のデータ調査が必要となるため、発見が遅れ、全体のスケジュールに影響が出ることもあります。
開発側からは「設計時に調査させてほしい」とか「開発環境に入れて調査するので、データ一式をエクスポートしていただきたい」という依頼があるはずですが、秘守義務契約の話や前述の仕様書の問題があったりして、すぐには出てこないことが多いです。

また、(2)にあるような不要なデータは、この機会に一掃しておくことが望まれます。
ただ、「削除してシステム運用に支障は出ないのか」という話は必ず出てきますので、詳細を調査する必要が出てきたりしてやっかいです。実際に必要ないデータが「バグを打ち消している」という場合もあるのです。

データ移行については、色々な状況を想定して調査だけは早めに進めておく、ということが大切です。
また、データ移行の工数は思った以上に大きなものになる場合があります。
お客様側も開発する側も、この点を認識しておく必要があります。