移行は 「やる前」と「やった後」のメリットだけ語られがちですが、移行プロジェクト自体が地獄になりがち。両 DWH を並行運用 → 切替の流れで、3 ヶ月で完遂するための計画術を共有します。
3 ヶ月計画の全体像
| 月 | フェーズ | 主な成果物 |
|---|---|---|
| 1 月目 | 棚卸し・並行運用設計 | 現行ジョブ一覧、対応表、移行 PoC |
| 2 月目 | 実装・並行運用 | 新 DWH でジョブ稼働、データ突合 |
| 3 月目 | 切替・廃止 | 接続切替、旧 DWH 停止、報告書 |
1 月目：棚卸しが命
「使ってないテーブルが半分以上」が普通。移行する前に捨てることで、移行コストを大きく下げられる。
- 全ジョブの棚卸し：DAG / / BI / アドホック → 1 つの一覧表に
- 最終アクセス日：90 日アクセスなしのテーブル → 移行対象外
- 所有者の確認：「これ使ってますか」を全テーブルで聞いて回る（地味だが必須）
- 移行 PoC：5〜10 テーブルで実際に新 DWH へ移してみる、性能・互換性を確認
2 月目：並行運用がポイント
新旧両方にデータを書き込み、整合性チェックを毎日回す。整合性が取れたら段階的に新 DWH に切替。
- 1 二重化：新 DWH にも同時に書く（既存パイプラインを分岐）
- 2dbt の二重実行：両 DWH で同じ model を build（profiles.yml で target 切替）
- 3整合性チェック日次：行数・SUM・GROUP BY が一致するか自動確認
- 4BI ダッシュボード並行公開：旧 / 新で見比べられる状態に
3 月目：切替の作法
- 段階切替：いきなり全切替せず、ダッシュボード単位で順次
- ロールバック準備：旧 DWH を最低 30 日は残す（突然の差戻しに備える）
- 業務時間外切替：金曜夜〜土曜午前で。月初は避ける
- コミュニケーション：BI ユーザー全員に切替日時を 2 週間前に通知
ありがちな失敗
失敗 ① 棚卸しを飛ばす
「全部移しちゃおう」は破綻パターン。半年経っても終わらない。捨てるフェーズに 2 週間を必ず確保。
失敗 ② 方言の互換性を甘く見る
の `STRUCT` や `ARRAY_AGG` は に直接移植できない。SQL 方言の差異を 1 月目の PoC で必ず洗い出す。
失敗 ③ コスト試算を移行後にやる
「移行したら月コストが倍になった」事故。移行前にクエリパターンから新 DWH のコストを試算し、想定外なら別ツール / 設計見直し。
ふくふくの進め方
「DWH 移行を計画している / 始めたが進まない」というご相談には、棚卸し（2 週間）→ 移行計画書作成 → 並行運用伴走 → 切替実施を 3〜4 ヶ月で。過去の経験から「捨てる」「圧縮する」のノウハウが一番効くフェーズです。
シリーズ後半予告（EP.13〜）
次のテーマブロック（EP.13 以降）では、Data Mesh、リアルタイムストリーミング、データプロダクトマネジメント、生成 とデータ基盤の融合などを扱います。シリーズの最初に立てた「壊れない基盤」の延長線で、現代的なテーマに踏み込んでいきます。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。