データ移行計画

位置づけ: 後続フェーズ

概要

新CRMのデータ移行は、旧BT社DBを移行元、新CRMのデータベースを移行先とする。移行方式は年末休業期間中の一括移行を基本線とし、業務を一時停止して切り替える。申請系業務は他業務からの独立性が高いため、移行本体から切り離して先行納品する（先方合意済み）。旧システムとの並行運用は行わない。切替直後の参照用に、旧DBは読み取り専用で残す。

本ページは、2026-07定例会（P4/P5ヒアリング）で確定したスケジュールとデータ移行方針を、移行計画の観点でマスタ・トランザクション・コード体系・クレンジング・検証基準まで展開したものである。

移行対象の規模感は、BT社資料「既存データ移行お見積」に基づく旧見積の実績値（成約顧客一覧 137項目・1,687件）を参考値として引き継ぐ。対象範囲・スキーマは新CRM側の再設計に合わせて改めて棚卸しする。実データの件数・容量・PIIは本ページに記載しない。

スコープ/対象

区分	内容
移行元	旧BT社DB
移行先	新CRMのデータベース
対象範囲	マスタ系（商品・商社・メーカー・営業マン・価格表。商品・商社は第1弾で先行実装済みのため、旧DBの新マスタへの差分取込に限る）＋トランザクション系（顧客・世帯、商談、活動ログ、見積、KPI実績）
対象外	第1弾で先行稼働済みの催事・アイテム・商社データ（継続利用扱い。IDの衝突回避のみが論点）
先行納品	申請系（独立業務）は移行本体と切り離し、先行納品・先行運用とする

データ（エンティティ表：旧DB→新DB マッピング）

マスタ系

対象マスタ	新DB側の受け皿	移行方式	備考
商品（アイテム）マスタ	新CRMのアイテムマスタ（第1弾実装済み）	突合・差分取込	Product.model（型番＝主キー、`crm_app/app/src/lib/masters.ts`）をキーに照合する。SalesPrice.productNo は型番を指す名称参照であり主キーではないため、照合は Product.model 基準で行う。旧DBの型番表記ゆれ（全角/半角・大文字小文字・ハイフン有無等）は現時点で未正規化のため、移行時に正規化ルールを別途定める
商社・仕入先マスタ	商社（卸）マスタ（第1弾実装済み）	差分取込	商社別軸案件管理との整合を確認する
メーカーマスタ	Manufacturer（試作実装あり）	新規整備＋旧DB照合	価格表・見積モジュールの前提
営業マンマスタ（インセンティブ等級含む）	新設テーブル（KPI予実で使用）	Excel等級表からの初期投入	本番DBに評価テーブルが存在しないため新規構築
価格表（PriceBook／SalesPrice）	CRM側で価格を保持（2026-07-17方針）	現行価格の初期投入＋反映日設定	反映日起点の現在価格導出を移行時に検証する

トランザクション系

対象データ	新DB側の受け皿	移行方式	論点
顧客・世帯（Household）	Household テーブル（試作あり）	名寄せ後に一括投入	クレンジングの主戦場。PII取扱いルールを別途定める
商談（Deal：channel／venue／createdAt 等）	Deal テーブル（試作あり）	channel区分をマッピングして投入	旧DB区分値→訪問販売/催事/反響/パートナーの対応表を作成する
活動ログ・架電（前確）・申込・タスク	各試作モデル	直近分を優先して投入	過去分の保持期間は「確認事項」参照
見積（quotes）	Quote テーブル（試作あり）。見積モジュールの画面は後続実装	進行中案件のみ移行し、完了案件はアーカイブ参照とする	移行範囲の線引きは「確認事項」参照
KPI実績（営業マン別 M1/M2実績）	実績テーブル（新設）	Excelからの初期投入	予算・評価テーブルが本番DBに存在せず、移行ではなく新規構築

旧見積（BT社資料）の「成約顧客一覧」137項目は、現行CRMの customers / contracts / contract_additional_materials 等に分解してマッピングされると推測される（未検証。data-migration 参照）。新CRMへの移行では、この旧Excel項目群を Household・Deal・見積等の新スキーマへ再マッピングする対応表を移行成果物として整備する。

画面・機能（移行ツールと手順）

移行はETL方式の使い捨てスクリプトで実施する。リハーサルで同一スクリプトを繰り返し実行し、精度と所要時間を計測する。

フェーズ	時期	内容
申請系先行納品	年末休業より前	独立業務のため単独で納品・運用を開始する
リハーサル移行（第1回〜N回）	本番移行の数週間前	本番相当データで全スクリプトを通し、所要時間と疑義件数を計測する
データ凍結（フリーズ）	年末休業初日	旧DBへの入力を停止し、最終バックアップを取得する
本移行実行	休業期間中	抽出→変換→投入→整合チェックを一括実行する
検証・受入判定	休業期間中〜年始直前	「検証・受入基準」節の基準で判定する。不合格の場合はロールバックし、旧システムで年始業務を再開する
切替・年始稼働	年始営業初日	新CRMで業務を開始する。旧DBは参照用に読み取り専用で保持する

この工程は、meeting-log 2026-07（P4/P5ヒアリング）で確定した「12月末に本丸（P1〜P5）納品→12月に研修・検証→1月完全切替」「データ移行は年末休業中」「申請系は独立業務のため先行納品を検討」（先方合意）を、移行計画の観点で展開したものである。時期・所要時間の具体値はリハーサルの実測で確定する。

業務ルール／ワークフロー

コード体系の引継ぎとID設計

新DBの各テーブルに旧DBのIDを保持する引継ぎカラム（legacy_id）を設け、移行後も新旧の突合・遡及調査を可能にする。将来構想（AIエージェント、商社明細スキャンの自動取込、SaaS化・分社化）を見据え、この引継ぎカラムは拡張余地を残す設計とする。
商品の業務キーは Product.model（型番＝主キー）であり、そのまま引き継ぐ。SalesPrice.productNo は型番を指す名称参照であり主キーではない点に注意し、Product.model×channel×反映日の複合構造と整合させる。旧DBの型番表記ゆれ（全角/半角・大文字小文字・ハイフン有無等）は現時点で未正規化のため、移行時に正規化・突合表の整備が必要。
channel・ステータス等の区分値は「旧コード→新コード対応表」を移行成果物として作成し、先方レビューを経て確定する。
参照整合性（Deal→Household、見積→価格表等）は、投入順序を依存関係順に固定して担保する。
第1弾稼働分（催事・アイテム・商社）で発番済みのIDと旧DB由来データは、採番帯を分離して衝突を回避する。

クレンジング方針

世帯・顧客の名寄せは、氏名・住所・電話の表記ゆれによる重複を自動統合し、判定困難な組は疑義リストとして目検する。
必須項目の欠損（連絡先なし等）や日付異常は移行前に疑義リスト化し、先方確認のうえ補正または欠損のまま取込むかを判断する。
廃番商品・取引終了商社は、過去トランザクションから参照が残るため削除せず、無効フラグ付きで移行する。
クレンジングの実施は、機械処理をOuver、業務判断をバリューエコロジー側が担当する分担とする。
疑義件数・補正件数は移行報告書にプレースホルダで記録し、受入判定の材料とする。

検証・受入基準

件数突合: 旧DB抽出件数＝新DB投入件数＋除外件数（除外理由付き）が全テーブルで成立すること。
金額整合: 売上・粗利等の集計値が現行KPI Excel（営業マン別シート）の値と一致すること。KPIダッシュボードの正しさの前提になる。
サンプル目検: 世帯・商談・見積からN件ずつ抽出し、先方担当者が画面上で旧システムと突合する。
業務シナリオ検証: 架電→商談→申込→タスク（前確・太陽光工程）の一連の流れが移行データ上で成立することを確認する。
不合格・重大不整合が生じた場合は旧システムへロールバックし、年始業務を旧システムで再開する。

確認事項

旧BT社DBのスキーマ・データ品質の詳細調査は未実施。調査結果次第でクレンジング工数と移行範囲が変動する。
営業マンマスタ・等級表の整備状況に応じて、KPI実績（予算・評価テーブル）の新規構築スケジュールが変動する。
年末休業の実日数と移行所要時間のバランスはリハーサル計測後に確定する。不足時は範囲縮小か凍結前倒しを協議する。
申請系の先行納品期間中は旧新の二重メンテ（マスタ変更の反映漏れ等）が発生しうるため、同期ルールを別途定める。
ロールバックの判断期限（年始稼働に間に合う最終判断日時）は先方と合意していない。
活動ログ・見積等の過去データの保持期間（過去N年分等）は先方と協議中。

データ移行 計画

概要