フレームワーク活用ガイドひとことで言うと#
レガシーシステムから新システムへの移行を「6R」の分類で方針を決め、Strangler Figパターンなどを使って段階的に実行する移行戦略フレームワーク。
押さえておきたい用語#
- 6R（シックス アール）
- Rehost/Replatform/Refactor/Repurchase/Retire/Retainの6つの移行パターンを指す。
- Strangler Fig Pattern
- 新旧システムを並行稼働させ、機能単位で段階的に新システムに切り替える移行手法を指す。
- Dual Write（デュアル ライト）
- 移行期間中に新旧両方のシステムにデータを二重書き込みする手法。データ整合性を担保する。
- Cutover（カットオーバー）
- 旧システムから新システムに本番トラフィックを切り替える瞬間。ロールバック計画が必須。
- Feature Parity（フィーチャー パリティ）
- 新システムが旧システムの全機能を同等に提供できる状態。移行完了の判定基準になる手法である。
マイグレーション戦略の全体像#
こんな悩みに効く#
- レガシーシステムの移行を計画しているが、どこから手をつけるかわからない
- ビッグバン移行を計画して失敗した経験がある
- 移行中にビジネスを止められないという制約がある
基本の使い方#
具体例#
月間売上20億円のEC。オンプレのデータセンター契約更新が12ヶ月後に迫り、AWS移行を決定。全15コンポーネントを6Rで分類。
| パターン | コンポーネント | 理由 |
|---|---|---|
| Rehost | バッチ処理(3) | 変更不要、そのまま移設 |
| Replatform | DB(2) | RDSに移行、マネージド化 |
| Refactor | 注文API(1) | マイクロサービス化 |
| Repurchase | メール配信(1) | SaaS(SendGrid)に置換 |
| Retire | 旧管理画面(2) | 利用者ゼロ、廃止 |
| Retain | 基幹連携(6) | 後フェーズで対応 |
Rehostから着手して移行パターンを確立し、12ヶ月で9コンポーネントの移行を完了。データセンター契約更新を回避し、インフラコストが 月額850万円 → 520万円 に削減。
エンジニア70名のBtoB SaaS。モノリスのコードベースが50万行に膨れ、デプロイに45分、テストに1時間かかっていた。
Strangler Figパターンで機能単位にマイクロサービスを切り出す戦略を採用。最初に通知サービスを分離し、パターンを確立。
6ヶ月で分離したサービスは 4つ（通知・請求・認証・レポート）。モノリスのコードベースは 50万行 → 28万行 に減少し、モノリスのデプロイ時間が 45分 → 18分 に短縮。分離済みサービスは独立デプロイで 3分 以内。
人口30万人の自治体。COBOLで書かれた住民基本台帳システムが20年稼働しており、保守ベンダーが撤退を通告。2年以内の移行が必須になった。
6R分類でRepurchase（パッケージ置換）を選択。自治体向けクラウドパッケージを採用し、カスタマイズは最小限にする方針を決定。
データ移行は3段階で実施。初回の全件移行 → 差分移行テスト3回 → 本番カットオーバー。並行稼働期間を2ヶ月設け、新旧で同じ業務を実行して結果を突合した。全 127帳票 の出力一致を確認後、旧システムを停止。カットオーバー当日のトラブルはゼロだった。
やりがちな失敗パターン#
- ビッグバン移行を選択する — 全コンポーネントを一度に切り替えると、問題発生時に切り戻しが困難。Strangler Figで段階的に移行する
- Feature Parityを100%目指す — 旧システムの全機能を新システムに移植すると、使われていない機能まで再実装することになる。利用頻度の低い機能は移行対象から外す判断が必要
- データ移行を後回しにする — スキーマ変換・データクレンジングは想定の2〜3倍の工数がかかる。移行プロジェクトの初期から着手する
- 並行稼働期間を設けない — カットオーバー直後の問題を検出するには新旧比較が不可欠。最低2週間は並行稼働させる
まとめ#
マイグレーション戦略は6Rの分類で移行パターンを決定し、Strangler Figパターンで機能単位に段階的に移行する手法。ビッグバン移行を避け、1機能ずつ切り替えて検証するサイクルを回すことでリスクを最小化する。データ移行は工数が膨らみやすいため初期から着手し、並行稼働期間で新旧の動作一致を確認してからカットオーバーする手順が安全な移行の鍵になる。