【連載】データ移行

データ移行は、新旧でマッピングするだけと、軽く考えている人が多い。
しかし、実際に経験をして苦労したことのある人は、大きな勘違いであることであることを知っている。
データは理想通りに入っているわけはなく、汚い。仕様追加をしてデータベース構造に変化があり、時代ごとに入っている内容が違うからである。特にベンチャー企業は動かすことを優先するため、一筋縄ではいかない。
システムリニューアルをすれば、当然改善のための機能改善がされる。だから、移行できないパターンも生まれてくる。
つまり、試行錯誤と調整の繰り返しである。
また、新旧の両方を知っている人は少なく、調査するエンジニアもメンバーとして必要である。
しかも、アプリケーションを設計中のため、データベースの設計変更もある。素早く移行チームにも連携し、変更の目的を伝え、適切なマッピングをしなければならない。
割り切る勇気
完璧に移行することは、現実的に難しい。時には、出来る範囲で了承することも必要である。また、無理難題を押し付けても解決はしない。できないのだから、時間とコストの無駄になる。
何をもって移行OKとするか？
考え方の基本は、論理的に移行が正しいとなることを証明する。
実際には、金額などは、最低でも軸を決めて、GT（合計）、クロス集計した比較をする。これを複数の軸で実行する。複数で実行する理由は、たまたま数字が一致した場合の対処である002;
そのための移行検証プログラムは必要である。
当日のタイムスケジュール
切り戻しタイミング
移行リハーサルを何度も成功するまで繰り返し確認したが、当日、失敗する確立はゼロではない。少しのトラブルを許容しても進めるべき場合もあるし、逆に戻した方が良い場合もある。その判断が鈍らないようにするための準備である。