Salesforceからの移行
失敗事例・原因・対策
機能・運用・データの3つの落とし穴を回避し、
スムーズなCRM移行を実現するための完全ガイド。
1. 機能面での失敗事例
Salesforce特有の高度な機能に依存しすぎると、移行先で壁にぶつかります。
自動化 独自機能が再現できない
プロセスビルダーやFlowで行っていた自動メールやタスク生成が、移行先で実装できず業務効率ダウン。
要件をリスト化し、外部RPAツールやAPI連携で補完。開発工数を見積もって段階的にテスト導入する。
アプリ 連携アプリが使えない
AppExchangeの見積・帳票アプリに依存していたが、移行先に代替アプリがなく業務フローが崩壊。
アドオンを棚卸しし、代替手段を調査。不要な機能はこの機会に廃止しシステムをシンプル化する。
開発 Apex/LWCが動かない
独自コードでガチガチにカスタマイズしていたが、新環境ではゼロから再構築となりコストが膨大に。
カスタム処理が本当に必要か再評価。標準機能やスクリプトでの代替を検討し、ミニマムで再実装。
モデル データ構造の不一致
オブジェクト構造の違いを考慮せず移行し、データが散逸。どのデータをどこに入れるか現場が混乱。
事前にオブジェクト対応表を作成。フィールドの統廃合を行い、新CRMに適した構造へ再設計する。
2. 運用面での失敗事例
システムの変更は「人の変更」。準備不足は現場の混乱を招きます。
ユーザトレーニング不足
操作方法が分からず現場から反発が発生。入力ミスも多発。
ガバナンスの欠如
追加要望が五月雨式に出てきて、スケジュールと予算が超過。
運用ルールの未整備
入力規則や必須チェックが外れ、データの品質が一気に低下。
3. データ面での失敗事例
「ゴミデータ」を移行しても、新しいシステムが汚れるだけです。
重複・不要データの移行
失敗: クレンジングせずに移行し、顧客レコードが重複だらけに。
対策
事前に集計・分析し、名寄せを行う。最新データのみを優先移行する。
文字コード・形式エラー
失敗: 日付形式や文字化けでインポート失敗を繰り返し、工数が爆増。
対策
文字コードと日付型を統一。少量データでのテスト移行を必ず実施する。
全履歴移行の破綻
失敗: 10年分の履歴を全て移行しようとしてスケジュール遅延・容量オーバー。
対策
直近数年分に限定し、古いデータはアーカイブ化。取捨選択方針を決める。
まとめ：成功のカギは「準備」と「テスト」
Salesforceからの移行リスクを低減するには、
独自の機能をどう再現するか検討する「要件定義」、ゴミを持ち込まない「データ整備」、
そして段階的な「テスト移行」の徹底が不可欠です。