Amazon Web Services ブログ
AWS Transform を使用した SQL Server データベースから Aurora PostgreSQL へのモダナイズ
このブログは、2026 年 8 月 3 日に公開された「 Modernize SQL Server databases to Aurora PostgreSQL using AWS Transform 」を翻訳したものです。
はじめに
SQL Server データベースの Aurora PostgreSQL へのモダナイゼーションは、始める前から停滞することがよくあります。インフラストラクチャーのセットアップ、ネットワーク構成、資格情報の共有、セキュリティレビューといった準備作業に何週間もかかり、移行の中身を評価する段階にすらたどり着けないのです。AWS Transform フルスタック Windows モダナイゼーション の Offline Source を使用すると、こうした障壁を飛び越えて、SQL Server データベースのスキーマファイルをアップロードするだけで Microsoft SQL Server データベースの Amazon Aurora PostgreSQL-Compatible Edition (Aurora PostgreSQL) へのモダナイゼーションを開始できます。
SQL Server 環境を管理していて、始めるまでの複雑さからモダナイゼーションを先送りにしてきた方に、ぜひ読んでいただきたい記事です。Offline Source がインフラストラクチャーの事前準備をどのように不要にするか、.NET アプリケーションコードのアセスメントを含む変換ワークフローがエンドツーエンドでどのように動くか、そして SQL Server スキーマの DDL エクスポートから、変換済みアプリケーションコードを伴う検証済み Aurora PostgreSQL スキーマに至るまでの流れを解説します。
課題: アセスメント前のインフラストラクチャー要件
SQL Server データベースのモダナイゼーションアセスメントには従来、以下が必要でした :
- ソースデータベースと変換ツール間のネットワーク接続
- ソースサーバーへの資格情報の共有またはエージェントのインストール
- スキーマ分析のための中間環境のプロビジョニング
厳格なセキュリティポリシー、規制環境、または企業ファイアウォールの背後にあるデータベースを持つ組織にとって、アセスメント作業を始める前の段階でこれらの前提条件だけでモダナイゼーションプロジェクトが数週間から数か月遅れることもありました。
ソリューション概要
AWS Transform の Offline Source を使用すると、標準的な Data Definition Language (DDL) エクスポートファイルからソースデータベースの構造を再現できます。稼働中の SQL Server インスタンスに接続する必要はなく、 DDL をアップロードするだけで AWS Transform がアセスメントから変換、検証、Aurora PostgreSQL へのデプロイまでを実行します。インフラストラクチャーの事前準備は一切不要です。
図 1: AWS Transform Offline Source ワークフロー
ワークフローは 5 つのステージで構成されます :
- データベースアセスメント : データベースオブジェクトの複雑さ、依存関係、作業量レベルを分析
- スキーマ変換 : SQL Server オブジェクトの PostgreSQL への LLM ベースの変換
- 検証 : 3 層の検証 (構造的、意味的、機能的)
- デプロイ : 検証済みスキーマを Aurora PostgreSQL クラスターに適用
- アプリケーションのアセスメントと変換 : .NET ソースコードを接続し、スキーマと並行してデータベース依存のアプリケーションコードをアセスメントおよび変換
前提条件
開始する前に、以下を確認してください :
- AWS Transform console へのアクセスを持つ AWS アカウント
- DDL を抽出するための SQL Server に接続する資格情報
- Aurora PostgreSQL クラスターを作成する権限を持つ AWS アカウント (AWS Transform はデプロイステップの一部としてターゲットクラスターをプロビジョニングします)
- オプション : .NET アプリケーションアセスメント用の、AWS CodeConnections 経由でアクセス可能な、または Amazon S3 や Personal Access Token (PAT) 経由でアップロードされたソースコードリポジトリ (GitHub、GitLab、または Bitbucket)
- AWS Transform for SQL Server は US East (N. Virginia) us-east-1 でのみ利用可能です。他のリージョンのデータベースの場合、変換のために us-east-1 にクローンしてください。
- AWS アカウントで IAM Identity Center が有効化されていること
- Microsoft SQL Server バージョン 2008 R2 から 2022 (すべてのエディションがサポートされています)。SQL Server は AWS 上または AWS 外でホストできます。
- オプション (.NET アセスメント用): .NET Core 6、7、8、または 10 アプリケーション。レガシーな .NET Framework 4.x 以前はサポートされていません。
ウォークスルー
以下のセクションでは、Offline Source ワークフローの各ステージを説明します。
ステップ 1: SQL Server DDL を抽出してアップロード
AWS Transform は DDL を抽出するための 2 つの方法を提供します :
- オプション 1 (推奨): 変換ジョブを作成すると、AWS Transform は SQL Server に対して実行する抽出スクリプト (
ExtractDatabaseMetadata.ps1) を提供します。このスクリプトはデータベースごとに SQL Server オブジェクトタイプ (テーブル、ストアドプロシージャ、関数、トリガーなど) の DDL 定義を抽出し、複数の機能領域 (SSIS、SSRS、Service Broker、Agent Jobs など) を検出するため、アセスメントに最も完全な情報を提供します。 - オプション 2 (手動): SSMS または sqlpackage を使用して SQL DDL ファイル (
CREATE TABLE、CREATE PROCEDUREなどのステートメント) を手動でエクスポートし、zip にしてアップロードします。各 SQL ファイルには 1 つのデータベースのステートメントのみを含める必要があります。
結果の DDL ファイル (または zip) を AWS Transform にアップロードして Offline Source を作成します。
ステップ 2: アセスメントの確認
AWS Transform はすべてのデータベースオブジェクトの複雑さと依存関係を分析します。アセスメントレポートには以下が含まれます :
- オブジェクト間の関連性を可視化する依存関係マップ
- 各オブジェクトの複雑さスコア (Simple、Moderate、Complex)
- 手動変換と自動変換の作業量 (LOE) の見積もり
- エージェントによる自動化で削減できる工数と、人的レビューが必要な部分の内訳
アセスメントでは、PostgreSQL のイベントトリガーへの置き換えが必要な DDL トリガーや、例外ブロック内でのみ有効な構文を使用している関数など、手動レビューが必要になる可能性のある項目も識別されます。これらの情報をもとに、変換開始前にチームの作業計画を立てることができます。
ステップ 3: 変換をカスタマイズ
アセスメントを確認した後、AWS Transform は変換の実行方法を定義する変換プランを生成します。プランは実行戦略、フェーズの順序付け、変換ルール、インフラストラクチャー構成を単一のレビュー可能なアーティファクトに統合します。デフォルトを受け入れて進めることも、変換開始前に任意の側面をカスタマイズすることもできます。
変換プランは 4 つの領域をカバーします :
- 実行ウェーブ – データベースはウェーブ順に変換され、各ウェーブ内で最大 5 つのデータベースが並行して実行されます。次のウェーブは現在のウェーブのすべてのデータベースが完了した後にのみ開始されます。ウェーブ間でデータベースの順序を変更したり、完全に除外したりできます。
- ジョブプラン – 変換ジョブのフェーズの順序 (スキーマ変換、ターゲットプロビジョニング、スキーマデプロイ、コード変換、およびオプションの合成テストデータ生成)。必要に応じてオプションフェーズをスキップできます。
- 変換およびカスタムルール – 型マッピング (例: SQL Server の
MONEYから PostgreSQL のDECIMAL(19,4))、スキーマ名マッピング (例: 単一データベース移行でのdboからpublic)、関数マッピング (例:GETDATEからCURRENT_TIMESTAMP)、IDENTITY 列戦略 (GENERATED BY DEFAULTまたはGENERATED ALWAYS)、およびプロシージャ結果のハンドリング (refcursor または関数リターンスタイル)。適切なデフォルトが自動的に適用されるため、ユースケースに合わないものだけを変更するだけで済みます。 - ターゲットプロビジョニング構成 – 新しい Aurora PostgreSQL クラスターを作成するか既存のものに接続するか、およびインスタンスクラス、ネットワーク設定、資格情報管理。
これらの設定は、コンソールでプランを直接編集するか、自然言語でプリファレンスを記述するか、JSON 構成ファイルを提供することでカスタマイズできます。例えば、「MONEY を DECIMAL(19,4) にマッピングし、dbo に public を使用し、GENERATED ALWAYS で IDENTITY 列を生成する」とリクエストすると、AWS Transform が該当するルールを適用します。
ステップ 4: LLM ベースのスキーマ変換の実行
AWS Transform では、大規模言語モデル (LLM) を使用して SQL Server スキーマオブジェクトを PostgreSQL に変換します。変換はコンテキストを考慮し、構文だけでなくビジネスロジックの意図を保持します。
変換はステージごとに進行します:
- 基盤オブジェクト (スキーマ、シーケンス、シノニム、ユーザー定義型)
- テーブルと主キー
- 制約とインデックス
- プログラマブルオブジェクト (ストアドプロシージャ、関数、ビュー、トリガー)
LLM ベースのアプローチは、ルールベースのツールでは通常手動変換が必要な複雑な T-SQL パターンやプロプライエタリな SQL Server 構文を処理します。これにより、自動変換率が向上し、手動介入が減少します。
ステップ 5: 変換済みオブジェクトの検証
変換されたオブジェクトは、以下の 3 層の自動検証を通過します :
- 構造的検証 は、変換された PostgreSQL スキーマが構文的に正しくデプロイ可能であることを確認します。
- 意味的検証 は、変換されたオブジェクトがソースの論理的な意味と動作を保持していることを検証します。
- 機能的検証 は、ソースとターゲット間のクエリ動作を比較し、本番環境に影響する前に差異を検出します。
各検証パスでは分離されたサンドボックスが起動し、ソースとターゲット両方のスキーマをロードした上で、型マッピング、制約、ルーチンを検査する AI エキスパートレビュワーが実行されます。AWS Transform はストレージオブジェクトの変換後とコードオブジェクトの変換後にそれぞれ検証レポートを生成します。各レポートでは、カテゴリごと (テーブル、列、制約、インデックス、ビュー、プロシージャ、関数) に Pass、Warning、Fail の結果が示されます。
検証完了後、エキスパートアセスメントが全体の変換を評価します :
- Ready: オブジェクトが完全に変換および検証済み
- Conditional: オブジェクトが変換済みで、レビュー用にマイナーな問題がフラグ付けされている
- Not Ready: 手動介入が必要なオブジェクト
ステップ 6: 残りの問題への対応
Conditional または Not Ready と評価されたオブジェクトについて、AWS Transform は具体的な次のステップを含む Schema Conversion Report を提供します。2 つのオプションがあります :
- 組み込みの AWS Transform Web コンソールを使用して、ローカル IDE のインストールなしにブラウザで直接変換の問題を確認して修正する。
- または、Kiro や他のローカル AI コーディングアシスタントと AWS Transform MCP Server を使用して、好みの IDE にアーティファクトを取得する。
修正を加えた後に検証を再実行し、スキーマ全体が検証に合格するまで繰り返しデプロイできます。
Web コンソールでは、変換レポートの確認、SQL の編集、検証の再実行、変更のデプロイまでをブラウザ上で一貫して行えます。ローカル開発を好むチームには、MCP Server を使って IDE から AWS Transform ワークスペースに接続して普段の開発ワークフローのまま、同じアーティファクトとデプロイ機能を利用できます。
ステップ 7: Aurora PostgreSQL にデプロイ
検証が完了したら、AWS Transform に AWS アカウントへのアクセスを付与するデータベースコネクタを設定します。AWS Transform はターゲットの Aurora PostgreSQL クラスターをプロビジョニングし、変換済みスキーマをデプロイします :
- 既存のクラスターを選択するか、AWS Transform に新しいクラスターを作成させます。
- AWS Transform が変換済みオブジェクトをターゲットに適用します。
- データベース資格情報が生成され、AWS Secrets Manager に保存されます。
- 問題がないかデプロイレポートを確認します。
デプロイ後、継続的な運用に不要な場合は、オプションで RDS Data API を無効にできます。
ステップ 8: .NET アプリケーションコードのアセスメントおよび変換
スキーマのデプロイが完了すると、コード変換が実行可能になります。アプリケーションのアセスメントと変換を行うために、.NET Core (6、7、8、または 10) のソースコードリポジトリを接続します。アプリケーションのデータベースアクセスには ADO.NET または Entity Framework (6.3-6.5、または EF Core 1.0-8.0) を使用している必要があります。なお、アセスメントはスキーマデプロイ前でも開始できますが、コード変換にはスキーマが先にデプロイされている必要があります。
ソースコードへの接続には、以下を使用できます :
- AWS CodeConnections (GitHub、GitLab、または Bitbucket リポジトリ用)
- ソースコードの直接アップロード用の Amazon S3
- AWS Secrets Manager に保存する Personal Access Token (PAT)
接続すると、AWS Transform は :
- コネクタを通じて利用可能なリポジトリを検出します。
- ソースコードをダウンロードして分析し、データベース参照、Entity Framework モデル、接続文字列、SQL クエリパターンを識別します。
- モダナイゼーションの複雑さ (Low、Medium、High) と具体的な変換レコメンデーションを含むアプリケーションアセスメントレポートを生成します。
アセスメント完了後、コード変換を開始して .NET アプリケーションコードを Aurora PostgreSQL をターゲットとするように更新できます。コード変換はスキーマ変換の結果を使用して、アプリケーション内の接続文字列、ORM マッピング、インライン SQL クエリを更新します。
ステップ 9: テストデータで検証する (オプション)
AWS Transform は本番データを公開することなく、ターゲットクラスターに検証用のテストデータを生成できます。テストデータ生成レポートには何が作成されたかが記載され、代表的なデータボリュームに対してストアドプロシージャ、ビュー、アプリケーションクエリの徹底的なテストが可能になります。
クリーンアップ
このウォークスルー中にテスト目的で新しい Aurora PostgreSQL クラスターを作成した場合 :
- Amazon RDS console に移動します。
- 作成したクラスターを選択します。
- Actions > Delete を選択します。
- 削除を確認します。
AWS Transform ワークスペースは追加料金なしでそのまま残しておけるため、後から参照することができます。
まとめ
AWS Transform for SQL Server の Offline Source を使うことで、SQL Server モダナイゼーションにおける 2 つの大きな障害、すなわち「始めるまでのハードル」と「スキーマ変換の精度・検証」を解消できます。稼働中のデータベースへの接続設定は不要で、DDL ファイルをアップロードするだけで始められます。インフラストラクチャーのプロビジョニングなしに、スキーマのアセスメントから変換、検証、Aurora PostgreSQL へのデプロイまでを実行できます。さらに .NET ソースコードリポジトリを接続すれば、データベースと合わせてアプリケーションコードの変換も可能です。これらすべてが単一の統合ワークフローで完結します。
Offline Source を開始するには、AWS Transform console を開いて最初の変換ワークスペースを作成してください。詳細については、AWS Transform ドキュメントを参照してください。モダナイゼーションターゲットとしての Aurora PostgreSQL の詳細については、Amazon Aurora PostgreSQL-Compatible Edition を参照してください。
翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文はこちらです。