CRMの乗り換え・Excelからの移行を、確認できる計画へ

顧客は移った。
案件と履歴も、正しい相手につながっていますか。

件数が合うだけで終わらせず、担当者・案件・対応履歴・添付まで確認する。移行前の準備から、テスト、本番切り替え、問題時の戻し方までを整理します。

「顧客一覧は取り込めたのに、どの会社の案件なのか分からない」

「過去の問い合わせは見えるけれど、添付ファイルが開けない」

CRMのデータ移行では、名前や住所の一覧を移すだけでなく、情報同士のつながりを引き継ぐ必要があります。顧客・担当者・案件・履歴がそれぞれ登録されても、関連付けが違っていれば、日々の仕事で使いにくくなります。

また、テストから本番切り替えまでの間に増えたデータ、退職者が残した履歴、別の場所へ保存された添付なども、移行の範囲に関係します。「CSVで出せるから大丈夫」と考える前に、何をどう移し、どう確認するかを決めましょう。

この記事では、中小企業がCRMの乗り換えやExcelからの移行を検討する際に使える、データ別のチェックリスト、旧IDと新IDの対応例、テスト移行と本番切り替えの確認手順を紹介します。

CRM移行で起きやすいのは、「入った」と「使える」の行き違い

CRMには、顧客の基本情報に加え、担当者、案件、見積もり、活動、問い合わせ、資料などがあります。どの情報がどこへつながるかを確認せずに取り込むと、次のような状態が起きます。

  • 同じ会社名の別拠点へ、案件や問い合わせが関連付いている。
  • 案件名や金額はあるが、営業ステージ・予定日・担当者が違う。
  • 履歴本文は移ったが、対応した人や当時の日時を確認できない。
  • 添付のファイル名だけがあり、実ファイルを取得できていない。
  • 管理者は見られるが、営業やサポートの権限では参照できない。
  • テストは成功したが、本番切り替え中の追加・更新が反映されていない。

移行計画では、データの対応付けと検証を、実際に使い始めるための準備へ結び付けます。Microsoftの導入ガイドでも、移行範囲・項目と値の対応・検証などを計画する考え方が示されています。[1]本記事では、その基本的な考え方も参考に、CRMで確認したい項目を整理します。

vtplusのデモで顧客企業に関連する2件の案件を表示した画面。金額や営業ステージも確認できる
デモ実画面:顧客企業に関連する案件。移行確認では、このように「正しい顧客から、対象の案件へ進めるか」も確かめます。移行作業の実行結果を示す画像ではありません。

最初に、移す・参照用に残す・見直すを決める

すべての情報を新しいCRMへ移すことが、必ずしも最適とは限りません。今後の業務と、過去の経緯を確認する必要性から、対象を分けます。

情報と機能を分けて、対象範囲を決める例
分類対象の例確認すること
新CRMへ移す取引中の顧客、進行中の案件、未完了の問い合わせ、必要な履歴・資料対象条件、基準日、関連先、移行後の使い方
参照用に残す頻繁に使わない過去履歴、旧帳票、対象外の添付保存場所、検索・閲覧方法、必要な期間、利用できる人
見直す・作り直す独自画面、入力ルール、通知、帳票、承認、外部連携データとは別に、設定・追加開発・動作確認の範囲を決める

過去の情報を「移さない」と決めても、すぐ削除するという意味ではありません。業務や保存の要件を確認し、必要なときに探して開ける形で残します。旧CRMの契約終了後に参照・出力できるかも確認しましょう。

データの移行と、機能の再現は別の作業です。プラグイン、数式、レイアウト、承認経路、メール送信などは、データを書き出しただけで移行先に再現されるとは限りません。

CRM移行前に確認する6つのこと

1.移行元の製品・バージョン・独自設定

製品名、クラウドか自社運用か、バージョン、独自項目、追加アプリ、ソース改修の有無を整理します。標準と異なる構成があれば、出力や関連の確認方法にも影響します。

2.データの種類・件数・容量

顧客だけでなく、担当者、案件、見積もり、履歴、添付などを分けて調べます。添付はファイル数と容量、本文は長文や改行の有無も確認します。画面の表示件数が、実際に移す範囲の件数と同じかも確かめます。

3.出力できる項目と、関連を示す識別番号

CSV・APIなどで、どの項目とデータを取得できるかを確認します。画面には見えても出力に含まれない項目や、履歴・添付を別の方法で取得する必要がある場合もあります。出力権限や利用制限、処理時間も調べます。

4.顧客の重複と、元データの品質

同じ顧客の二重登録、空欄、表記ゆれ、関連先が見つからない履歴などを確認します。どこまで整理して移すか、判断が必要なものを誰が確認するかを決めます。詳しい整理は、顧客マスタの見直しとして移行とは区別して計画します。

5.担当者と権限、退職者の記録

旧担当者と新しいユーザーの対応を整理します。退職者の履歴を残す際は、移行作業者へ一律に付け替えるのか、元の担当情報を別項目等へ保持するのか、実現可能な方法を確認します。閲覧・編集の権限も移行先で設計します。

6.連携・自動処理と、切り替えの制約

メール取り込み、Webフォーム、API、予定同期、ワークフロー、定期処理など、データを追加・更新する経路を一覧にします。ユーザーの画面操作だけを止めても、他の経路で更新が続くことがあるためです。業務上停止できる時間と、外部サービス側の調整も確認します。

顧客・案件・履歴・添付の移行チェックリスト

以下は移行計画へ転記できる確認項目の例です。各項目に「対象/対象外」「確認方法」「担当」「結果」「未解決事項」を付け、対象外の理由も残します。

顧客・担当者:名称だけでなく、管理単位と関係を確認する

顧客・担当者の確認項目
項目確認する内容
管理単位企業・支店・工場・請求先・納入先を、必要な区別を保って移せるか
識別と重複旧ID・顧客コードを取得できるか。統合・除外・保留の扱いを記録したか
企業と人物の関係顧客側の担当者が、正しい企業・拠点へ関連付いているか
連絡先と状態住所・電話・メール、異動・退職・連絡停止等の扱いを確認したか
自社担当と共有担当ユーザーや部門の対応、閲覧・編集範囲が意図どおりか

案件・見積もり:金額・段階・日付・明細を確認する

案件・見積もりの確認項目
項目確認する内容
関連する顧客・人物案件と見積もりが、正しい顧客・担当者・取引へつながるか
金額・通貨・税通貨、税込・税抜、税率、端数、値引きなどの扱いが一致するか
状態と日付営業ステージ・受注確度・予定日・受注日・見積有効期限を、意味をそろえて変換したか
商品と明細商品、数量、単価、並び順、合計の計算を引き継げるか。集計結果も確認したか
提出版・過去の帳票最新版と過去の版を区別できるか。発行済みPDF等を必要な形で残せるか

現在の商品価格や税設定で再計算すると、過去の見積もり金額が変わる場合があります。当時の値を記録として残すのか、新しい計算で作り直すのかを分けて確認します。

活動・問い合わせ・履歴:時系列と、誰の対応かを残す

活動・問い合わせ・履歴の確認項目
項目確認する内容
履歴の種類活動、コメント、メール、変更履歴など、どこまでを対象にするか
日時と順序タイムゾーン、時刻、作成日・更新日・対応日の意味を確認したか
記録者と担当者作成した人と対応責任者を区別できるか。退職者の情報をどう残すか
本文と状態長文、改行、日本語、HTML等の扱い、未完了・返答待ち・完了の対応が正しいか
関連と次の仕事正しい顧客・案件・問い合わせへつながるか。未完了タスクと期限が残るか

移行先の仕様により、元の作成者や作成日時を同じシステム項目へ設定できない場合があります。その場合は、元情報を別項目・参照用データ等に残す方法を決め、見え方を利用者へ説明します。

vtplusのデモで顧客企業に関連する9件の問い合わせを表示した画面。顧客担当者、対応担当、状態などを確認できる
デモ実画面:顧客に関連する問い合わせの一覧。移行後は件数に加え、顧客側の担当者、自社担当、未完了・完了などの状態も確認します。移行済みデータの検証結果を示すものではありません。

添付・文書:ファイル名だけでなく、実体と開ける権限を確認する

添付・文書の確認項目
項目確認する内容
実ファイルの取得ファイル名・リンク一覧だけでなく、対象のファイル本体を取得できたか
関連先と版どの顧客・案件・問い合わせの資料か。複数の関連先や版をどう引き継ぐか
欠損・内容件数・容量・取得エラーを照合し、必要なファイルを開いて確認したか
権限と外部リンク利用者の権限で参照できるか。旧環境の認証や契約に依存したリンクが残っていないか

同じファイル名でも別の資料の場合があります。同一ファイルをそのまま転送する構成では、ハッシュ値による内容照合も検討できます。一方、形式変換や再生成をする場合はハッシュが変わるため、別の確認方法を決めます。

旧IDと新IDの対応表を残し、関連をたどれるようにする

移行元の顧客番号と、移行先の内部IDが同じになるとは限りません。会社名や案件名だけで関係を付け直すと、同名の別データへつながる可能性があります。

そこで、移行元システム・データの種類・旧IDと、移行先の種類・新IDを対応付けます。旧IDが同じでも、顧客と案件では別のデータであることがあるため、種類も含めて扱います。

ID対応表の記入例(架空のデータ)
移行元・種類・旧ID移行先・新ID判断・関連の確認
旧CRM A/顧客/100顧客/1200採用する顧客。名称・拠点を確認
旧CRM A/顧客/101顧客/1200旧100と同一と確認し統合。採用値と判断理由を別途記録
旧CRM A/担当者/200担当者/2400旧顧客101との関係を、新顧客1200へ対応付け
旧CRM A/案件/300案件/3600顧客1200と担当者2400へ関連付けたことを確認

この表は考え方の例で、特定製品のID形式を示すものではありません。実際の変換では、データの依存関係に沿って取り込み順序を決めます。途中で失敗したデータを再実行する場合も、二重登録せずに扱えるよう、処理結果と対応表を残します。

テスト移行は、件数・関連・業務・所要時間を確認する

テスト環境と、自動処理の扱いを整える

本番データへ影響しない環境で試します。移したデータをきっかけに、実際の顧客へメールが送られたり、販売管理へ情報が送信されたりしないよう、テスト側の通知・外部接続・自動処理を確認します。

一方、通常の業務で必要なルールや連携は、本番と条件をそろえて検証する必要があります。「すべて止めて取り込めた」で終えず、取り込み時と運用開始時の設定を区別し、何をいつ有効にするかを記録します。

移行元の全件数ではなく、「対象件数」と照合する

元の顧客が1,000件でも、対象外や重複統合があれば移行先が同じ件数にはなりません。「対象外」「統合」「成功」「保留」「エラー」の内訳と、期待する移行結果を先に決めます。

件数に加え、同じ条件での金額合計、状態別の件数、関連先が見つからないデータ、添付の取得結果などを確認します。丸めや変換による差がある場合は、その理由を記録します。

重要な値と関連は広く照合し、実際の操作でも確かめる

重要項目や関連については、可能な範囲で全件の機械的な照合を行います。それに加え、進行中の案件、別拠点、退職者の履歴、長文、大きい添付など、性質の違うサンプルを使い、画面と業務で確かめます。

管理者だけでなく、営業・事務・サポートなどの権限で、検索、閲覧、更新、帳票、関連情報への移動を試します。Microsoftの公開チェックリストでも、移行データと実際の権限を使った受け入れ確認や、本番前の移行検証が挙げられています。[2]

処理時間を測り、修正後の再実行も確かめる

抽出・転送・変換・取り込み・関連付け・照合に、それぞれどれだけ時間がかかるかを測ります。一部のデータだけで成功しても、全量が予定した停止時間内に終わるとは限りません。

問題が見つかったら、修正内容と結果を記録して再確認します。本番切り替えに近い条件で予行を行い、手順、担当、判断する時点を確かめます。

本番切り替えでは、更新停止と差分の扱いを明確にする

テスト移行の後も旧CRMは使われるため、顧客や案件の追加・更新が発生します。本番では最終的にどの時点のデータを使い、テスト以降の変更をどう反映するかを決めます。

停止して移す方法と、差分を反映する方法を比較する

一定時間の更新停止が可能なら、停止後のデータを取得して移す方法が候補になります。データ量が多い場合などは、先に大部分を移し、最後に差分を反映する方法も検討します。

ただし、差分は追加データだけではありません。更新・削除・担当変更・関連の変更・添付の追加などを含め、取得できる範囲と整合性を確認します。方法と停止時間は、移行元の仕様と構成に応じて決めます。

本番切り替えの確認順序の例
段階主な作業確認・判断
切り替え前予行、手順の確定、利用者への案内、バックアップと戻し方の確認対象と受け入れ条件、担当・連絡先がそろったか
更新停止時対象の画面・API・取り込み・定期処理など、更新経路を制御どの時点のデータかを確定し、更新が続いていないか確認
最終反映最終出力または差分取得、取り込み、関連付け、照合対象・値・関連・ファイルの結果とエラーを確認
利用開始前業務と権限の確認、連携先と入力先の切り替え開始するか、延期・切り戻しかを責任者が判断
利用開始後実際の入力と連携を監視し、問い合わせに対応新旧の二重更新、未処理・重複・権限の問題がないか確認

停止中に届く問い合わせや受注の記録先も決める

システムを止めても、電話やメールで連絡が来る場合があります。停止中の記録をどこへ残し、いつ、誰が新環境へ反映するかを決めます。フォームや外部サービス側に蓄積された情報の再送・重複も確認します。

新旧CRMへ同じ情報を自由に入力すると、どちらが正しいか分からなくなります。切り替え後の入力先を明確にし、旧環境を参照用に残す場合は、その使い方を案内します。

切り戻しは、バックアップを用意するだけでは完了しない

切り戻しは、問題が起きたときに旧環境などへ戻して業務を再開するための計画です。「何が起きたら、誰が、いつまでに戻すと判断するか」を、本番前に決めます。

戻す条件と、戻した後の情報の整合性を確認する

重要な顧客・案件が参照できない、主要業務を進められない、予定した時間内に照合を終えられない、といった判断条件を整理します。軽微な表示差などは、業務への影響と対応期限を確認して扱いを決めます。

新CRMで入力を始めた後に戻す場合は、その間に追加・変更された情報をどう回収し、旧環境へ反映するかが必要です。また、すでに外部へ送ったメールや連携結果は、バックアップを戻しても取り消されません。実施した処理を確認し、重複や行き違いを調整する手順も用意します。

開始後の支援と、旧環境の終了を別の判断にする

利用開始直後は、移行漏れ・権限・検索・連携などの問い合わせ先を一本化し、影響と優先度を整理します。担当者が判断できないものを、技術担当や業務責任者へ渡す方法も決めます。

旧CRMの解約・削除は、必要な確認とデータ確保が済んでから、契約期限も踏まえて判断します。参照用のファイルや旧環境を残す場合も、検索方法、アクセス権、維持期間と担当を明確にします。

移行費用は、CSVの件数だけでは決まらない

費用に影響するのは、データ量に加え、関連の複雑さ、独自項目、品質、履歴や添付の出力方法、試行回数、切り替え条件などです。同じ件数でも、名簿だけを取り込む作業と、過去の対応まで関連を保つ移行では準備と検証が異なります。

vtplusでは、合意した範囲の単純なデータ取り込みと、既存CRMの関連を維持する移行を区分しています。関連を保つ移行は、調査・変換・補正・試行・検証などの作業を確認し、別途お見積もりします。CSV・APIなど、使う手段だけで基本費用に含まれるかが決まるわけではありません。

導入・移行費用と、利用開始後のサポート・アプリ・サーバー等の費用も分けて確認します。最新の条件は、料金・導入費用ページをご覧ください。

初回相談には、次の情報があると整理しやすくなります

  1. 現在のCRM名・バージョン・運用形態、独自設定や追加機能。
  2. 顧客・担当者・案件・履歴など、データの種類とおおよその件数。
  3. 添付のファイル数・容量、出力できる形式や制約。
  4. 利用部門・人数、必要な外部連携、改善したい仕事。
  5. 契約更新・解約の期限、希望する切り替え時期、停止できる時間。

分からないものは未定でも構いません。まず項目一覧や、確認に必要な範囲へ絞ったサンプルから、調査の進め方を整理します。

切り替えてよいかを判断する、最終チェックリスト

技術担当の「取り込み完了」と、利用部門の「業務開始可能」を分けて確認します。次の項目に確認者と結果を付け、問題が残る場合は、影響・対応期限・開始可否の判断を記録します。

確認記録には、例えば「確認項目/対象・基準日/期待する結果/実際の結果/証跡/確認者・確認日/未解決事項・対応期限/開始可否」を残します。チェックを付けるだけでなく、何を見て判断したかが分かる状態にしましょう。

CRMのデータ移行で、よくある質問

CSVで出力できれば、顧客や履歴はすべて移せますか?

出力できる項目と関連情報、移行先で受け取れる形式によって変わります。履歴・添付・独自項目が別の出力になる場合や、画面・承認・帳票等を再設定する必要がある場合もあります。実際の出力仕様とサンプルで確認します。

データの件数が合っていれば、移行成功ですか?

件数だけでは判断できません。値、顧客と案件・履歴の関連、添付、権限、主要な業務操作まで確かめます。重複統合や対象外がある場合は、そもそも同じ件数にならないこともあります。

業務を止めずに乗り換えられますか?

構成と移行元の仕様によって検討します。差分取得ができるか、各種連携の更新をどう扱うか、最終反映に必要な時間を調査します。停止なしの切り替えを一律にお約束するものではありません。

バックアップがあれば、いつでも元に戻せますか?

復元手順と所要時間の確認に加え、切り替え後の新規入力や外部へ送った情報の扱いが必要です。戻す期限と判断担当を決め、必要な範囲で復元や切り戻しを試しておきます。

過去の履歴や添付を、すべて新CRMへ入れる必要がありますか?

業務上の利用と保存・参照の要件から判断します。進行中の業務を優先し、過去情報は別の参照環境へ残す方法もあります。必要な情報を検索・閲覧でき、旧契約が終了しても困らないかを確認します。

移行先の画面だけでなく、移した後の仕事まで確かめる

CRMの移行は、データが入った瞬間が終わりではありません。正しい顧客から案件へ進める、過去の対応を探せる、必要な資料を開ける、担当者が続きを進められる。その状態を、移行結果として確かめましょう。

vtplusでは、移行元の構成と必要なデータを確認し、移す範囲、関連の対応、テスト、切り替え、利用開始後の支援を整理します。乗り換えを決める前でも、現在の困りごとから相談できます。