システム移行時のデータ移行の進め方と注意点
基幹システムや販売管理システムを入れ替えるとき、「新しいシステムの画面や機能は決まったのに、今のデータをどう移すかが決まっていない」という状態に陥る企業は少なくありません。データ移行は後回しにされやすい一方で、失敗すると本番稼働日に請求書が出せない、在庫数が合わないといった業務停止に直結します。
この記事では、システム移行時のデータ移行とは何か、どの順番で進めればよいか、どこでつまずきやすいかを、発注者の立場から整理します。移行方式の選び方、発注者が担う作業、見積もりで確認すべき点までわかります。
- データ移行は「抽出→クレンジング→変換→投入→検証」の工程で、要件定義の段階から計画するのが原則です。
- 失敗の多くは技術ではなく、旧データの品質（重複・表記ゆれ・欠損）と移行対象の範囲が曖昧なことに起因します。
- 移行リハーサルは最低2回。本番と同じ手順・時間で行い、件数と金額の突合で検証します。
- データの意味を知っているのは発注者側です。データの棚卸しと検証は発注者の役割として体制に組み込みましょう。
目次
データ移行とは？システム移行における位置づけ
データ移行とは、旧システムに蓄積された顧客・商品・取引などのデータを、新システムで使える形に整えて移し替える作業です。単なるファイルのコピーではなく、新システムのデータ構造（テーブル設計やコード体系）に合わせて変換し、正しく移ったことを検証するまでを含みます。
システムリプレイス全体の中では、データ移行は「開発と並行して進む独立したプロジェクト」と捉えるのが実態に近い考え方です。新システムの設計が固まらないと変換ルールが決まらず、変換ルールが決まらないと移行プログラムが作れません。そのため、設計工程から移行担当を置き、早めに旧データを調査することが重要です。
移行対象になる主なデータ
| 種類 | 具体例 | 移行の難しさ |
|---|---|---|
| マスタデータ | 顧客、取引先、商品、社員、勘定科目 | コード体系の変更や重複統合が発生しやすい |
| 残高・在庫データ | 売掛金・買掛金残高、在庫数、ポイント残高 | 移行時点の断面を正確に取る必要がある |
| トランザクションデータ | 受注、出荷、請求、入金の明細 | 件数が多く、どこまで過去分を移すかの判断が必要 |
| 添付・文書データ | 見積書PDF、図面、契約書の画像 | 保存場所やファイル名の規則が統一されていないことが多い |
データ移行の進め方5ステップ
データ移行は次の5つの工程で進めます。各工程の成果物を明確にしておくと、開発会社との役割分担もはっきりします。
データ移行の基本工程
- 現状調査・移行計画旧システムのテーブル、件数、データの意味を調べ、移行対象・移行方式・スケジュールを決める
- マッピング設計旧項目と新項目の対応表を作り、コード変換や値の変換ルールを定義する
- クレンジング重複、表記ゆれ、欠損、使われていないデータを整理する
- 移行ツール開発・リハーサル抽出・変換・投入のプログラムを作り、本番同様の手順で繰り返し試す
- 本番移行・検証業務を止めるタイミングで最終データを移し、件数・金額・サンプルで突合する
STEP1：移行計画で決めること
最初に決めるべきは「何を、いつの時点まで、どの方式で移すか」です。とくにトランザクションデータは、全期間を移すと費用と時間が膨らみます。法令上の保存義務がある帳簿類は、旧システムを参照専用で残す、CSVやPDFで保管するなど、新システムに入れない選択肢も検討します。
STEP2：マッピング設計は発注者の確認が必須
マッピング設計とは、旧システムの項目が新システムのどの項目に入るか、値をどう変換するかを1項目ずつ定義する作業です。たとえば旧システムの「取引区分：1」が新システムの「掛売上」に当たる、といった対応です。こうした意味づけは開発会社には判断できないため、業務を知る担当者のレビューが欠かせません。
STEP3：クレンジングは想像以上に時間がかかる
長年使ったシステムには、同じ取引先が別コードで複数登録されている、住所の書き方がばらばら、必須項目が空欄といったデータが必ず残っています。どこまで自動で直し、どこから人の判断で直すかを決め、現場の担当者に作業時間を確保してもらう必要があります。
移行方式の選び方
本番移行の方式には大きく3つあります。業務を止められる時間と、データ量・リスク許容度で選びます。
| 方式 | 内容 | 向いているケース | 注意点 |
|---|---|---|---|
| 一括移行 | ある時点で旧から新へ全データを切り替える | データ量が中規模で、週末や連休に業務を止められる | 失敗時の切り戻し手順を必ず用意する |
| 段階移行 | 拠点・部門・機能ごとに順番に移す | 拠点が多い、業務を長く止められない | 移行期間中は新旧の連携や二重管理が発生する |
| 並行稼働 | 一定期間、新旧両方で業務を行い結果を比較する | 会計・給与など誤りが許されない領域 | 現場の入力負担が大きく、期間を区切る必要がある |
中小〜中堅企業では、マスタと残高を一括移行し、過去の明細は必要な期間だけ移す組み合わせがよく採られます。月末締めや決算期を避け、月初の業務が落ち着いた時期に切り替えるのが一般的です。
データ移行でよくある失敗と対策
うまくいくプロジェクト
- 設計段階から移行担当を決めている
- 旧データを早期に抽出し、実データで調査している
- リハーサルを本番と同じ手順・時間で2回以上行う
- 件数・金額の突合表をあらかじめ作っている
つまずくプロジェクト
- 移行はテスト工程の最後に考えればよいと思っている
- 旧システムの仕様書がなく、データの意味が誰もわからない
- テスト用の架空データでしか検証していない
- 「移ったかどうか」の判定基準が決まっていない
とくに注意したいのは、旧システムがブラックボックス化しているケースです。独自のコード値やプログラム内で計算している値があると、データを抜き出しても意味がわかりません。旧システムの保守会社に協力を依頼できるか、契約上データを抽出できるかも早めに確認しましょう。
検証（突合）のチェックリスト
- 件数：テーブルごとに旧と新の件数が一致するか、除外したデータの件数と理由が説明できるか
- 金額：売掛残高、在庫金額などの合計値が移行前の帳票と一致するか
- サンプル：代表的な取引先・商品を数十件選び、画面上で1件ずつ確認したか
- 業務確認：移行データを使って受注から請求まで一連の操作ができるか
- 切り戻し：問題があった場合に旧システムへ戻す手順と判断期限が決まっているか
データ移行の費用と期間の目安
データ移行の費用は、システム全体の開発費に含めて見積もられることが多いものの、見積書上で独立した項目になっているかは必ず確認してください。目安としては開発費全体の1〜2割程度になることが多く、旧データの品質が悪い、システムが複数ある、過去データを大量に移すといった条件では割合が上がります。
上のグラフは工数がかかりやすい工程の相対的なイメージです。クレンジングは発注者側の作業が中心になるため、見積金額に表れにくい点に注意が必要です。期間は、中規模の基幹システムで調査から本番移行まで数か月程度を目安に、開発と並行して計画します。
関連記事レガシーマイグレーションの手法（リホスト・リライト・リビルド）
よくある質問
- データ移行は自社だけで行えますか？
- CSVの取り込み機能があるパッケージで、データ量が少なければ自社で対応できる場合もあります。ただし、コード変換や残高の整合確認が必要な基幹システムでは、移行ツールの開発とリハーサルを開発会社と分担するのが現実的です。
- 過去データは何年分移すべきですか？
- 業務で日常的に参照する期間に絞るのが基本で、直近1〜3年程度にするケースが多く見られます。それ以前の分は、旧システムの参照環境を残すかファイルで保管し、法定の保存期間を満たす方法を別に用意します。
- 旧システムの仕様書がなくても移行できますか？
- 可能ですが、データの中身から意味を読み解く調査に時間がかかります。実データを抽出し、業務担当者と一緒に項目の意味を確認する工程を計画に入れておくことが大切です。
- 移行リハーサルは何回必要ですか？
- 最低2回、できれば3回を目安にします。1回目で問題を洗い出し、2回目以降で本番と同じ手順・所要時間で問題なく終わることを確認します。
まとめ
データ移行は、システム移行の成否を左右する独立した工程です。要件定義の段階から計画し、マッピング設計とクレンジングには業務担当者を巻き込み、リハーサルと突合で「正しく移った」ことを確かめてから切り替えましょう。旧システムの保守会社との調整や、見積もりでの移行費用の扱いも早めに確認しておくと安心です。
この記事に関連するサービス
システムリプレイス
老朽化したシステムやサポートが終わるシステムを新しく置き換えます。仕様書がないシステムも、画面・データ・プログラムの解析から対応し、段階的な移行で業務を止めずに切り替えます。 サービスの詳細を見る
