1) 事前評価（Assessment）
- 目的：依存関係、互換性問題、Data types、サイズ、プロシージャ／トリガーの量、LOBやパーティションなどを洗い出す。
- 推奨：EDBのMigration Portalでスキーマをアップロードして自動評価を行うと、互換性アセスメントと推奨変換が得られます。大規模ならプロファイリング（クエリ実行頻度、長時間実行クエリ）も実施。
2) ツール選定（何を使うか）
- EDB Migration Portal / Migration Toolkit（EDB公式）
スキーマ変換支援・DDL生成・一部のPL/SQL変換サポートがあるため、EDB（EPAS）に移すならまず有力候補。 - ora2pg（OSS）：
無償で成熟したツール。スキーマ抽出・DDL変換・データエクスポートが可能で、多くの事例がある。小〜中規模やカスタム対応で有用。 - CDC（継続レプリケーション）ツール（切替をほぼゼロダウンタイムで行う場合）
例：Quest SharePlex、Debezium、または商用のレプリケーション製品。初期ロードはora2pg/EDBツール、差分はCDCで追従する設計が多い。
3) スキーマとコードの変換（DDL・ストアド・トリガー）
- 自動変換ツール（Migration Portal / Migration Toolkit / ora2pg）でまずDDLとオブジェクトを変換。
- 注意点：データ型（NUMBER→numeric/integer）、シーケンス、日付型、NULL/空文字の扱い、パーティション、LOBの扱い、Oracle固有の機能（パッケージ、カーソル、暗黙の型変換）等は手作業レビューが必要。
- PL/SQLは自動変換で8〜9割対応できることもあるが、複雑なパッケージやダイナミックSQLは手動で書き換える必要が出る。EDBのEPASはOracle互換機能があり変換工数を削減できる場合がある。
4) データ移行（初期ロード）
- 初期ロードはツールで一括エクスポート→インポート（CSV、COPY、または専用ロード）で行う。大容量データは並列ロード、インデックス・制約は後付けでロード効率を上げる。
- LOBやBLOBは取り扱いに注意（ツールのドキュメント確認）。トランザクション境界やコミット頻度も調整する。
5) 差分同期・切替（ダウンタイム最小化）
- 要件によるが「完全停止で一気に切替」か「ほぼゼロダウンタイム」か方法を決定。
- ほぼゼロダウンタイムの場合：初期ロード後にCDCで変更を適用（SharePlex、Debezium等）→アプリケーションのリード/ライトを段階的に切替→最終同期→切替・検証。
6) テスト（機能・性能・回帰）
- 単体テスト：ストアドプロシージャ、トリガー、例外処理、カーソルの動作を確認。
- 負荷／性能テスト：インデックス、クエリプランの差異を洗い出し、必要に応じてインデックスや統計情報を調整。Postgres（EDB）はオプティマイザがOracleと異なるためチューニングが必要。
7) 運用準備と切替後チューニング
- 監視、バックアップ/リカバリ（pg_basebackup/EDBツール）、権限・接続プール、運用手順を整備。
- 切替後は実運用負荷を見てクエリチューニング、パラメータ調整（shared_buffers, work_mem 等）を行う。
典型的な移行パターン（小まとめ）
- 小〜中規模：ora2pgでスキーマ＋データ → 手動でPL/SQL修正 → 切替（短時間停止）｡
- 大規模／業務連続性重視：EDB Migration Portalで評価 → Migration Toolkit/EDBプロの支援で変換 → CDC（SharePlex/Debezium等）で差分同期 → 切替（ほぼゼロダウン）。
リスクと対策（重要）
- PL/SQL互換性とアプリ変更工数を過小評価しない（プロシージャ/パッケージの再実装が発生）。
- 性能差：同じSQLでも実行計画が異なるため、性能回帰の可能性あり → 本番同等負荷での検証必須。
- 長期サポート/運用体制：DBAのスキルセット（Postgres運用）を確保すること。
推奨アクション（今すぐできること）
ダウンタイム要件が厳しいなら、CDCソリューション（例：SharePlex、Debezium）での差分同期設計を並行検討。
現行OracleのスキーマDDL（小さめのスキーマや代表的なスキーマ）を用意して、EDB Migration Portalへアップロードしてみる（互換性レポート取得）。
小さなスキーマでora2pgを試して、DDL・データ移行の流れをハンズオンで確認する（問題点を洗い出せます）。