新旧システム間のデータ移行時にデータの正当性を保証することの難しさ

（本記事の情報は、記事の公開日時点での情報であり、その正確性、完全性、最新性等内容を保証するものではありません。）

レガシーシステムからオープン系システムのような新旧システム間のデータ移行には、RDBベースで開発をしている方々には想像できないような問題が内在しています。

メインフレームは、現在と比べて大幅にマシン性能が低い時代から、1台で数百・数千人のアクセスをこなしていました。
必然的にデータベースに割けるCPUパワーは限定されており、RDBでは常識である参照整合性やテーブルジョインなどは、実装されていることはあっても実際に使えるケースは多くありませんでした。
そのため、データ整合性はアプリケーションが保証していたのです。（「いるのです」と言った方が良いかもしれません。レガシーシステムではいまでも当時のアプリケーションが稼動している例が多いです）

例えば、あるカラムに投入されるべき商品コードがマスターテーブルに存在しなければならない場合、RDBでは通常、Foreign Keyを使用すれば、コードカラムにマスターに存在しないコードが入ると、レコードの挿入時にRDBが参照整合性エラーではじいてくれます。
このような構造のデータベースなら、異常データはそもそもデータベース内に存在しないことになります。

一方、メインフレームやオフコンなどのレガシーシステムでは、アプリケーション内に投入可能なコードをインコーディングすることで、適切なコード以外は書き込めなくしています。
マスターを参照して投入可能なコードを獲得する場合もありますが、オンラインのレスポンス保証のためには省略させる場合が多かったのです。

そうなると、データの正当性はアプリケーションの信頼性次第と言うことになります。
アプリケーションに障害がなくても、
長期に渡るシステム運用の中で仕様変更の際に設計ドキュメントに記されていないコードや、
もう使われていないシステム稼動当初のデータ、
アプリケーションの障害で混入したデータ、
極端な例では開発時のデバッグ用コードなどが残っている場合もあります。

これがそのまま抽出され、データ移行担当者に渡されるのです。

よりによってこのような「ダーティなデータ」は、データの移行時ではなくデータのロード後の検証作業で初めて見つかることがあり、特にDWH：データウェアハウスでその傾向が強い印象があります。

DWH：データウェアハウスは、確定済みの正確なデータが来ることが前提ですから、Foreign Key等の参照整合性はあまり使われません。データが正確なら、検索や集計時の参照整合性チェックが必要ないからです。
そのため、データロード時ではなく、フロントエンドのBIツールのデバッグ時に発覚することも少なくないでしょう。

データ移行をプログラムで実施する場合、データ量にもよりますが、
ホスト側のCOBOLでデータ抽出時に加工するか、
移行先のサーバー側で実行するなら、C言語等の高速な言語が使われることが多いでしょう。

DWH：データウェアハウスの構築自体は、C言語やCOBOLなどのプログラマーがいなくても実現できますが、データ移行作業のみ別のチームからプログラマーをアサインしたり、基幹系システム側に依頼するなどして、不足するスキルを補うこともよくお聞きします。
しかし、新システムへのデータ移行が終わり、いざデータの突き合わせを行うと
数値が合わない！
といったことが起きるわけです。
スキルホルダーにデータの調査を依頼しようにも、移行チームは既に解散済みで修正できるプログラマーがいない！といった事態に至るケースもあるでしょう
特に、BIツールでの検証は工程の最終フェーズでしょうから、ここで手戻りが発生すると、高い確率で移行完了時期の遅延が起こりえます。

データ移行にETLツールを使用するのは、単にロジックを高速に構築できると言うことではなく、このような手戻りに素早く対応できるという意味もあるのです。

結果、新旧システム間のデータ移行は、次のような点に留意して計画することをお勧めします。