# 移行性（Portability）

## 移行性の基本方針

システムを既存環境から新環境へ、または将来的に異なる環境へ円滑に移行するためのインフラ・ミドルウェア戦略を以下に示す。

### 移行計画方針
- **ダウンタイムの最小化**: 計画的なシステム停止時間を最小限に抑える移行方式を採用
- **データ整合性の確保**: 移行前後でデータの完全性と整合性を保証する手順を確立
- **切り戻し計画**: 予期せぬ問題発生時に、迅速かつ確実に旧環境へ切り戻せる体制と手順を整備

### 移行方式方針
- **段階的移行**: 大規模な移行では、リスクを低減するため段階的な移行方式を検討
- **自動化の推進**: 移行作業の自動化を推進し、人為的ミスを排除し、効率化を図る
- **環境差異の吸収**: 異なるインフラ環境間での差異を吸収できるよう、標準化されたミドルウェア構成やIaC（Infrastructure as Code）を活用

### 移行対象方針
- **データ移行の優先**: 業務データの移行を最優先とし、データ損失や破損のリスクを排除
- **設定情報の管理**: インフラ・ミドルウェアの設定情報を一元的に管理し、新環境への適用を容易にする

---

## 移行性要件の実現方式

### D1. 移行時期 (Migration Period)

#### D1.1 移行のスケジュール (Migration Schedule)

##### D1.1.1 システム移行期間
- **要件**: 移行作業計画から本稼働までの期間を2ヶ月以内とする
- **実現方式・仕様**:
  - 移行計画フェーズ（1ヶ月）: 移行対象の洗い出し、データ移行方式の決定、リハーサル計画策定
  - 移行実行フェーズ（1ヶ月）: 環境構築、データ移行、システムテスト、本稼働
  - IaC（Infrastructure as Code）を活用し、新環境のインフラ構築期間を短縮

##### D1.1.2 システム停止可能日時
- **要件**: 本番システム停止は、週末の深夜帯（土曜日 0:00 - 日曜日 6:00）の最大6時間とする
- **実現方式・仕様**:
  - データベースのオンライン移行（例: AWS DMS, Azure Data Migration Service）を検討し、ダウンタイムを最小化
  - DNS切り替えによるトラフィック誘導で、サービス停止時間をユーザーから見えない形で吸収
  - 移行作業は複数回のリハーサルを実施し、手順の確立と時間計測を行う

##### D1.1.3 並行稼働の有無
- **要件**: 移行期間中の旧システムと新システムの並行稼働は行わない
- **実現方式・仕様**:
  - 新システムへの一括切り替え（Big Bang方式）を採用
  - 移行前のデータ同期は最終切り替え直前まで実施し、データ差異を最小化
  - 切り替え後は、旧システムは参照専用として一定期間保持し、切り戻しに備える

### D2. 移行方式 (Migration Method)

#### D2.1 システム展開方式 (System Deployment Method)

##### D2.1.1 拠点展開ステップ数
- **要件**: 複数拠点への展開は、段階的に実施し、各拠点での安定稼働を確認後に次拠点へ展開
- **実現方式・仕様**:
  - 拠点A（小規模）で先行導入し、運用ノウハウを蓄積
  - 拠点B（中規模）へ展開
  - 拠点C（大規模）へ最終展開
  - 各拠点へのインフラ展開は、IaCテンプレートを用いて標準化

##### D2.1.2 業務展開ステップ数
- **要件**: 新システムへの業務移行は、重要度の高い業務から段階的に実施する
- **実現方式・仕様**:
  - フェーズ1: コア業務（例: 受注管理）を新システムへ移行
  - フェーズ2: サブ業務（例: 顧客管理、在庫管理）を新システムへ移行
  - フェーズ3: 周辺業務（例: レポート生成）を新システムへ移行
  - 各フェーズで必要なインフラリソースの増強を計画的に実施

### D3. 移行対象（機器） (Migration Target (Equipment))

#### D3.1 移行設備 (Migration Equipment)

##### D3.1.1 設備・機器の移行内容
- **要件**: 旧環境の物理サーバー、ネットワーク機器は新システムでは利用せず、すべてクラウドインフラへ移行する
- **実現方式・仕様**:
  - 旧環境の物理サーバーは、P2V（Physical to Virtual）ツールを利用せず、クラウド上に新規VMインスタンスを構築
  - 旧環境のネットワーク設定は、クラウドのVPC/VNet構成に合わせた設計を新規に実施
  - 旧環境のストレージデータは、ネットワーク経由でクラウドのオブジェクトストレージまたはブロックストレージへ移行

### D4. 移行対象（データ） (Migration Target (Data))

#### D4.1 移行データ量 (Migration Data Volume)

##### D4.1.1 移行データ量
- **要件**: データベースデータ総量 1TB、ファイルデータ総量 5TB
- **実現方式・仕様**:
  - データベース移行は、マネージドDBサービスのデータ移行ツール（例: AWS DMS）を利用し、オンラインでのデータ転送を実施
  - ファイルデータ移行は、専用の高速データ転送サービス（例: AWS Snowball, Azure Data Box）またはネットワーク経由でのrsync/robocopyなどを検討
  - 移行データ量に応じたネットワーク帯域の確保と、移行期間の計画

##### D4.1.2 移行データ形式
- **要件**: データベースデータはリレーショナルデータベース形式、ファイルデータはオブジェクトストレージ互換形式
- **実現方式・仕様**:
  - データベースは、旧システムのRDBMS（例: Oracle）から新システムのRDBMS（例: PostgreSQL on RDS）へスキーマ変換ツールを用いて移行
  - ファイルデータは、旧システムのファイルサーバーからクラウドのオブジェクトストレージ（例: Amazon S3）へ直接移行。必要に応じてファイル名やメタデータの変換を実施

---

## テスト計画（移行性関連）

### 移行リハーサル
- **実施時期**: 本番移行の1ヶ月前までに複数回実施
- **テスト項目**:
  - 新環境のインフラ構築手順の検証
  - データベース、ファイルデータの移行手順と所要時間の計測
  - 切り替え手順（DNS変更、ロードバランサー設定変更など）の検証
  - 切り戻し手順の検証
- **合格基準**: 移行手順が確立され、所要時間が要件（システム停止可能日時）内に収まること

### データ整合性検証
- **実施時期**: 移行リハーサル時、および本番移行後
- **テスト項目**:
  - 移行前後のデータベースレコード数、テーブル構造、主要データの比較
  - ファイルデータのハッシュ値比較、またはファイル数・サイズ比較
- **合格基準**: 移行前後でデータの不整合がないこと

### 性能検証（移行後）
- **実施時期**: 本番移行直後
- **テスト項目**:
  - 移行後の新環境におけるシステム全体の応答時間、処理能力
  - データベースのCPU使用率、I/O性能
- **合格基準**: 移行後のシステム性能が「性能・拡張性」要件を満たしていること

---

## リスクと対策

| No | リスク | 影響 | 発生確率 | 対策 |
|----|--------|------|---------|------|
| 1 | データ移行失敗・破損 | 業務データ損失、システム復旧不能 | 中 | 複数回の移行リハーサル、データ整合性検証ツールの導入、バックアップ体制の強化 |
| 2 | 移行作業の遅延 | システム停止時間の超過、業務影響 | 中 | 詳細な移行計画とタイムライン策定、自動化ツールの活用、緊急時の人員増強 |
| 3 | 移行後の性能劣化 | サービス品質低下、ユーザー満足度低下 | 中 | 移行後の性能テスト実施、旧環境との性能比較、キャパシティプランニングの再評価 |
| 4 | 切り戻し失敗 | 長期的なシステム停止、業務継続困難 | 低 | 切り戻し手順の確立とリハーサル、旧環境の一定期間保持、データバックアップの確保 |
| 5 | 環境差異による不具合 | システム動作不良、予期せぬエラー発生 | 中 | 開発・テスト環境を本番環境に極力近づける、IaCによる環境構築の標準化 |
| 6 | 移行コストの超過 | 予算オーバー | 中 | 移行ツールの選定と費用対効果分析、クラウドリソースの最適化、専門家による見積もり |

---