Oracle DatabaseからAzure Database for PostgreSQLへ移行する際、最初の壁になりやすいのがスキーマ変換です。2026年6月に一般提供された更新により、Visual Studio CodeのPostgreSQL拡張機能から、OracleのスキーマオブジェクトをAzure Database for PostgreSQL互換のスキーマへ変換できるようになりました。結論として、移行作業は「DDLを手作業で書き換える工程」から、「VS Code上で変換・検証・レビュータスク管理まで進める工程」へ寄せやすくなります。
ただし、この更新はAzure SQL Databaseそのものの機能追加ではなく、移行先としてAzure Database for PostgreSQL Flexible Serverを使うための更新です。Azure SQLを含むMicrosoftのデータベース基盤を管理しているチームにとっては、Oracle移行先の選定、PoC、アプリ改修計画に影響するため、機能の範囲と注意点を正しく押さえておく必要があります。
Visual Studio CodeでOracleスキーマをAzure PostgreSQL向けに変換可能に
今回の更新では、Visual Studio CodeのPostgreSQL拡張機能に、Oracle DatabaseのスキーマオブジェクトをAzure Database for PostgreSQL互換のスキーマへ変換する機能が一般提供されました。Microsoftの公式更新では、ステータスは「Launched」、つまり本番利用可能な一般提供として扱われています。(マイクロソフト Azure)
この機能は、OracleからPostgreSQLへの移行で発生するスキーマ変換を、VS Code内のプロジェクトベースのワークフローとして扱える点が特徴です。Microsoft Learnでは、OracleスキーマをPostgreSQL互換スキーマに変換し、Azure Database for PostgreSQL Flexible Server向けの成果物を生成する機能として説明されています。(Microsoft Learn)
従来の移行では、次のような作業が分断されがちでした。
| 移行工程 | 従来ありがちな進め方 | 今回の機能で変わる点 |
|---|---|---|
| Oracleスキーマの調査 | SQLや専用ツールで個別に抽出 | VS Code拡張機能から接続・検出 |
| DDL変換 | 手作業、スクリプト、外部ツールで変換 | AI支援を含む変換ワークフローを実行 |
| 互換性確認 | 変換後に別環境で検証 | Scratch schema上で構文や依存関係を検証 |
| 未変換項目の整理 | Excelやチケットで別管理 | Review tasksとしてVS Code内で確認 |
| 成果物管理 | 変換SQLやレポートが散在 | プロジェクト配下にSQL・レポートを出力 |
特に大きいのは、変換だけでなく「検証」と「レビュー対象の見える化」まで一連の作業に含まれる点です。OracleからPostgreSQLへの移行では、単純な型変換よりも、PL/SQL、トリガー、日付処理、NULLの扱い、パッケージ構造などの差分が問題になりやすいため、レビュータスクとして残る仕組みは実務上重要です。
対象はAzure SQLではなくAzure Database for PostgreSQL
今回の情報を読むうえで、最初に整理しておきたいのが対象サービスです。
この更新の対象は、Azure SQL DatabaseやAzure SQL Managed Instanceではなく、Azure Database for PostgreSQL Flexible Serverです。公式ドキュメントでも、変換後のスキーマはAzure Database for PostgreSQL Flexible Server向けに生成されると説明されています。(Microsoft Learn)
Azure SQLを運用している管理者にとっては、次のように位置付けると理解しやすくなります。
| 観点 | Azure SQL | Azure Database for PostgreSQL |
|---|---|---|
| 主な互換性 | SQL Server系 | PostgreSQL系 |
| 今回の更新の直接対象 | 対象外 | 対象 |
| Oracle移行時の役割 | 移行先候補の一つ | 今回のスキーマ変換機能の主な移行先 |
| 管理者が見るべき点 | 移行先選定、既存基盤との比較 | 変換・検証・権限・ネットワーク・運用設計 |
つまり、「Azure SQLの新機能」として捉えるより、Microsoft Azure上でOracle移行を進める際に、PostgreSQL系の移行ルートが強化されたと見るのが正確です。既存のAzure SQL基盤を持つ組織でも、Oracleワークロードの特性によってはPostgreSQLを選ぶケースがあるため、データベース標準化やクラウド移行を担当するチームは確認しておく価値があります。
何が変わったのか
今回の一般提供で、開発者や移行担当者はVisual Studio Code上からOracleスキーマ変換を進められるようになりました。PostgreSQL拡張機能に組み込まれているため、専用の別拡張機能を追加する必要はありません。インストール時はMarketplaceで「PostgreSQL」または拡張機能ID ms-ossdata.vscode-pgsql を検索し、発行元がMicrosoftであることを確認します。(Microsoft Learn)
主な変更点は次のとおりです。
| 変更点 | 内容 | 実務上の意味 |
|---|---|---|
| VS Code内でのスキーマ変換 | OracleスキーマをPostgreSQL互換DDLへ変換 | 開発者が普段使う環境でPoCしやすい |
| プロジェクトベースの管理 | 移行プロジェクトとして接続、変換、成果物を管理 | 作業履歴や成果物をチームで扱いやすい |
| Microsoft Foundry連携 | AIモデルを使ってOracle固有構文を変換 | 複雑なDDLやPL/SQL変換の初期作業を短縮できる |
| Scratch schemaでの検証 | Azure Database for PostgreSQL Flexible Server上で一時スキーマを作成して確認 | 本番環境に適用する前に構文・依存関係を確認できる |
| Review tasksの生成 | 自動変換しきれない項目をレビュー対象として提示 | 手戻りや見落としを減らしやすい |
| SQL成果物の生成 | 変換済みオブジェクトを.sqlファイルとして出力 | CI/CDやレビュー工程に載せやすい |
この機能は「ボタン一つでOracle移行が完了する」ものではありません。むしろ、移行作業のうち、スキーマ変換と初期検証を標準化し、レビューすべき箇所を明確にするための機能と考えるべきです。
変換ワークフローの流れ
公式チュートリアルでは、OracleソースとAzure Database for PostgreSQLターゲットへの接続、Microsoft Foundryの設定、Migration Wizardの実行、生成されたPostgreSQL成果物の確認までを扱っています。変換では、スキーマ検出、AI処理、Scratch databaseでの検証、Review tasksの生成、出力ファイルの生成が行われます。(Microsoft Learn)
実務では、次の順序で進めると失敗しにくくなります。
移行対象スキーマを決める
最初に、Oracle上のどのスキーマを移行対象にするかを明確にします。アプリケーション単位、業務機能単位、データベースユーザー単位など、チームが検証しやすい粒度で分けるのが現実的です。
いきなり全スキーマを対象にすると、レビュータスクが大量に発生し、優先順位が見えにくくなります。初回PoCでは、代表的なテーブル、ビュー、ストアドプロシージャ、トリガーを含む小さめの業務領域を選ぶのがおすすめです。
Oracleソースへ接続する
VS CodeのPostgreSQL拡張機能からOracleソースに接続し、スキーマオブジェクトを検出します。Oracle接続にはThin client modeとThick client modeがあり、Thin modeは追加のOracleクライアントライブラリなしで接続できます。一方、Oracle側のネットワーク暗号化設定などによっては、Oracle Instant Clientを使うThick modeが必要になります。(Microsoft Learn)
特に社内Oracle環境では、sqlnet.ora や tnsnames.ora を前提にした接続構成が残っていることがあります。PoC前にDBAへ接続方式を確認しておくと、VS Code側で接続できずに止まるリスクを減らせます。
Scratch databaseを準備する
変換機能は、Azure Database for PostgreSQL Flexible Server上に一時的なScratch schemaを作成し、変換済みオブジェクトの構文や依存関係を検証します。接続ユーザーにはScratch database上でスキーマを作成・削除するための権限が必要です。(Microsoft Learn)
本番DBをScratch databaseとして使うのは避けるべきです。検証用のFlexible Serverまたは専用データベースを用意し、変換作業で作成される一時オブジェクトが業務環境に影響しないようにします。
Microsoft Foundryを設定する
スキーマ変換ではMicrosoft Foundryのモデルデプロイを使います。公式FAQでは、OracleスキーマがMicrosoft FoundryモデルによってPostgreSQLオブジェクトへ変換され、Scratch schemaで検証され、結果がサマリーレポートにまとめられると説明されています。(Microsoft Learn)
AIを使うため、管理者は単に「機能が使えるか」だけでなく、どのAzureリージョンのモデルを使うのか、アクセス権は誰に付与するのか、ネットワーク経路はどう制限するのかも確認する必要があります。
変換結果とReview tasksを確認する
変換後は、生成されたSQLをそのまま本番へ適用するのではなく、Review tasksを確認します。公式ドキュメントでは、複雑なPL/SQL、Oracle固有のデータ型、Oracle固有ロジックを含むカスタム関数などがレビュー対象になりやすい例として挙げられています。(Microsoft Learn)
レビュー時は、次のような観点で確認します。
| 確認項目 | 見るべきポイント |
|---|---|
| テーブル定義 | 型、NULL制約、主キー、外部キー、デフォルト値 |
| インデックス | Oracle固有インデックスがPostgreSQLで再現可能か |
| シーケンス | 採番方式がアプリケーションの想定と一致するか |
| ビュー | 関数、日付演算、結合条件の挙動差分 |
| プロシージャ・関数 | PL/SQLからPL/pgSQLへの変換結果、例外処理、戻り値 |
| トリガー | 実行タイミング、参照可能な値、トランザクション挙動 |
| 文字列・NULL | Oracleの空文字とNULLの扱いの差 |
| 日付・時刻 | タイムゾーン、丸め、フォーマット依存処理 |
管理者が確認すべき設定
今回の更新は開発者向けツールに見えますが、実際には管理者側の準備が成否を左右します。特に権限、ネットワーク、コスト、セキュリティの4点は事前確認が必須です。
権限は最小権限で専用アカウントを使う
公式チュートリアルでは、Oracle側ではスキーマとコードを分析するためのデータディクショナリ参照権限、Azure Database for PostgreSQL側では検証用オブジェクトを作成する権限が必要とされています。可能であれば専用のサービスアカウントを使うことが推奨されています。(Microsoft Learn)
実務では、次のように分けると管理しやすくなります。
| 接続先 | 必要な権限の考え方 | 避けたい運用 |
|---|---|---|
| Oracleソース | メタデータ参照に必要な権限を付与 | 本番DBAアカウントで変換作業を行う |
| Scratch database | スキーマ作成、オブジェクト作成、接続権限 | 本番DBと同じ権限を広く付与する |
| Microsoft Foundry | モデル利用に必要なロールを付与 | 個人アカウントに過剰な権限を与える |
| VS Code利用端末 | 必要な接続先へ到達可能にする | 個人PCから無制限にDB接続させる |
Azure Database for PostgreSQL側では、Scratch schemaを作成・削除できる権限が必要です。公式ドキュメントでは、Scratch schemaの名前には _mig_scratch_ プレフィックスが使われると説明されています。(Microsoft Learn)
ネットワーク到達性を事前に確認する
VS Codeを実行する端末は、Oracleソース、Azure Database for PostgreSQL Flexible Server、Microsoft Foundryエンドポイントへ接続できる必要があります。公式のベストプラクティスでも、VS Code端末からこれら3つの接続先へ到達できることを確認するよう案内されています。(Microsoft Learn)
企業環境では、次のどこかで止まりやすいです。
| 詰まりやすい箇所 | 典型的な原因 | 対応例 |
|---|---|---|
| Oracleへ接続できない | VPN、ファイアウォール、TNS設定、暗号化設定 | DBAと接続方式を確認し、必要ならOracle Instant Clientを準備 |
| PostgreSQLへ接続できない | Azure側のファイアウォール、Private Endpoint、NSG | 作業端末または踏み台からの経路を許可 |
| Foundryへ接続できない | プロキシ、許可リスト、認証設定 | エンドポイントURL、Entra ID権限、プロキシ設定を確認 |
| VS Code拡張機能が入らない | Marketplaceアクセス制限 | 拡張機能の配布方法を社内手順に合わせる |
本番移行を見据えるなら、個人PCから直接接続するより、Azure Bastion、Dev Box、管理用VDI、閉域接続済みの開発端末など、監査しやすい作業環境に寄せるほうが安全です。
Microsoft Foundry利用時のデータ取り扱いを確認する
この機能はAIモデルを使うため、データの扱いを必ず確認してください。公式FAQでは、AIに送信されるのはスキーマメタデータであり、DDL、テーブル名、列名、関数本体、ビュー定義、トリガーコードなどが含まれる一方、行レベルのデータは送信されず、Oracleカタログのみを読み取ると説明されています。(Microsoft Learn)
この点は、セキュリティレビューで必ず確認されるポイントです。行データが送られないとしても、テーブル名や列名、ストアドプロシージャ内の業務ロジックに機密性がある場合があります。
管理者は、少なくとも次の内容を整理しておくべきです。
| 確認項目 | 判断基準 |
|---|---|
| スキーマメタデータの機密性 | テーブル名、列名、PL/SQL内に機密情報や顧客名が含まれないか |
| 利用リージョン | 自社のデータ所在地ポリシーとFoundryモデルのリージョンが合うか |
| 認証方式 | APIキーではなくEntra ID認証を使えるか |
| ネットワーク | Private Endpointやファイアウォールで接続元を制限できるか |
| 監査 | 誰が変換を実行したか、成果物をどこに保存したか追跡できるか |
追加コストを見落とさない
公式FAQでは、VS Code PostgreSQL拡張機能のスキーマ変換機能自体は無料ですが、使用するAzureリソースには課金が発生すると説明されています。具体的には、Microsoft Foundryで消費するAIトークン、Azure Database for PostgreSQL Flexible ServerのターゲットサーバーやScratch validation serverが課金対象です。(Microsoft Learn)
PoCだからといって、コスト見積もりなしに大規模スキーマを変換すると、AI利用量や検証用サーバーの稼働コストが見えにくくなります。最初は小さなスキーマで実行し、1スキーマあたりの変換時間、Review tasks数、概算コストを記録してから範囲を広げるのが安全です。
開発者が確認すべき移行上の注意点
開発者にとって重要なのは、「変換されたSQLが動くか」だけでなく、「アプリケーションの期待する挙動と一致するか」です。OracleとPostgreSQLでは、同じSQLに見えても挙動が異なる部分があります。
自動変換できない前提でレビュー計画を立てる
Microsoftのドキュメントでも、AIやツールが見落とす可能性があるため、すべての変換済みオブジェクトとレビュータスクの解決結果を本番展開前に独立して検証する責任があると明記されています。(Microsoft Learn)
特に次のようなオブジェクトは、変換後に必ず人が読むべきです。
| オブジェクト | 注意点 |
|---|---|
| PL/SQLパッケージ | PostgreSQLにはOracleのpackage構造がそのまま存在しないため、分割・再設計が必要になる場合がある |
| ストアドプロシージャ | 例外処理、トランザクション制御、戻り値の扱いを確認する |
| トリガー | BEFORE/AFTER、行単位/文単位、参照値の差分を確認する |
| 日付処理 | SYSDATE、タイムゾーン、日付文字列の暗黙変換に注意する |
| 空文字処理 | Oracleでは空文字がNULLとして扱われる文脈があり、PostgreSQLとの差分が出やすい |
| 動的SQL | 文字列連結、識別子のクォート、権限実行の差分を確認する |
出力ファイルの確認順序を決める
変換後は、レポートとSQL成果物が生成されます。公式ドキュメントでは、最初に reports/customer_summary.md を開き、全体の準備状況や関連レポート、生成SQL、レビュータスクへの案内を確認する流れが示されています。(Microsoft Learn)
確認順序は次のようにすると効率的です。
| 順序 | 確認対象 | 目的 |
|---|---|---|
| 1 | reports/customer_summary.md | 全体の変換結果と準備状況を把握する |
| 2 | Schema Review pane | 人の判断が必要な項目を優先度順に確認する |
| 3 | review_tasks.md | レビュー対象をチーム共有・監査用に確認する |
| 4 | postgres_ddl/<schema>/<object_type>/ | Oracleオブジェクトごとの変換SQLを確認する |
| 5 | deploy.sql | 実際に適用するSQLの実行順序を確認する |
| 6 | ログ・内部レポート | 失敗原因や変換根拠を調査する |
変換結果だけを見ると、見た目上はSQLが生成されているため「完了した」と判断しがちです。しかし、実務ではReview tasksとレポートの確認が本体です。特に、数値精度、日付処理、例外処理、照合順序、NULLの扱いは、テストデータを使って実行結果を比較してください。
本番適用前に代表データで差分テストを行う
Scratch schemaで構文が通っても、業務ロジックが正しいとは限りません。変換後のプロシージャやビューは、Oracle側の実行結果とPostgreSQL側の実行結果を比較する必要があります。
最低限、次のテストケースを用意します。
| テスト種別 | 例 |
|---|---|
| 正常系 | 通常の顧客、注文、請求データで同じ結果になるか |
| 境界値 | 最大桁数、最小日付、月末、うるう年、NULLを含むデータ |
| 異常系 | 存在しないID、重複キー、制約違反、権限不足 |
| バッチ系 | 大量件数、長時間処理、途中失敗時のロールバック |
| 性能 | 主要SQLの実行計画、インデックス利用、ロック待ち |
「SQLが作成された」ことを完了条件にせず、「代表業務シナリオでOracleと同等の結果を返す」ことを完了条件にしましょう。
サポートされない・注意が必要なOracleオブジェクト
OracleからPostgreSQLへの移行で失敗しやすいのは、Oracle固有機能を多用している部分です。公式の制限事項では、抽出されないOracleオブジェクトのカテゴリが示されており、対象外のものは手動で再作成するか、別のAzureサービスやアプリケーション層へ再配置する必要があります。(Microsoft Learn)
代表的な注意点は次のとおりです。
| 分類 | 対象例 | 対応の考え方 |
|---|---|---|
| システム・組み込みスキーマ | SYS、SYSTEM、XDBなど | 移行対象から除外する |
| 特殊な表・索引 | 外部表、ブロックチェーン表、Bitmap indexなど | PostgreSQLの標準機能や別方式で再設計 |
| Materialized View関連 | Materialized view logs、refresh groupsなど | 更新方式や集計基盤を再設計 |
| システムイベントトリガー | LOGON、LOGOFF、STARTUPなど | DB内処理ではなく監査・運用機能で代替 |
| Java in Database | Java stored procedures、外部ライブラリ | アプリケーション層や別サービスへ移行 |
| Wrapped PL/SQL | 難読化されたパッケージ、関数、プロシージャ | 元の非難読化ソースを用意 |
| Advanced Queuing | Oracle AQ | Azure Service Busなどメッセージング基盤を検討 |
| Database Link | CREATE DATABASE LINK | FDWやアプリケーション側接続へ再設計 |
| 監査・管理系 | FGA、Resource Manager、Directory objectなど | AzureやPostgreSQLの運用機能に置き換え |
特にWrapped PL/SQLは、ツールが中身を読めないため変換できません。ベンダー提供パッケージや古い業務アプリでWrapped PL/SQLを使っている場合、移行前にソースコードの入手可否を確認してください。ここを後回しにすると、移行プロジェクトの終盤で「変換できない業務ロジック」が発覚します。
どのような組織に影響があるか
今回の更新は、OracleからAzureへの移行を検討している組織に特に影響します。中でも、次のようなケースでは早めに検証する価値があります。
Oracleライセンスや基盤更改をきっかけに移行を検討している
Oracle Databaseのライセンス更新、オンプレミス基盤の更改、データセンター縮退をきっかけに、Azure移行を検討している企業では、Azure SQLだけでなくAzure Database for PostgreSQLも移行先候補になります。
今回の機能により、PostgreSQLへ移行した場合のスキーマ変換難易度を、比較的早い段階で見積もりやすくなります。PoCでReview tasksの量を確認すれば、手作業の改修規模を把握しやすくなります。
開発チーム主導で移行PoCを進めたい
VS Code内で作業できるため、DBAだけでなくアプリケーション開発者も移行検証に参加しやすくなります。生成されたSQLやレビュータスクをGit管理し、Pull Requestでレビューする運用にもつなげやすいでしょう。
ただし、開発者だけで完結させるのは危険です。権限、ネットワーク、監査、機密情報の扱いは管理者と一緒に設計する必要があります。
AI支援ツールの利用ルールを整備している
この機能はMicrosoft FoundryのAIモデルを使うため、AI利用ポリシーの対象になります。行データは送信されないとしても、スキーマ定義や業務ロジックがAI処理の入力になる点は社内審査の対象になる可能性があります。
セキュリティ部門やコンプライアンス部門には、「何が送信されるのか」「どのAzure環境で処理されるのか」「誰が実行できるのか」を説明できる状態にしておく必要があります。
導入前チェックリスト
PoCを始める前に、次の項目を確認しておくと手戻りを減らせます。
| チェック項目 | 確認内容 |
|---|---|
| 対象スキーマ | 初回PoCの範囲を小さく定義したか |
| Oracle接続 | 接続方式、権限、TNS設定、暗号化設定を確認したか |
| VS Code環境 | Visual Studio CodeとMicrosoft発行のPostgreSQL拡張機能を利用できるか |
| PostgreSQL環境 | Azure Database for PostgreSQL Flexible ServerをScratch database用に準備したか |
| PostgreSQLバージョン | Scratch databaseと本番想定のメジャーバージョンを合わせたか |
| 権限 | Oracle、PostgreSQL、Foundryで専用アカウントや最小権限を設計したか |
| ネットワーク | VS Code端末からOracle、PostgreSQL、Foundryへ到達できるか |
| セキュリティ | スキーマメタデータのAI利用について社内承認を得たか |
| コスト | Foundryトークンと検証用PostgreSQLサーバーの費用を見積もったか |
| 検証データ | 代表的な業務テストケースを準備したか |
| 成果物管理 | 生成SQL、レポート、ログの保存場所と共有方法を決めたか |
失敗しやすいポイント
今回の機能を使う場合でも、Oracle移行そのものの難易度がなくなるわけではありません。特に次の失敗パターンには注意してください。
PoC対象が大きすぎる
最初から全スキーマを変換すると、Review tasksが多すぎて評価できません。まずは業務上重要で、かつOracle固有機能をある程度含む代表スキーマを選びます。単純すぎるスキーマだけでPoCすると、本番移行時の難所を見落とします。
Scratch databaseを本番環境と違うバージョンで作る
公式ベストプラクティスでは、Scratch databaseと本番ターゲットのPostgreSQLメジャーバージョンを合わせることが推奨されています。バージョンが違うと、変換時に通ったDDLが本番想定環境で失敗する可能性があります。(Microsoft Learn)
変換結果をレビューせずに適用する
AIによる変換は初期作業を短縮しますが、業務ロジックの正しさを保証するものではありません。特に、会計、請求、在庫、権限判定、締め処理など、間違いが業務影響に直結する処理は、Oracle側との結果比較が必須です。
アプリケーション改修を後回しにする
スキーマ変換が成功しても、アプリケーション側のSQL、接続ライブラリ、トランザクション制御、バッチ処理がOracle前提のままでは移行できません。スキーマ変換のPoCと並行して、アプリケーションコード内のOracle依存箇所も棚卸ししましょう。
Oracle固有機能の代替設計を決めていない
Database Link、Advanced Queuing、DBMS_SCHEDULER、Materialized View関連、Wrapped PL/SQLなどは、変換ツールだけで解決しにくい領域です。これらは「変換」ではなく「再設計」の対象として、早い段階でアーキテクトやアプリ担当者を巻き込むべきです。
移行プロジェクトでの現実的な使い方
この機能は、本番移行の直前に一度だけ実行するより、移行計画の早い段階から繰り返し使うほうが効果的です。
おすすめの進め方は次のとおりです。
| フェーズ | 使い方 | 成果物 |
|---|---|---|
| 初期調査 | 代表スキーマを小さく変換 | 変換率、Review tasks数、難所の一覧 |
| 移行計画 | 対象スキーマ全体を段階的に変換 | 工数見積もり、再設計対象の洗い出し |
| 開発・改修 | 生成SQLをレビューし、アプリ改修と並行検証 | 修正版DDL、テスト結果、変更履歴 |
| 結合テスト | 代表データでOracleとPostgreSQLを比較 | 差分一覧、性能課題、修正チケット |
| 本番準備 | 適用順序、権限、ロールバックを確認 | deploy.sql、運用手順、監査記録 |
ポイントは、変換結果を「完成品」として扱わず、移行プロジェクトの判断材料として使うことです。Review tasksの量、未対応オブジェクトの種類、手作業が必要な箇所を早期に見れば、移行先をPostgreSQLにするか、Azure SQLを含む別の選択肢を検討するかも判断しやすくなります。
Azure SQL担当者が今確認すべきこと
Azure SQLを主に管理しているチームでも、今回の更新は無関係ではありません。Microsoft Azure上のデータベース移行を横断的に管理している場合、Oracleワークロードの移行先としてAzure SQL系とPostgreSQL系を比較する場面があるためです。
今確認すべきことは次の3つです。
まず、社内のOracleワークロードにPostgreSQL移行候補があるかを確認します。Oracle固有機能が少なく、オープンソースDBへの移行方針があるシステムは候補になりやすいです。
次に、Azure Database for PostgreSQL Flexible Serverの標準構成を決めます。ネットワーク、認証、バックアップ、監視、Private Endpoint、運用ロールを先に整えておくと、PoCから本番移行への接続がスムーズになります。
最後に、AI支援による変換の利用ルールを整えます。誰が実行できるのか、どのスキーマを対象にできるのか、生成物をどこに保存するのか、レビュー完了の基準は何かを明文化しておくと、ツール利用が属人化しません。
まとめ：まずは小さなスキーマで変換結果とレビュー量を確認する
今回の一般提供により、Visual Studio CodeのPostgreSQL拡張機能からOracleスキーマをAzure Database for PostgreSQL互換スキーマへ変換し、Scratch schemaで検証し、Review tasksとして人の確認が必要な箇所を整理できるようになりました。
実務で重要なのは、機能を「自動移行ツール」として過信しないことです。OracleとPostgreSQLの差分は、構文だけでなく業務ロジック、データ型、日付処理、NULLの扱い、例外処理、運用機能に及びます。変換結果は必ずレビューし、代表データでOracle側との結果比較を行ってください。
次に取るべき行動は明確です。まず、移行候補のOracleスキーマを1つ選び、VS Code PostgreSQL拡張機能、Azure Database for PostgreSQL Flexible ServerのScratch database、Microsoft Foundryの利用環境を準備します。そのうえで小さく変換を実行し、Review tasksの量、未対応オブジェクト、追加コスト、アプリ改修範囲を確認しましょう。ここまで見えれば、OracleからAzure PostgreSQLへの移行が現実的かどうかを、感覚ではなく成果物ベースで判断できます。
コメント