システムを運用していると
「データ移行」
という話が出てくることがあります。
このデータ移行は、特にシステムの入れ替えなどで発生するケースがありますが、それ以外のタイミングでも発生するものです。
データ移行は、手順を間違えると、社内のシステムのデータがなくなるなど、非常に大きなリスクがあるものです。
今回は、データ移行のリスクの高さや、具体的な手順を解説していきたいと思います。
データ移行とは
データ移行とは、
「旧システムのデータを新システムに移行すること」
を指します。
他にも、サーバーそのものが変わる際などに、古いサーバーから新しいサーバーにデータを移すときにも使います。
データという電子的な情報ですが、基本的にはサーバーに専用のソフトが入っており、そこにデータが格納されている事になります。
このデータを別の場所に移動させることをデータ移行と言うのです。
一般的には、データベースのデータを移動させる事を指しますが、場合によってはファイルなどのデータを移行することを指すこともあります。
データ移行の目的
では、このデータ移行とはどの様なタイミングや目的で発生するものなのでしょうか。
システムの刷新
1つ目は、システムの刷新の際に行われます。
例えば、元々使われていた内製の基幹システムから、基幹システムのパッケージソフトを導入する際、使えるデータはパッケージソフトに持って行く必要があります。
こういった時にデータ移行が行われます。
また、同じシステムでも、オンプレミスの場合にはバージョンアップ時にデータ移行が必要な事があります。
これは、クラウドサービスでは意識することが無いミドルウェアのバージョンアップなどによって必要になることがあるからです。
複数システムの統合
次に、複数のシステムを統合するプロジェクトなどでデータ移行が行われることがあります。
例えば、顧客管理システムが国内用と海外用で別の仕組みとして動いていたとします。
この2つの仕組みを統合して、仕様を国内システムに統合する場合。
別システムだとテーブル定義などが違ってくるわけですが、それを考慮した上でデータを移行してくる必要があります。
世界中にビジネス展開している企業が、社内システムを内製化している場合に起こる事があり、各国の法律や運用方法の違いにより、別システムで動かしていたのが、運用体制の変更やコスト削減などで統合している事例などがあります。
この様に、複数のシステムを統合する場合には、統合先のデータベースに、移行元のデータを持ってくる必要があるのです。
データ移行が難しい・リスクが高い理由
データ移行は、一般的に「難しい」「リスクが高い」と言われています。
ここでは、データ移行が難しい理由やリスクの高い理由を解説します。
バージョンの違いによりプログラムが動かなくなる可能性
1つ目のリスクは、バージョンなどの違いによってプログラムが動かなくなる可能性があることです。
例えば、データ移行の際に、DBのバージョンが上がり、プログラムからの呼び出し方法が変わった様な場合。
プログラム側のSQLの実行部分を修正しなければ、プログラムが動かないということがあります。
この様に、互換性の有無によってプログラムに影響を与える可能性があるため、リスクが高いと考えられます。
データの欠損の可能性
次に、データの欠損の可能性です。
データ移行を行う際に、全てのデータを持っていければ良いですが、場合によってはテーブル定義の違いによって持っていけないデータが出る可能性があります。
移行先では主キーになる項目が、移行元では重複しているようなケースです。
こういった場合、
・主キーの値を変えるのか
・別テーブルとして作るのか
・更新日が新しい行を優先するのか
などの選択をする必要があります。
特に、注文情報などのヘッダーと明細部分に分かれる事が多いテーブルなどに関しては、データの持たせ方が違う事がありますので、注意が必要でしょう。
大量のデータ移行は業務に影響が出る
データ移行では、大量のデータを移すことが必要になります。
特に基幹システムなどのメインのシステムの場合には、数千万～数億件のデータの移行が必要なケースもあります。
こういった場合に、データ移行を日中の業務中に実行すると、他のシステムや通信が止まる可能性があります。
そのため、業務時間外にやったり、分割して実行するなど、方法の検討が必要です。
思わぬトラブルで移行が中断することも
データ移行には、予期せぬトラブルによって中断してしまうリスクもあります。
例えば、特定のカラムに多言語が入っており、そのバイト数が移行先のものよりも大きかった場合。
移行してみて初めてその事に気付くこともあるでしょう。
こういったトラブルによって中断してしまった時に、データの修正方針などを考える必要があり、場合によってはそこで移行作業が止まってしまう事もあります。
一方で、中断している間にも、どんどん新しいデータが蓄積されており、上手く移行しなおさなければ、データの抜けが発生する可能性があります。
これが、データ移行のリスクの1つなのです。
一時的に業務負荷が上がる
データ移行には、後述するように「並行稼働」をすることが一般的です。
新旧のシステムを両方利用しながら、その使用感やデータの差異が無いかを確認していきます。
この時、現場では新旧2つのシステムで、同じデータ登録などをしてもらう必要があります。
そのため、業務負荷が一時的に増大するため、普段の業務に支障が出る可能性があります。
更に、そこまでやって上手くいかなければ、責任を問われることもあるので、リスクが高いと感じる人も多いでしょう。
データ移行の手順
では、具体的にデータ移行の手順を見ていきましょう。
各々の環境の調査
まずは、移行先と移行元の環境の調査を行います。
製品が違う場合には、それぞれの仕様の確認を行い、製品が同じ場合にはバージョンによる互換性の情報がないかを確認しましょう。
基本的には、同じ製品の互換性は、メーカーの公式ページに載っている事が多いですが、場合によってはメーカーに直接確認してみるのが良いです。
それ以外には、ネット検索で
「旧製品 新製品 移行トラブル」「旧製品 新製品 互換性」
などで調べると、過去に同じ様な事をした人が、起こったトラブルなどを記載してくれている場合があります。
こういった情報を確認しながら、トラブルが起こりそうな部分を事前に確認しておきましょう。
既存のデータベースのデータ量の確認
次に、既存のデータベースのデータ量の確認を行います。
各テーブルに何件のデータが入っていて、全体のテーブル数がいくらあるのか。
これらを事前調査しておく必要があります。
この調査で、それぞれのテーブルのデータ件数から
「移行に時間がかかりそうな部分」
をある程度予想することができます。
それにより、後述のスケジュールの作成に役立ちます。
各データが使われている箇所の調査
続いて、各データがどこで使われているのかを確認していきます。
同じテーブルのデータでも、
・プログラム側から取得／登録／更新／削除するデータ
・ストアドプロシージャなどDB内で使われるデータ
・バッチファイルなどから呼ばれるデータ
など、使われ方は様々です。
それぞれ、DBの製品の違いによって利用するライブラリが変わるなども考えられます。
ストアドプロシージャの場合には、使えなくなる関数などもあるため、注意が必要です。
データ移行範囲と移行方法・スケジュールの決定
次に、データ移行の範囲や移行方法、スケジュールの決定を行います。
このスケジュールには、前項のプログラムの修正などもスケジュールに加え、全体感を確認していきます。
データの移行範囲とは、
「本当に全てのデータを移行する必要があるのか」
という事です。
システムの刷新にあたって、必要のないデータが有れば、移行対象から外す場合もあります。
他にも、過去のデータをどれくらい持っていく必要があるのかも、重要なポイントです。
過去10年のデータを持っていけば良いのか、それとも創業当時のデータから持っていく必要があるのかで、データ量が変わります。
データの移行方法に関しては、一般的には
「全件移行」と「差分更新」
が考えられます。
全件移行は、主にマスターデータなど修正が頻繁に発生するデータで行います。
差分更新では、トランザクションデータなどの修正があまり発生しない且つ、追加登録されるデータ量が多いものに利用します。
これらも、後述する並行稼働を考えた時に
「どのくらいリアルタイムにデータ更新が必要か」
を基準に、
・15分単位での移行を繰り返す
・1日単位での移行を繰り返す
・週に1回移行する
などのタイミングを検討する必要があります。
データ統合の場合にはマッピングを定義
システムの統合など、複数の環境からデータを統合する場合には、テーブル定義が異なるため、マッピングの定義が必要です。
それぞれのテーブルのカラムを、移行先のどのカラムに入れるのかを定義し、それを元にストアドプロシージャなどで移行する必要があります。
この時、カラムの型や文字数にも注意が必要です。
数値型を文字型に変換してしまうと、集計などの際に上手く動かない事もあるので、事前調査が重要になります。
移行後に使えないものの修正
プログラムなどで移行後に使えなくなる可能性があるものの修正を行っていきます。
各画面などの修正は後回しにして、DB内の関数やストアドプロシージャなどの移行に関連してくる部分を先に修正していきます。
開発環境にてテスト移行
続いて、修正が完了するか、修正範囲が多い場合は並行して開発環境でテスト移行を行います。
開発環境がない場合には、新たに作成しても良いですが、本番環境以外で実行してみることが重要です。
データの確認
テスト移行が完了すれば、各データの確認をします。
データ移行の際にデータの変換を行うような場合には、変換用のマスターによって意図せずNULLになっているデータがないかなどを確認していきます。
ただ、全てのデータを確認するのは難しいため、優先順位を決めたり、変換をかけた部分だけを確認するなど、作業の優先順位をつけることが重要です。
本番データ移行
データ確認の上で、問題がなさそうであれば本番データでも移行を行っていきます。
この作業は、前述した様に日中の業務時間を避けるか、分割して移行をしていくことをおすすめします。
プログラムの修正等
データの移行が完了したら、必要なプログラムの修正を行っていきます。
これは、特にデータベースの製品変更など、システムそのものは過去のものを利用する場合に必要な作業です。
この間、新システム側では入力できていない状態のため、日次などでデータを移行し続ける事が必要です。
並行稼働
プログラムの修正が完了したら、新旧のシステムを並行稼働していきます。
この時、現場としては作業が2回発生する事になり、業務効率が落ちるので、期間を絞ったり、分担するなどの工夫が必要になります。
本稼働
数週間から1ヶ月程度並行稼働をして、データに大きな違いがなければ、本稼働として旧システムの利用を停止します。
ただし、本稼働が始まってすぐに旧システムやサーバーを閉鎖するのではなく、いつでも戻せる様に待機させておくのが重要です。
また、仮に何かしらのトラブルが起こった時に、旧システムに戻せるように逆向き（新システムから旧システム）のデータの移行方法をまとめておくのも良いでしょう。
データ移行のご依頼はAMELAに
今回は、データ移行について見てきました。
システムの刷新など、データ移行作業そのものはよくある事です。
しかし、本文中でも述べた様に、注意するべき点も多くリスクが高い作業とも言えます。
そのため、知見のある会社に依頼することが重要になります。
AMELAでは、経験豊富なIT人材を派遣しております。
データ移行を検討する際には、是非一度ご検討いただければと思います。
また、データ移行だけではなく、システムそのものの開発やデータ精査など、幅広く対応いたしますので、お気軽にご相談ください。
