概要
これまでの「オンプレ編」では、Azure の仮想マシン（IaaS）を使って、社員番号から名前を検索できるシンプルな社内システムを構築してきました。Active Directory、SQL Server、ADFS などを組み合わせ、オンプレミスの構成を仮想的に再現しています。
※全体構成の詳細は、【第0回】Azureで社内システム再現（オンプレ編）｜構成図と動作の流れ をご参照ください。
クラウド編では、これまでの構成をベースにしつつ、Azure のマネージドサービス（PaaS）を中心とした構成へ段階的に移行していきます。
※クラウド移行全体の設計方針については、【第10.5回】Azureで社内システム再現（クラウド編）｜オンプレ構成をどうクラウドに移行するか？ にまとめています。
システム構成（今回の対象範囲）
今回は、オンプレミス環境の SQL Serverにあるデータベースを、DMA（Data Migration Assistant）を使って Azure SQL Databaseへ移行する構成です。
図の太い矢印のとおり、DB-VM1 から Azure SQL DB への移行が今回の中心となります。
リージョンは、無料クレジットで多くのサービスを利用可能だったため、Azure 側を Southeast Asia（シンガポール）に構築しています。
具体的には、以下の作業を行います：
- Azure SQL Database の作成
- DMA を使ってオンプレ SQL Server から Azure SQL へスキーマ＆データを移行
- 移行対象は、EmployeeDB に含まれる
employee_dataテーブル
Azure SQL Database の作成
まずは、Azure 側に移行先となる SQL Database を用意します。
ここでは新しく サーバー（sqlsrv-employee） を作成し、その上にデータベースを作成します。
- サーバー名：
sqlsrv-employee - 場所：
(Asia Pacific) Southeast Asia
Japan East（東京）や West Japan（大阪）などの人気リージョンでは、無料クレジットプランでは Azure Automation など一部のサービスが作成できませんでした。
一方、Southeast Asia（シンガポール）では比較的制限が少なく、Automation や他の PaaS サービスも問題なく使えたため、このリージョンを選択しています。
次に、認証情報の設定を行います。
ここでは以下のように設定しました：
- 認証方法：SQL + Microsoft Entra 認証の両方を使用する
- サーバー管理者ログイン：
sqladmin - パスワード：任意のパスワードを入力
ADF → SQL の処理を行う際は、Entra ID 認証を利用して SQL Database にアクセスします。
このとき、SQL 側に Entra ID 認証のユーザー（例：ADF のマネージド ID）を作成しておく必要がありますが、
このユーザー作成は SQL 認証（例：sqladmin）では実行できないため、
Entra ID で SQL にログインできるよう、認証方式は「SQL + Entra 認証の両方」を有効にしておきます。
ファイアウォール設定（DMA移行のための一時的な接続許可）
オンプレ環境にある DMA（Data Migration Assistant）から Azure SQL Database にパブリックIP経由で接続してデータを移行するため、
一時的に接続元 VM にパブリック IP を割り当て、その IP アドレスをファイアウォールで許可しています。
今回は East US 2 → Southeast Asia というリージョンを跨いだ構成のため、
パブリックアクセス経由での移行になります。
同一リージョン内であれば、Private Endpointを活用することで、よりセキュアに移行を行うことも可能です。
移行元 VM（DB-VM1）にパブリック IP を割り当てる
VM のパブリック IP アドレスを確認しておきます。
この IP が、あとで SQL Server 側で許可する対象になります。
SQL Server 側で「選択されたネットワークのみ許可」を設定
SQL Server のネットワーク設定を開き、パブリックアクセスは
「選択されたネットワーク」 のみに限定しています。
DB-VM1のIPアドレスを一時的にファイアウォールルールとして登録
「開始IP」と「終了IP」に VM のパブリックIP（例：172.210.215.177）を指定して、
一時的なルール rule_dma を作成します。
このファイアウォール設定により、DMA から Azure SQL Database への接続が可能になります。
移行完了後は、不要になったルールを削除します。
Data Migration Assistant（DMA）によるデータ移行
続いて、オンプレ側（DB-VM1）から Azure SQL Database にデータを移行します。
Data Migration Assistant（DMA）のインストール
移行には、Microsoft が提供している公式ツール
「Data Migration Assistant（DMA）」を使用します。
オンプレ環境（今回は DB-VM1）上で DMA をインストールし、起動しておきます。
事前確認（nslookup）
nslookup コマンドで移行先の Azure SQL Server（例：sqlsrv-employee.database.windows.net）の名前解決ができるかを確認しています。
新しいプロジェクトを作成
- プロジェクトタイプ：Migrate
-
- プロジェクト名：db-mig-pj
- ソースサーバータイプ：**SQL Server **
- ターゲットサーバータイプ：Azure SQL Database
※ 今回は非常に単純な構成かつ検証用のため、Assessment（評価）はスキップしています。
移行元（オンプレの SQL Server）を選択
以下の内容でオンプレ側の SQL Server（移行元）に接続します：
-
Source server name：
db-vm1 -
Authentication type：
Windows Authentication(ドメイン環境のため）
移行先（Azure SQL Database）を選択
- サーバー名：
sqlsrv-employee.database.windows.net -
- 接続方式：SQL 認証
- ユーザー名：
sqladmin
移行対象データの確認
移行対象のテーブル（employee_data）が選択されていることを確認します。
移行の実行と完了
移行を実行すると、数秒〜数十秒で完了しました。
DMA は GUIベースで操作でき、SQL Server → Azure SQL の移行をシンプルに行えるツールとしてとても便利でした。
移行結果の確認
移行が完了した後、Azure Portal の「クエリ エディター（プレビュー）」を使用して、Azure SQL Database にデータが正しく移行されているかを確認します。
クエリ エディターで接続
接続元の IP アドレスがファイアウォールで許可されていない場合、
「この IP をファイアウォールで許可する」というボタンが表示されます。
クリックすることで、該当の IP が一時的に許可され、接続が可能になります。
データの確認
employee_data テーブルに、オンプレミスから移行したデータが格納されていることを確認します。
内容に問題がなければ、移行は完了です。
ファイアウォールルールの削除
以下の一時的なファイアウォールルールは、不要になった段階で削除しておきます。
- クエリ エディター利用時に追加された、クライアント PC の IP アドレスの許可ルール
- DMA 実行時に登録した、移行元 VM（DB-VM1）のパブリック IP の許可ルール