顧客データの移行は、「エクスポートして取り込めば終わる作業」ではありません。移行作業の大半は、取り込む前のデータの整理と、新旧システムの項目の対応付け、そして本番前の移行テストに費やされます。ここを省くと、切り替え当日に取り込みエラーが続出したり、移行後に重複した顧客や文字化けしたデータが見つかったりして、現場の信頼を一気に失います。
成功させるための要点は、①移行の範囲を決める、②項目を対応付ける、③重複と表記の揺れを整理する、④本番と同じ手順で移行テストを繰り返す、⑤切り替え当日の段取りと切り戻しの手順を決める、の5つです。この順番を守れば、Excelからでも旧CRMからでも、移行は落ち着いて進められます。
この記事は、Excelや古いCRM・顧客管理システムから新しいシステムへ顧客データを移す担当者の方に向けて、移行の実務手順と、つまずきやすいポイントを具体的に整理したものです。
顧客データ移行の全体像
顧客データの移行は、次の流れで進みます。全体の期間は、データの量と汚れ具合、新システムの構造の違いによって大きく変わります。
- 移行の範囲を決める:どのデータを、いつ時点のものまで、どの粒度で移すかを決める。
- 現状のデータを調べる:件数、項目、入力の揺れ、重複、空欄の多さを把握する。
- 項目を対応付ける:旧データの項目を新システムのどの項目に入れるかを一覧にする。
- データを整理する:重複の統合、表記の統一、不要データの除外を行う。
- 変換と取り込みの手順を作る:変換のルールを決め、取り込み用のファイルや処理を用意する。
- 移行テストを行う:テスト環境で取り込み、件数と中身を照合する。問題を直して繰り返す。
- 切り替え当日の計画を立てる:旧システムの入力停止、最終データの抽出、取り込み、確認、公開の段取りを決める。
- 本番移行と切り替え:計画どおりに実施し、問題があれば切り戻す。
- 移行後の確認と旧データの保管:一定期間、現場からの問い合わせに対応し、旧データを読み取り専用で保管する。
移行全般の考え方はデータ移行の用語ページでも解説しています。以下、それぞれの手順で押さえておくべき点を見ていきます。
手順1:移行の範囲を決める
最初に決めるのは「何を移さないか」です。すべてのデータを移そうとすると、使われていない古いデータの整理にまで時間がかかり、移行全体が遅れます。
範囲を決めるときの観点は次のとおりです。
- 対象の期間:何年前までの取引先・商談・活動履歴を移すか。長期間取引のない顧客は移さず、旧データとして保管する選択もある。
- 対象のデータの種類:取引先、担当者(連絡先)、商談、活動履歴、見積もり、契約、添付ファイルなど、どこまで移すか。
- 履歴の粒度:活動履歴をすべて移すか、最新の数件だけにするか、要約して1項目にまとめるか。
- 添付ファイル:名刺画像や契約書のPDFなど、ファイルをどこに保管するか。
移さないデータも、捨てるのではなく、必要なときに参照できる形で保管しておきます。旧システムを読み取り専用で一定期間残す、CSVで書き出して保管する、などの方法があります。保管期間は、契約や法令上の保存義務も踏まえて決めてください。法令上の扱いは、専門家や公的窓口で最新の情報を確認することをおすすめします。
移行の体制と役割分担を決める
顧客データの移行は、情報システムの担当者だけでは進められません。項目の意味やデータの正しさを判断できるのは、日々そのデータを使っている営業や事務の担当者だからです。移行を始める前に、次のような役割を決めておきます。
| 役割 | 担うこと | 適任者の例 |
|---|---|---|
| 移行責任者 | 範囲・日程・切り戻しの最終判断 | 営業部門の責任者、プロジェクトの責任者 |
| データの持ち主 | 項目の意味の確認、重複統合の判断 | 営業マネージャー、営業事務の担当者 |
| 変換・取り込みの担当 | 変換処理の作成、取り込みとテスト | 情報システム担当、開発会社 |
| 現場の確認担当 | 移行テスト後の中身の確認 | 各チームの営業担当 |
特に「データの持ち主」を決めておくことが重要です。重複の統合や項目の読み替えで判断に迷ったとき、誰が決めるかが曖昧だと、作業が止まります。また、移行責任者は切り替え当日に連絡がつく人である必要があります。
手順2〜3:現状のデータを調べ、項目を対応付ける
現状のデータを調べる
旧データを書き出したら、項目ごとに次のことを調べます。
- 件数と、空欄の割合
- 入力されている値の種類(自由記述か、選択肢か)
- 表記の揺れ(「株式会社」と「(株)」、全角と半角、ハイフンの種類など)
- 同じ顧客が複数件登録されていないか
- 日付や電話番号の形式がそろっているか
Excelで管理していた場合は、シートごと・担当者ごとに書き方が違うことがよくあります。同じ「担当者」列でも、フルネームの人、姓だけの人、イニシャルの人が混在しているといった状況です。
項目の対応表を作る
旧データの項目と新システムの項目を対応付けた一覧表を作ります。これが移行作業の設計図になります。
| 旧データの項目 | 新システムの項目 | 変換ルール | 備考 |
|---|---|---|---|
| 会社名 | 取引先名 | 「(株)」を「株式会社」に統一、前後の空白を削除 | 名寄せのキーにも使う |
| 住所 | 都道府県/市区町村/番地 | 1つの文字列を分割 | 分割できないものは手作業 |
| 担当営業 | 所有者 | 名前を新システムのユーザーに対応付け | 退職者は引き継ぎ先に置き換え |
| ランク | 顧客区分 | A/B/C を新しい区分に読み替え | 区分の定義を事前に合意 |
| 備考 | メモ | そのまま移す | 長文は文字数上限を確認 |
| 最終訪問日 | 活動履歴 | 日付形式を統一して活動として登録 | 日付のないものは除外 |
対応表を作る過程で、「旧データにはあるが新システムに入れる場所がない項目」「新システムでは必須だが旧データにない項目」が見つかります。前者は移すか捨てるかを決め、後者は既定値を入れるか、移行後に入力してもらうかを決めます。この判断を現場の責任者と合意しておくことが、移行後のトラブルを防ぎます。
手順4:重複と表記の揺れを整理する
顧客データの移行でもっとも時間がかかるのが、この整理です。重複したまま移すと、新システムで同じ顧客が複数件表示され、担当の重複や連絡の行き違いが起きます。
重複の見つけ方
重複を見つけるには、比較に使うキーを決めます。法人顧客なら、会社名を正規化した文字列(法人格の表記を統一し、空白や記号を除いたもの)、電話番号、Webサイトのドメインなどを組み合わせます。個人の連絡先なら、メールアドレスが有力なキーになります。
キーが一致したものを候補として一覧にし、統合するかどうかを判断します。同じ会社でも、支社ごとに別の取引先として扱いたい場合もあるため、機械的に統合せず、ルールを決めてから進めます。名寄せの進め方や整理の具体的な方法はExcelデータをシステムに移す前のデータ整備で詳しく扱っています。
統合するときのルール
重複を統合するときは、どちらのレコードの値を残すかのルールを決めます。
- 更新日が新しいほうの値を優先する
- 空欄でないほうの値を優先する
- 活動履歴や商談は、両方のものを統合後のレコードにまとめる
- 担当者が異なる場合は、直近で接触した担当者を残す
このルールを決めずに手作業で統合すると、担当者ごとに判断が異なり、結果がばらつきます。
手順5〜6:変換と移行テスト
変換の手順を再現できる形にする
データの整理と変換は、手作業でExcelを直すのではなく、できるだけ手順を記録して再現できる形にします。移行テストは何度も繰り返すため、毎回手作業で同じ変換をしていると時間がかかり、ミスも増えます。変換用のスクリプトを用意する、Excelの関数や置換の手順を手順書として残す、などの方法があります。
文字と形式の落とし穴
移行テストで頻繁に見つかるのが、文字と形式に関わる問題です。あらかじめ次の点を確認しておくと、テストの回数を減らせます。
- 文字コード:古いシステムやExcelから書き出したCSVは、新システムが想定する文字コードと異なることがある。取り込み時に文字化けしたら、まず文字コードを疑う。
- 機種依存文字:丸数字、ローマ数字、旧字体の漢字などが、新システムで表示できないことがある。会社名や人名に含まれる場合は特に注意する。
- 先頭のゼロ:電話番号や郵便番号、顧客コードの先頭のゼロが、Excelで開いた時点で消えてしまうことがある。数値ではなく文字列として扱う。
- 日付の形式:和暦と西暦、スラッシュとハイフン、日付と時刻の混在などをそろえる。
- セル内の改行:備考欄の改行が、CSVの行区切りと誤認されて行が分かれることがある。
- 文字数の上限:新システムの項目に文字数の上限があると、長い備考が途中で切れる。
移行テストで確認すること
テスト環境に取り込んだら、次の点を確認します。
- 件数の照合:旧データの件数と、取り込まれた件数が一致するか。除外したものはその件数と理由が説明できるか。
- 中身の照合:無作為に選んだ数十件について、旧データと新システムの表示を目で見て比べる。
- 関係の照合:取引先と担当者、商談、活動履歴の紐づけが正しいか。
- 文字の確認:文字化け、機種依存文字、改行の扱いに問題がないか。
- 現場での確認:営業担当に自分の担当顧客を見てもらい、違和感がないかを確認する。
テストに使う環境は、本番と同じ設定にしておきます。項目の必須設定、入力規則、自動処理(登録時に通知を送る、担当者を割り当てるなど)が本番と違うと、テストでは通ったのに本番で取り込みエラーが出る、あるいは移行した大量のデータに対して自動処理が動いて通知が大量に送られる、といった事故が起きます。移行の間だけ自動処理を止めるかどうかも、あらかじめ決めておきます。
移行テストは一度で終わることはまずありません。問題を直して再度取り込み、件数と中身を照合する、という流れを2〜3回繰り返す計画にしておきます。最後のテストは、本番と同じ手順・同じ順番で行い、作業時間を計っておくと、切り替え当日の段取りが立てやすくなります。
手順7〜8:切り替え当日の運用
切り替え当日は、次のような段取りで進めます。
- 旧システムの入力を止める:事前に周知した時刻に、旧システムへの新規入力と更新を止める。
- 最終データを書き出す:入力停止後のデータを書き出す。
- 変換して取り込む:テストで固めた手順どおりに変換し、新システムに取り込む。
- 件数と中身を照合する:テストと同じ方法で確認する。
- 現場に公開する:問題がなければ新システムの利用を開始する。
- 旧システムを読み取り専用にする:誤って旧システムに入力されないようにする。
切り戻しの判断基準を決めておく
当日に問題が見つかったとき、そのまま進めるか、旧システムに戻すかを判断する基準を事前に決めておきます。たとえば「件数の不一致が説明できない場合」「主要な取引先の紐づけが壊れている場合」は切り戻す、といった基準です。判断する人と、切り戻しにかかる時間もあらかじめ確認しておきます。リプレイス全般の移行計画についてはリプレイス時のデータ移行計画も参考になります。
切り替え日の選び方
切り替え日は、営業活動への影響が小さい日を選びます。月末や四半期末の締めの時期、繁忙期は避け、週の後半に切り替えて週末に確認する、といった選び方が一般的です。
具体的な場面で考える
架空の例として、Excelで顧客管理をしていた営業10名ほどの会社が、新しいCRMに移行するケースを考えます。
この会社では、営業担当ごとに顧客一覧のExcelファイルを持っており、共通の顧客マスタはありませんでした。ファイルを集めて結合すると数千件になりましたが、調べてみると同じ会社が複数の担当者のファイルに登録されていたり、会社名の表記がばらばらだったりしました。
そこで、まず「直近数年で取引または接触のある顧客」に範囲を絞り、それ以外は書き出して保管することにしました。次に、会社名の表記を統一し、電話番号とあわせて重複の候補を出しました。重複候補は各担当者に確認してもらい、直近で接触した担当者を所有者として残すルールで統合しました。
移行テストは3回行い、1回目は文字化けと日付の形式、2回目は担当者の対応付けの漏れ、3回目でようやく件数と中身がそろいました。本番は金曜日の夕方に入力を止めて取り込み、週末に確認したうえで、翌週月曜日から新システムの利用を開始しました。
移行後の確認と定着
切り替えが終わっても、移行作業は完了ではありません。移行直後の数週間は、現場から「顧客が見つからない」「担当者が違う」「前の画面にあった情報がない」といった問い合わせが集中します。これに素早く対応できるかどうかで、新システムへの信頼が決まります。
移行後は次のことを行います。
- 問い合わせ窓口を一本化する:移行に関する質問や不具合の報告先を一か所に決め、対応状況を共有する。
- よくある質問をまとめて周知する:同じ質問が何度も来る場合は、答えをまとめて全員に共有する。
- データの修正ルールを決める:移行後に見つかった誤りを、誰がどのように直すかを決めておく。個人が勝手に直すと、修正の履歴が追えなくなる。
- 重複の発生を監視する:移行後に新たな重複が生まれていないか、定期的に確認する。新規登録時に重複を警告する仕組みがあれば有効にする。
- 旧データの保管期限を決める:読み取り専用で残した旧システムやCSVを、いつまで保管し、いつ廃棄するかを決める。
移行をきっかけに、データの入力ルールを見直すのも有効です。会社名の表記ルール、必須項目、重複時の対応を決めて新システムに組み込んでおけば、移行で整えたデータの状態を保ちやすくなります。取引先や商品などの基本データを保つ考え方は、マスタデータの用語ページでも解説しています。
よくある失敗と避け方
- すべてを移そうとする:古いデータや使われていない項目まで移そうとして、整理に時間がかかる。範囲を最初に決め、移さないデータは保管する。
- 整理を移行後に回す:「とりあえず移して、新システムで直す」とすると、重複したデータのまま運用が始まり、直す機会を失う。移行前に整理する。
- 手作業で変換する:毎回手作業だと、テストのたびに結果が変わる。変換手順を再現できる形にする。
- 現場の確認を省く:件数が合っていても、担当者の紐づけが間違っていることがある。営業担当に自分の顧客を確認してもらう。
- 切り戻しを考えていない:当日に問題が出たとき、進めるか戻すか決められずに混乱する。判断基準と手順を事前に決める。
- 旧システムを開けたままにする:切り替え後も旧システムに入力する人が出て、データが分散する。読み取り専用にする。
移行前のチェックリスト
- 移すデータと移さないデータの範囲が決まっているか
- 移さないデータの保管方法と保管期間が決まっているか
- 項目の対応表があり、現場の責任者と合意しているか
- 重複の判定キーと統合のルールが決まっているか
- 変換手順が再現できる形で記録されているか
- 移行テストを本番と同じ手順で行い、作業時間を計ったか
- 件数・中身・関係の照合方法が決まっているか
- 切り替え日と入力停止の時刻を現場に周知したか
- 切り戻しの判断基準と判断者が決まっているか
よくある質問
Q. 移行テストは何回くらい行えばよいですか?
データの量や汚れ具合によりますが、2〜3回を見込んでおくのが現実的です。1回目で見つかった問題を直し、2回目で直ったことを確認し、最後は本番と同じ手順で通しの確認をします。問題が多い場合は回数を増やします。
Q. 移行中も営業は顧客情報を更新し続けますが、どう扱えばよいですか?
テスト期間中は旧システムで通常どおり業務を続け、本番の切り替え時に最新のデータを書き出して移します。そのため、変換手順を再現できる形にしておくことが重要です。切り替え当日だけは入力を止める時間帯が必要になるので、事前に周知します。
Q. 旧CRMの活動履歴はすべて移すべきですか?
必ずしもすべてを移す必要はありません。直近の数年分だけを移し、それ以前のものは書き出して保管する、あるいは要約して1つのメモにまとめる方法もあります。新システムで日常的に参照するかどうかを基準に判断します。
Q. 移行は自社でもできますか?
件数が少なく、項目の構造が単純で、新システムに標準の取り込み機能があれば、自社で進められることも多いです。重複が多い、複数のファイルやシステムからデータを集める、項目の構造が大きく異なる、といった場合は、変換の仕組みを作れる人の手を借りると安全です。
Otsumuに相談できること
件数が少なく、新システムの取り込み機能で対応できる移行であれば、この記事の手順とチェックリストに沿って社内で進められます。特に、移行の範囲の決定や項目の対応付けは、業務をよく知る社内の担当者が主導するのがもっとも確実です。
一方で、複数のExcelや旧システムからデータを集めて名寄せする必要がある、変換のルールが複雑で手作業では再現できない、新システム自体を作る・作り替える必要がある、といった場合は、変換の仕組みを作れる外部の力を借りたほうが、移行テストを効率よく繰り返せます。移行の失敗は、新システムへの信頼を損なうため、最初の一歩を確実にすることが大切です。
Otsumuでは、移行範囲の整理、項目の対応表づくり、重複の統合ルールの設計、変換処理の開発、移行テストの実施までを一貫して支援します。新しい顧客管理システムを作る場合は、移行のしやすさも含めて設計します。詳しくはCRM開発のページをご覧ください。
どこから手をつければよいか分からない段階でも構いません。30分の無料相談で、データの状況を伺いながら移行の進め方を整理します。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆:Otsumu株式会社 / 編集日 2026.10.01