リプレイス時のデータ移行で失敗しないために

リプレイス先のシステムが決まり、契約も済んだ。あとはデータを移すだけ——そう思っていた矢先に、移行リハーサルで文字化けした住所データが大量に見つかったり、本番切り替え後に得意先マスタが重複表示されたり、最悪の場合は過去の取引履歴の一部が消えてなくなっていた、というトラブルは珍しくありません。システムのリプレイスにおいて、要件定義や機能選定にはしっかり時間をかけても、データ移行は「最後にまとめて流し込むだけの作業」として軽視されがちです。しかし実際には、リプレイスプロジェクトが炎上する最大の要因のひとつがデータ移行です。

この記事は、リプレイスの検討段階（費用内訳や発注判断）ではなく、すでにリプレイスが決まり、これから実際にデータを移行フェーズに入る担当者を対象にしています。旧システムから新システムへ、実際にデータを移す作業そのものに焦点を当て、よくある失敗パターンと、非エンジニアの担当者でも実行できる対策を解説します。リプレイス費用の内訳そのものや、Excel移行前のデータ整備については別記事で詳しく扱っているので、そちらもあわせてご覧ください（記事末尾でリンクします）。

この記事の結論を先に

データ移行の失敗は、ほとんどの場合「移行の直前になって初めてデータの中身を精査した」ことが原因です。逆に言えば、次の4点を移行作業に着手する前に押さえておけば、致命的なトラブルの多くは避けられます。

• 移行対象データの範囲と「捨てるデータ」を先に決める
• 文字コード・改行コード・日付形式などのフォーマット差異を事前に洗い出す
• 本番移行の前に、必ず同じ手順でリハーサル移行を行う
• 移行後の検証（件数照合・サンプル突合・業務担当者による目視確認）を移行作業の一部として計画に組み込む

以下、それぞれがなぜ重要なのか、具体的にどう起きて、どう防ぐのかを順に説明します。

なぜデータ移行はリプレイスの中で軽視されやすいのか

見積もりの内訳を見ると、多くの場合「データ移行」は数ある工程のひとつとして小さく記載されています。しかし実際の作業量は、旧システムの構造・データの汚れ具合・新システムの仕様によって大きく変動し、見積もり時点では正確に見積もりにくい性質を持っています。

開発会社側も、要件定義や画面設計といった「発注者と一緒に決める工程」には時間をかけますが、データ移行は基本的に開発会社側の内部作業として進むため、発注者側の目が届きにくくなります。結果として、移行のリハーサルや検証が計画に組み込まれないまま「移行スクリプトを流して終わり」という進め方になってしまうケースが見られます。

さらに、リプレイスの検討段階では機能面の比較検討に関心が集中しがちで、「今のデータをどう移すか」は後回しにされやすいという事情もあります。契約前の段階で、データ移行の進め方について開発会社に確認しておくべき理由はここにあります。

「新しいシステムは決まった。あとは移すだけ」という言葉が出た時点で、データ移行のリスクへの警戒感が下がっていないか、一度立ち止まって確認する価値があります。

失敗パターン1: データ欠損（移行したはずのデータが消える）

最も深刻な失敗が、移行後に一部のデータが見当たらなくなるケースです。「削除された」というより、多くの場合は「そもそも移行対象に含まれていなかった」「移行スクリプトの条件から漏れていた」という原因で起こります。

よくある原因

• 旧システムの一部のテーブル・シートが、移行対象の洗い出し段階で見落とされていた
• 「アクティブなデータだけ移す」という判断基準が曖昧で、休眠顧客や過去年度の取引履歴などが対象外にされていた
• 添付ファイル（見積書PDF、契約書スキャンなど）がデータベースの外部（旧サーバーのファイルサーバー等）に保存されており、DBの移行対象からそもそも漏れていた
• 文字コードの扱いを誤り、特定の文字（機種依存文字、絵文字、旧字体の氏名など）を含む行だけがインポート時にエラーで弾かれ、そのまま見過ごされた

対策

移行を始める前に、「何を移すか」だけでなく「何を移さないか」を文書として明確にすることが最も効果的な予防策です。過去5年分の取引履歴は移す、それより古いものは旧システムを閲覧専用で残す、といった判断を発注者側で下し、開発会社と共有しておきます。この判断が曖昧なまま「全部移してください」とだけ伝えると、開発会社側の解釈でどこかが漏れるリスクが残ります。

添付ファイル類は特に見落とされやすいので、移行対象の棚卸しリストに「ファイル」の行を必ず追加してください。DBのレコード移行とファイルの移行は、技術的にも別の作業になることが多く、担当者が違う場合は連携漏れが起きやすい部分です。

失敗パターン2: 文字化け・文字コードの不一致

「移行したデータの一部が読めない文字になっている」という文字化けは、データ移行トラブルの中でも発生頻度が高いものです。特に日本語データを扱う移行では、次のような組み合わせで問題が起きやすくなります。

CSV形式でデータを受け渡す場合、文字コードだけでなく改行コード（CRLFとLFの違い）や区切り文字（カンマと引用符の扱い）の不一致も、レコードの行がずれる・文字が化けるといった不具合の原因になります。

対策

移行に使うファイルの文字コードは、必ず移行の初期段階で「旧システムからの出力形式」と「新システムの取込仕様」の両方を確認し、変換が必要かどうかを明文化しておきます。実務担当者がすべてを把握する必要はありませんが、「文字コードを合わせる作業が必要かどうか、開発会社に確認しましたか」という一言を発注時・移行着手時に投げかけるだけでも、対応漏れをかなり防げます。

機種依存文字（丸数字や単位記号など）は、変換ツールによって別の文字に置き換わったり、削除されたりすることがあります。氏名・住所・品名など、変換ミスがそのまま業務トラブルにつながりやすい項目については、移行後に目視でのサンプルチェックを行うことをおすすめします。

失敗パターン3: データの重複

移行後に「同じ取引先が2件、3件と重複して登録されている」という状態は、業務上の実害が大きい失敗です。売上集計が二重にカウントされたり、担当者が古い方の重複レコードを見て連絡してしまったりと、気づいた後の後始末にも時間がかかります。

起きる理由

旧システムの側にすでに重複データが存在していたケースと、移行処理そのものが重複を生んでしまうケースの2種類があります。

1. 旧システム側にすでに重複があった: 表記ゆれ（「株式会社山田商店」と「(株)山田商店」など）で同一の取引先が別レコードとして登録されていた状態を、そのまま新システムへ移行してしまう
2. 移行処理が重複を生んだ: 移行スクリプトを複数回実行してしまい、同じデータが二重に取り込まれた。あるいは、旧システムの複数のテーブル（例: 「顧客マスタ」と「見込み客リスト」）を統合する際、名寄せ（同一人物・同一法人の判定）のルールが不十分で、同じ相手が別レコードとして残った

対策

移行前の段階で、旧システムのデータに重複がどの程度含まれているかを確認しておくことが重要です。この工程はデータクレンジングと呼ばれ、Excel運用が長く続いたデータほど、表記ゆれによる重複が積み重なっている傾向があります。全件を人手でチェックするのは非現実的なので、会社名・電話番号・メールアドレスなど、突合に使えそうな項目でソートし、近い値が並んでいないかを重点的に確認する方法が現実的です。

移行作業自体については、「同じ処理を2回実行しても結果が変わらない」設計（同じキーのレコードがあれば上書きする、なければ追加する、といった処理）になっているかを開発会社に確認しておくと、作業ミスによる二重登録のリスクを下げられます。

失敗パターン4: 項目の対応関係のズレ（マッピングミス)

旧システムと新システムでは、同じ意味のデータでも項目名や入力の仕方が異なることがほとんどです。この対応関係（マッピング）を誤ると、データそのものは移行できていても、内容が意図と違う形で新システムに入ってしまいます。

具体的には、次のようなズレがよく起こります。

• 旧システムの「備考欄」に自由入力されていた情報（「要注意顧客」「掛け率10%引き」など）が、新システムでは構造化された別項目に分かれているべき内容だったが、そのまま1つのテキスト項目に丸ごと転記されてしまい、検索・集計に使えなくなった
• ステータスを表すコード値（旧: 1=商談中、2=受注、3=失注）が、新システムの選択肢（新: 見込み、成約、他決）と1対1で対応しておらず、機械的な変換で一部が誤ったステータスに割り当てられた
• 日付の形式（和暦・西暦、年月日の区切り文字）の解釈が食い違い、月と日が入れ替わって登録された

対策

マッピング（旧項目→新項目の対応表）は、移行作業を始める前に一覧表として作成し、発注者側の業務担当者が必ず目を通す工程を挟んでください。開発会社が機械的に項目名だけを見て対応付けると、実際の業務での使われ方（自由記入欄に何が書かれているか等）まではくみ取れないことがあります。特に自由入力のテキスト項目は、実際のデータをサンプルで見ながら「この内容は新システムのどの項目に入れるべきか」を業務目線で判断する必要があります。

マッピング表のレビューは、システムに詳しい担当者だけでなく、実際にそのデータを日常的に入力・参照している現場のスタッフにも見てもらうことを推奨します。項目の意味は、使っている本人にしか分からないことが多いためです。

失敗パターン5: 周辺システムとの連携漏れ

基幹システムや顧客管理システムのリプレイスでは、対象システム単体だけでなく、そこにデータを送っている・そこからデータを受け取っている周辺のシステムやツールの存在を見落としがちです。

たとえば、旧システムから会計ソフトへ売上データを自動連携していた、あるいはExcelマクロが旧システムのCSV出力を毎朝取り込んで集計表を作っていた、といった「システムの外側にある業務の仕組み」は、リプレイスの要件定義の段階では話題に上らないことがあります。新システムに切り替わった瞬間、これらの周辺の仕組みが突然動かなくなり、担当者が「なぜ集計表が更新されないのか」と原因を探し始めて初めて連携漏れに気づく、という展開はよくあるパターンです。

対策

移行対象データの棚卸しと合わせて、「旧システムとデータをやり取りしている他のシステム・ファイル・マクロが存在しないか」を洗い出す工程を入れてください。経理・営業・製造など、部署をまたいで確認することが重要です。1つの部署では気づかなかった連携が、別の部署では日常的に使われていた、というケースは珍しくありません。VBAマクロで組まれた集計処理は、作成者以外が存在に気づいていないことも多いため、特に注意が必要です。

洗い出した連携先については、新システム側でも同様のデータ出力・連携が可能かどうかを移行計画に含め、間に合わない場合は暫定的な代替手段（手動でのデータ書き出しなど）を用意しておくと、切り替え直後の業務停止を防げます。

移行方式の選択: 一括移行か、段階移行か

データ移行の進め方には、大きく分けて「一括移行」と「段階移行」の2つの方式があります。どちらを選ぶかによって、リスクの性質が変わってきます。

一括移行は、旧システムの運用をある時点で完全に止め、全データを一度に新システムへ移し、翌日から新システムのみで業務を行う方式です。切り替えの手順がシンプルで、旧システムと新システムを並行して運用する期間の管理コストがかかりません。一方で、移行時に見つかった問題への対応時間が限られるため、リハーサルを入念に行っておく必要性が高くなります。

段階移行は、部署ごと・データの種類ごとに段階を分けて少しずつ移行し、旧システムと新システムをしばらく並行稼働させる方式です。問題が起きても影響範囲を限定でき、後戻りもしやすい一方、並行稼働の期間中は同じデータを両方のシステムに入力・反映する二重管理が発生しやすく、その運用ルールを事前に決めておかないと現場が混乱します。

どちらの方式が適しているかは、業務の止められる時間、データ量、システムの構成によって変わります。判断に迷う場合は、開発会社に両方の方式のメリット・デメリットと、それぞれの場合の作業スケジュールを提示してもらい、比較検討することをおすすめします。試験的に作ったシステムを段階的に本番運用へ移行していく実務的な進め方は、PoCをVercelから本番化する現実的な手順でも扱われており、データ移行以外の本番化の論点として参考になります。

テスト移行では「業務のシナリオ」で確認する

リハーサル移行の検証というと、件数照合やデータの中身の確認が中心になりがちですが、それに加えて「実際の業務の流れに沿って新システムを操作してみる」ことも重要な検証です。

たとえば、見積書を新規作成する、過去の取引先を検索して連絡先を確認する、月次の売上集計を出力する、といった日常的によく行う操作を、移行されたデータを使って実際に試してみます。データの中身が正しく見えても、実際に検索や集計といった操作を行うと、項目のマッピングミスや文字化けが原因でうまく動作しないことに気づく場合があります。

この検証は、システム管理の担当者だけで行うのではなく、実際にそのシステムを日常的に使う現場のスタッフに数名参加してもらうと精度が上がります。日々の業務でどのデータをどう使っているかを最もよく知っているのは、現場の担当者だからです。

移行リハーサルを必ず挟む

ここまで挙げた失敗パターンの多くは、本番移行の前に一度「リハーサル移行」を行い、結果を検証する工程を挟むことで事前に発見できます。リハーサルとは、本番と同じ手順・同じデータ（またはその一部）を使って、実際に移行処理を試し、結果を確認する作業です。

リハーサルを省略して、いきなり本番でデータを移行してしまうと、問題が見つかったときにはすでに旧システムの運用が止まっている、あるいは新システムでの業務がすでに始まっているという状況になりかねません。特に旧システムを解約・停止してしまった後に問題が見つかると、元データを参照して再移行することすら困難になります。

リハーサルで確認すべきこと

1. 想定していた件数と、実際に移行された件数が一致しているか（テーブルごと・項目ごとに集計して照合する）
2. 文字化けしている行がないか（特に住所・氏名など、日本語の特殊な文字を含みやすい項目）
3. 金額・数量などの数値項目が、桁ズレや誤変換なく移行されているか
4. サンプルで抽出したレコードを、旧システムの画面と新システムの画面で並べて見比べ、内容が一致しているか

件数照合は最も基本的でありながら効果の高い検証方法です。「旧システムで検索した件数」と「新システムに登録された件数」を突き合わせるだけで、移行漏れや重複の多くを機械的に検出できます。件数が合わない場合は、差分の理由（意図的に除外したデータなのか、漏れなのか）を必ず特定してから本番移行に進んでください。

移行後の検証体制も事前に決めておく

リハーサルと並んで重要なのが、本番移行後の検証です。移行が完了した直後は問題なく見えても、実際に日常業務でデータを使い始めてから初めて不具合に気づくケースは少なくありません。次のような体制をあらかじめ決めておくと、移行後のトラブルに素早く対応できます。

• 移行完了後、一定期間（例えば2週間〜1か月）は旧システムをすぐに参照できる状態で残しておく（解約・データ削除は検証期間終了後に行う）
• 各部署の代表者に、自分の担当領域のデータを新システムで実際に確認してもらう期間を設ける
• 不具合が見つかった場合の報告ルートと、開発会社への修正依頼の窓口を事前に決めておく

旧システムをすぐに解約・停止してしまうと、移行後に発覚した不具合の原因調査ができなくなります。契約更新のタイミングやライセンス費用の兼ね合いもありますが、可能であれば移行直後の一定期間は旧システムを並行して閲覧できる状態にしておくことを強くおすすめします。

開発会社に事前に確認しておきたいこと

データ移行を発注する、あるいは既存の開発契約の中でリプレイスを進める場合、次のような点を移行作業の着手前に確認しておくと、認識のズレによるトラブルを避けやすくなります。

• 移行対象データの範囲（テーブル・期間・添付ファイルを含むか）を明文化した資料があるか
• 移行リハーサルを実施する計画があるか。実施する場合、いつ・誰が結果を確認するか
• 文字コード・日付形式などのフォーマット変換について、変換ルールが文書化されているか
• 移行後、旧システムのデータをいつまで、どのような形で参照できる状態にしておくか
• 移行に伴う不具合が見つかった場合の対応（契約不適合責任の対象になるかどうかを含む）が、契約上どう扱われるか

これらは技術的な詳細をすべて理解していなくても、進捗確認の場で「確認しましたか」「資料はありますか」と尋ねるだけで十分に機能する質問です。データ移行という工程が「ブラックボックスのまま進んでいないか」を発注者側からチェックする役割を担うことが、非エンジニアの担当者にできる最大の予防策になります。

移行データのバックアップも忘れずに

意外と見落とされがちですが、移行元データ・移行先データの両方について、作業前の状態のバックアップを取得しておくことも欠かせません。万が一、移行処理そのものに問題があり、データが意図せず上書き・削除されてしまった場合でも、バックアップがあれば復旧の手段が残ります。

バックアップの取得は開発会社側の作業として進むことが多いですが、「移行前のバックアップは取得しますか、いつのタイミングのものが残りますか」という点は、発注者側からも確認しておくべき項目です。バックアップの設計思想については、3-2-1ルールと呼ばれる考え方が広く知られています。移行プロジェクトに限らず、日常的なバックアップ運用の参考にもなります。

移行スケジュールに余裕を持たせる

データ移行のトラブルの多くは、スケジュールの余裕のなさから生まれます。リプレイス全体の計画の中で、データ移行の作業期間が「念のため数日」程度しか確保されていないと、リハーサルで問題が見つかっても修正・再検証の時間が取れず、不完全な状態のまま本番移行に踏み切らざるを得なくなります。

特に注意したいのが、契約の解約タイミングとの兼ね合いです。旧システムのライセンス契約や保守契約の終了日に合わせて移行日を固定してしまうと、移行作業に遅れが生じた場合の調整余地がなくなります。可能であれば、旧システムの契約終了日と、新システムへの本番移行完了予定日の間に、1〜2週間程度の余裕期間を設けておくことをおすすめします。この期間があれば、移行後に見つかった不具合への対応や、万が一の切り戻し判断にも対応しやすくなります。

移行作業のスケジュールを開発会社から提示された際は、次の点を確認しておくと安心です。

• リハーサル移行の実施日と、その結果を確認・フィードバックする期間が確保されているか
• リハーサルで問題が見つかった場合、修正して再度リハーサルを行う時間的余裕があるか
• 本番移行の日程が、旧システムの契約終了日ぎりぎりに設定されていないか

移行担当者が変わる場合の引き継ぎにも注意する

リプレイスプロジェクトは数か月から1年以上にわたることも珍しくなく、その間に担当者の異動・退職が発生する可能性もゼロではありません。データ移行の判断（何を移すか、マッピングをどう決めたか）を1人の担当者の頭の中だけで進めてしまうと、途中で担当が交代した際に、判断の根拠が分からなくなり、移行作業自体が停滞する原因になります。

移行対象の範囲やマッピングの判断は、口頭のやり取りだけで済ませず、簡単なものでよいので文書やスプレッドシートに残しておくことをおすすめします。これは移行作業そのものの品質を上げるだけでなく、万が一の引き継ぎが発生した際のリスクヘッジにもなります。システム管理台帳のような形で、リプレイスに関する意思決定の記録を残しておく習慣は、今回のプロジェクトに限らず、今後のシステム管理全般でも役立ちます。

まとめ: データ移行を「最後の付随作業」にしない

リプレイス時のデータ移行は、要件定義や画面設計と同じくらい、事前の計画と検証が必要な工程です。移行対象の範囲を明確にする、フォーマットの差異を洗い出す、移行方式（一括か段階か）を選ぶ、リハーサルを行う、移行後の検証体制を用意する——これらを移行作業の計画に組み込むことで、データ欠損・文字化け・重複・マッピングミス・周辺連携の見落としといった典型的な失敗の多くは防げます。

いずれの対策にも共通しているのは、「移行処理そのものは開発会社に任せつつ、何を移すか・結果が正しいかの判断は発注者側が担う」という役割分担です。技術的な処理をすべて理解する必要はありません。移行の節目節目で「対象範囲は明確になっていますか」「リハーサルの結果は確認しましたか」と問いかけ続けることが、非エンジニアの担当者にできる最も実効性の高い備えです。

「移すだけの作業」と軽視せず、契約段階・移行着手前の段階から開発会社と認識をすり合わせておくことで、リプレイスというプロジェクト全体の成否も大きく左右されます。リプレイスの費用の内訳や、そもそもExcelからの移行を検討している段階の方は、関連記事もあわせてご確認ください。