基幹システムの刷新で、見た目には地味だが最も重要なのがデータ移行である。新しいシステムをどれだけ丁寧に作っても、そこに乗るデータが正しく移らなければ、業務は回らない。受発注や在庫、会計のデータがずれていれば、刷新後に現場が混乱し、信頼を損なう。

本記事は、データ移行の進め方と、見落としやすいリスクを、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、DX担当、情シス担当、事業責任者である。技術的な作業はベンダーが担う部分が多いが、データの中身を知っているのは業務側である。移行の勘所を発注者が理解しておくことが、成否を分ける。

結論：移すこと自体より、正しく移ったかの確認が肝心

データ移行で重要なのは、「移すこと」よりも「正しく移ったことを確かめること」である。移行作業そのものより、設計と検証に手間をかけることが、トラブルを防ぐ。GXOがデータ移行で重視するのは、次の3点である。

  • 何を、どこから、どこへ移すかを、設計として明文化する
  • 移す前にデータの品質を確かめ、必要なら整える
  • 本番の前にリハーサルを行い、結果を業務側が確認する

「とりあえず移して、後で直す」は、基幹システムでは通用しない。移った結果を業務側が確認できる状態を作ることが、移行設計の目的である。

移行設計：何を、どう移すかを決める

データ移行は、いきなり作業に入るのではなく、設計から始める。何を、どこから取り出し、どう変換して、どこへ入れるかを決めるのが移行設計である。

設計で決めること内容決めないと起きること
移行対象どのデータを移し、どれを移さないか不要なデータまで移し、品質を下げる
変換ルール形式や項目をどう対応づけるか移行先で意味が変わる
移行範囲の期間過去どこまでのデータを移すか移行量が膨らみ、手間が増える
検証方法正しく移ったかをどう確かめるか誤りに気づけない

設計を明文化しておくと、ベンダーと業務側の認識がそろい、後から「これは移っていないのか」という食い違いを防げる。移行対象を絞る判断は、現行の棚卸しと地続きである。

移行設計でとりわけ判断が分かれるのが、過去のデータをどこまで移すかである。すべての履歴を移せば安心だが、量が増えるほど移行の手間も時間も膨らみ、移行先に古い品質の悪いデータを持ち込むことにもなる。一方で、必要なデータまで切り捨てると、業務で過去を参照したいときに困る。法令で保管が求められるもの、業務で実際に参照するもの、もう使わないものを切り分け、移すものと移さないものの線を引く。この線引きは技術ではなく業務の判断であり、発注者が主体的に関わるべきところである。

データクレンジング：移す前に整える

長く使われたシステムのデータには、重複や欠損、表記ゆれが溜まっていることが多い。これをそのまま移すと、刷新後にそれらの問題を持ち越すことになる。移す前に整えるのがデータクレンジングである。

  • 重複の整理：同じ顧客や商品が複数登録されていないか確認する。
  • 欠損の補完：必須の項目が空のまま残っていないか確認する。
  • 表記ゆれの統一：同じものが異なる表記で登録されていないか整える。
  • 不要データの除外：もう使わないデータを、移行対象から外す。

クレンジングは、データの中身を知る業務側の協力が欠かせない。何が正しい状態かは、システムではなく業務が知っている。刷新は、溜まった汚れを落とす機会でもある。データの状態把握は現行システムの棚卸しと可視化から続く作業である。

クレンジングを進めるときに気をつけたいのは、どこまで整えるかの加減である。完璧を求めて全データを精査しようとすると、刷新そのものが止まりかねない。一方で、汚れを残したまま移すと、刷新後に同じ問題を抱え続ける。現実的には、業務に支障が出る品質の問題を優先して整え、軽微なものは移行後に少しずつ直す、という割り切りも必要になる。何を移行前に整え、何を後回しにしてよいかを、業務側とベンダーで合意しておくと、クレンジングが際限なく膨らむのを防げる。

整合性と文字コードの落とし穴

データ移行では、技術的な落とし穴がいくつかある。代表的なのが、整合性と文字コードである。

  • 整合性：関連するデータどうしのつながりが、移行後も保たれているか。たとえば、注文データとその顧客データの対応が崩れていないか。つながりが切れると、業務で参照したときに不整合が表面化する。
  • 文字コード：文字の扱い方（文字コード）が新旧で異なると、特定の文字が化けたり、欠けたりする。氏名や住所など、特殊な文字を含むデータで起きやすい。

これらは、移行直後には気づきにくく、業務で使い始めてから問題が表面化することがある。だからこそ、移行後の検証で、つながりや文字化けを確かめる工程を組み込んでおきたい。古いシステムからの移行で起きやすい論点はAccessからの移行費用でも触れている。

文字化けは、特に氏名や住所といった、人にまつわるデータで起きやすい。旧システムでしか使えなかった特殊な文字が、新システムでは表現できず、別の文字に置き換わったり欠けたりする。一件ずつは小さな問題に見えても、顧客の氏名が誤って表示されれば、信頼に関わる。検証では、件数だけを突き合わせるのではなく、特殊な文字を含むデータを実際に目で確かめることが欠かせない。データの「数」が合っていても「中身」が崩れていることはあるため、サンプルを抜き出して中身まで確認する工程を組んでおきたい。

移行リハーサルの重要性

データ移行は、本番で一発勝負にしてはいけない。本番と同じ手順を、事前に試すのがリハーサルである。

  • 本番前に手順を試す：実際のデータを使い、移行手順を通しで実行してみる。
  • かかる時間を測る：本番の移行にどれだけ時間がかかるかを把握する。
  • 結果を業務側が確認する：移った結果が業務的に正しいかを、現場の目で確かめる。
  • 問題を洗い出して直す：リハーサルで見つかった問題を、本番前に解消する。

リハーサルをしないと、本番でしか分からない問題が、業務を止める形で表面化する。手順の確認だけでなく、移行にかかる時間を測っておくことは、業務を止めない移行計画にもつながる。本番切り替えの進め方は業務を止めない移行計画で扱う。

リハーサルで確認したいのは、手順が通ることだけではない。移った結果が業務的に正しいかを、現場の目で確かめることが重要である。システム上は問題なく移行できていても、業務の感覚では「この数字はおかしい」と気づけることがある。たとえば、特定の取引先のデータが抜けている、在庫の数が合わない、といった違和感は、その業務を日々扱っている人でないと気づけない。リハーサルは、技術的な検証の場であると同時に、業務側が新しいデータを実際に見て確かめる、貴重な機会でもある。ここで違和感を拾い、本番前に解消しておくことが、刷新後の信頼につながる。

データ移行のチェックリスト

  • 移行する対象と、移行しない対象を切り分けたか
  • 過去どこまでのデータを移すか、期間を決めたか
  • 重複・欠損・表記ゆれを確認し、整える方針を決めたか
  • 新旧の項目の対応づけ（変換ルール）を明文化したか
  • データどうしのつながり（整合性）の確認方法を決めたか
  • 文字コードの違いによる文字化けの確認を組み込んだか
  • 本番前のリハーサルを計画したか
  • 移った結果を業務側が確認する手順を決めたか

これらが押さえられていれば、データ移行の大きな失敗はかなり防げる。

よくある質問

Q1. データ移行は、ベンダーに任せれば大丈夫ですか

技術的な作業はベンダーが担うが、「何が正しいデータか」は業務側でないと判断できない。重複や表記ゆれが本当に問題か、移った結果が業務的に正しいかは、現場の確認が欠かせない。任せきりにせず、確認の役割を業務側が担うことが必要である。

Q2. 過去のデータは、すべて移すべきですか

必ずしもそうではない。法的に保管が必要なものや、業務で参照するものは移すが、もう使わない古いデータまで移すと、移行の手間が増え、移行先の品質も下げる。何をどこまで移すかは、業務の必要性から判断したい。

Q3. リハーサルはどのくらい行えばよいですか

少なくとも一度は、本番と同じ手順で通しで行いたい。一度で問題が多く見つかった場合は、直してから再度行う。本番で初めて手順を実行する状態は避けるべきで、リハーサルで手順と所要時間を確かめておくことが安全につながる。

データ移行の設計とリスク確認から、刷新を支援します

GXOでは、基幹システム刷新におけるデータ移行を、移行設計、クレンジング、整合性や文字コードの確認、リハーサルまで含めてご支援します。業務側でしか分からないデータの正しさを一緒に確かめながら、刷新後に業務が止まらない移行を進めます。

データ移行の相談をする

※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。