SQL Server to Azure SQL Database: Migration Guideで最初に押さえるべき結論は、Azure SQL Databaseへの移行は「SQL Serverをそのままクラウドへコピーする作業」ではなく、PaaS前提で互換性・移行方式・切り替え手順・接続設定を見直すプロジェクトだという点です。特に管理者と開発者は、Azure Database Migration Serviceを使うAzure SQL Database向け移行が基本的にオフライン移行であり、移行開始時点からアプリケーション停止が発生すること、ダウンタイムを抑えたい場合はトランザクションレプリケーションなど別方式を検討することを早めに確認する必要があります。(Microsoft Learn)
この記事では、2026年5月28日時点で確認しておきたいMicrosoft公式情報をもとに、SQL ServerからAzure SQL Databaseへ移行する際の変更点、影響範囲、設定・移行・展開上の注意点を整理します。社内の移行手順書が古いままだと、「Azure SQL Databaseで使えないSQL Server機能」「想定外の停止時間」「ファイアウォールや認証の設定漏れ」「移行後の性能劣化」でつまずきやすいため、実行前チェックリストとして活用してください。
Azure SQLのSQL Server to Azure SQL Database: Migration Guideで押さえるべき変更点
今回のポイントは、新しい移行機能が単純に追加されたというより、Azure SQL Databaseへの移行で確認すべき前提がより明確になっていることです。Microsoft Learnの移行ガイドは、移行前タスクを完了してからスキーマとデータ移行に進む流れを前提にしています。つまり、先にDMSやBACPACを動かすのではなく、検出、評価、移行先設計、接続設定、権限確認を済ませてから移行する構成です。(Microsoft Learn)
また、公式ドキュメントのGitHub履歴では、2026年2月に「Azure Data Studioからの移行コンテンツを削除する」趣旨の大きな整理が行われています。旧手順書でAzure Data Studioの移行拡張機能を前提にしている場合は、Azure portal上のAzure Database Migration Serviceや現在の公式チュートリアルに合わせて見直す必要があります。(GitHub)
さらに、関連するAzure SQL DatabaseのIPファイアウォール規則の公式情報は2026年5月28日に更新されており、移行時の接続許可、Azureサービスからの接続、データベース単位のファイアウォール規則、Private Endpointの検討が重要です。移行作業はデータコピーだけでなく、ネットワーク到達性と認可設定まで含めて計画する必要があります。(Microsoft Learn)
影響を受ける対象者
SQL ServerからAzure SQL Databaseへの移行で影響を受けるのは、DBAだけではありません。アプリケーション接続、認証、バッチ、監視、CI/CD、ネットワーク設定まで関係します。
| 対象者 | 主な影響 | すぐ確認すべきこと |
|---|---|---|
| データベース管理者 | 移行方式、スキーマ移行、互換性、性能検証 | DMS、BACPAC、bcp、トランザクションレプリケーションのどれを使うか |
| インフラ管理者 | Azure SQL DatabaseのSKU、ネットワーク、ファイアウォール、Private Endpoint | 接続元IP、ポート1433、Azureサービス許可、DNS、監査設定 |
| アプリ開発者 | 接続文字列、リトライ処理、T-SQL差分、SQL Agent依存 | 接続先変更、トランジェントエラー対応、未対応構文の修正 |
| セキュリティ担当 | 権限、ログイン、監査、公開エンドポイント | Microsoft Entra ID、SQLログイン、最小権限、監査ログ |
| 運用担当 | 切り替え、ロールバック、監視、移行後テスト | カットオーバー手順、性能ベースライン、移行後の統計更新 |
特に開発者は、Azure SQL DatabaseがSQL Serverと同じT-SQLを広くサポートする一方で、インスタンスレベル機能、OSやファイルシステムに依存する機能、Always On関連の一部ステートメントなどはそのまま使えない点を確認しておく必要があります。(Microsoft Learn)
Azure SQL Databaseは「SQL Serverインスタンスの完全コピー先」ではない
Azure SQL DatabaseはフルマネージドPaaSとして、バックアップ、高可用性、スケーリング、監視、チューニングなど多くの管理作業をAzure側に任せられるサービスです。一方で、SQL ServerインスタンスをOSごと、またはサーバーレベルの機能ごと移す移行先ではありません。(Microsoft Learn)
たとえば、次のような要件が強い場合、Azure SQL DatabaseではなくAzure SQL Managed InstanceやAzure VM上のSQL Serverを検討した方がよいケースがあります。
| 要件 | Azure SQL Databaseでの注意点 | 代替候補 |
|---|---|---|
| OSやファイルシステムへ直接アクセスしたい | PaaSのためOSレベル操作はできない | Azure VM上のSQL Server |
| FILESTREAM、FileTable、PolyBase、クロスインスタンストランザクションに強く依存 | Azure SQL Databaseではそのまま移行できない場合がある | Azure SQL Managed Instance、Azure VM |
| SQL Agentジョブをそのまま使いたい | Azure SQL DatabaseではSQL Agentジョブを直接サポートしない | Elastic Jobs、Automation、Managed Instance |
| Windowsログインを使っている | Azure SQL DatabaseではWindowsログインはサポートされない | Microsoft Entra ID、SQLログインの再設計 |
| Always On構成を手動で引き継ぎたい | 高可用性はAzure SQL Database側に組み込まれている | サービスレベル、フェールオーバーグループ設計 |
公式情報でも、SQL AgentジョブはAzure SQL Databaseで直接サポートされずElastic Jobsの利用が案内され、WindowsログインはMicrosoft Entra IDログインやSQLログインへの置き換えが必要とされています。(Microsoft Learn)
移行方式の選び方
SQL ServerからAzure SQL Databaseへの移行方式は、許容できる停止時間、データベースサイズ、テーブル数、移行対象範囲、運用チームのスキルで決めます。最初に「使えそうなツール」を選ぶのではなく、停止時間から逆算して方式を選ぶのが実務では安全です。
| 移行方式 | 向いているケース | 注意点 |
|---|---|---|
| Azure Database Migration Service | Azure portal中心でオフライン移行を管理したい | Azure SQL Database向けオンライン移行は利用できないため、停止時間の検証が必要 |
| トランザクションレプリケーション | 本番DBを止めにくく、変更を継続反映したい | 構成が複雑。ソースDBが要件を満たし、Azure SQL Databaseと互換性がある必要がある |
| BACPAC | 小規模DBや検証環境、単発移行 | エクスポートとインポート中に停止が必要。大規模DBやオブジェクト数が多いDBでは時間が延びやすい |
| bcp | 一部テーブルや大量データのコピーを制御したい | スキーマ、制約、データ型、エラー処理を自前で管理する必要がある |
| Azure Data Factory | ETLやデータ統合を兼ねたい | 完全なDB移行というより、データ移動・変換パイプライン向き |
Azure Database Migration ServiceのAzure SQL Database向けチュートリアルでは、移行プロセス中に許容できるダウンタイムを考慮し、オフライン移行モードを使うことが明記されています。現時点ではAzure SQL Databaseターゲットのオンライン移行はDMSで利用できず、オフライン移行では移行開始時点がアプリケーション停止の起点になります。(Microsoft Learn)
ダウンタイムを短くしたい場合はトランザクションレプリケーションを検討する
本番DBを長時間止められない場合は、トランザクションレプリケーションが候補になります。Azure SQL Databaseをサブスクライバーとして構成し、SQL Server側の変更を継続的に反映しておき、同期完了後にアプリケーションの接続文字列をAzure SQL Databaseへ切り替える流れです。(Microsoft Learn)
ただし、トランザクションレプリケーションは「停止時間を短くできる便利な移行ボタン」ではありません。ディストリビューター、パブリケーション、サブスクリプションの設計が必要です。Azure SQL Databaseではプッシュサブスクリプションのみがサポートされ、古いSSMSではSQL Databaseをサブスクライバーとして設定できないため、最新のSQL Server Management Studioを使うことも重要です。(Microsoft Learn)
移行前に確認すべき設定
移行前の確認で重要なのは、データベース単体だけでなく、アプリケーション、ジョブ、ログイン、ネットワーク、監視まで棚卸しすることです。Microsoftの移行前ガイドでも、SQL Serverインスタンスと機能の検出、阻害要因や互換性問題の評価、移行方法の選択、移行先Azure SQL Databaseの作成、接続と権限の設定が前提タスクとして示されています。(Microsoft Learn)
互換性とT-SQL差分
Azure SQL Databaseでは多くのT-SQL機能がSQL Serverと同じように動きますが、インスタンスレベル、OS、ファイル配置に依存する構文は制限されます。たとえば、CREATE DATABASEやALTER DATABASEの一部オプション、FILESTREAM、FileTable、ログイン関連の一部オプションは移行前に確認が必要です。(Microsoft Learn)
実務では、次の観点で洗い出すと漏れを減らせます。
| 確認項目 | 例 | 対応例 |
|---|---|---|
| SQL Server固有構文 | ファイル配置、FILESTREAM、インスタンス設定 | Azure SQL Database向け構文へ修正 |
| サーバーレベルオブジェクト | ログイン、リンクサーバー、SQL Agentジョブ | Entra ID、SQLログイン、Elastic Jobsなどへ置換 |
| アプリケーションSQL | 動的SQL、DB名固定、3部名参照 | 接続DB前提のクエリへ修正 |
| バッチ・ETL | SSIS、SQL Agent、外部ファイル依存 | Azure Data Factory、Functions、Automationを検討 |
| 高可用性構成 | Always On、フェールオーバークラスター | Azure SQL Databaseのサービスレベルやフェールオーバーグループで再設計 |
ネットワークとファイアウォール
Azure SQL Databaseの新しい論理サーバーは、既定でパブリックエンドポイントへのアクセスがファイアウォールでブロックされます。接続元からAzure SQL Databaseへ接続するには、サーバーレベルまたはデータベースレベルのIPファイアウォール規則を設計する必要があります。(Microsoft Learn)
公式情報では、可能な場合はデータベースレベルのIPファイアウォール規則を使うことが推奨されています。サーバーレベル規則は、そのサーバー配下のすべてのDBへ影響するため、管理者や共通要件向けに限定して使う方が安全です。(Microsoft Learn)
注意したいのが、Azure portalの「Azureサービスおよびリソースにこのサーバーへのアクセスを許可する」に相当する設定です。これを有効にすると、0.0.0.0の規則が作成され、他の顧客サブスクリプションを含むAzure上のサービスから接続試行が可能になります。アクセス制御はログインと権限で守る必要がありますが、セキュリティを重視する環境ではPrivate Endpointや仮想ネットワークサービスエンドポイントを優先的に検討してください。(Microsoft Learn)
また、移行元やアプリケーション側のネットワークでTCP 1433の送信が許可されているか、ファイアウォール変更の反映に最大数分程度の遅延があることも確認しておきましょう。(Microsoft Learn)
権限とログイン
DMSを使う場合、Azureアカウント、移行元SQL Serverログイン、移行先Azure SQL Databaseログインの権限を分けて確認します。公式チュートリアルでは、ターゲットAzure SQL Databaseの共同作成者、リソースグループ閲覧者、サブスクリプション所有者または共同作成者などのAzure側ロールに加え、移行元はdb_datareader、移行先はdb_ownerなどの権限が示されています。(Microsoft Learn)
スキーマ移行までDMSで行う場合は、ターゲット側で##MS_DatabaseManager##、##MS_DatabaseConnector##、##MS_DefinitionReader##、##MS_LoginManager##などの固定サーバーロールが関係します。移行直前に権限不足が分かると作業時間が大きく延びるため、本番移行前に同じ権限セットでリハーサルしておくことが重要です。(Microsoft Learn)
Azure Database Migration Serviceで移行する流れ
Azure Database Migration Serviceを使う場合の基本的な流れは、Azure portalでDMSインスタンスを作成または再利用し、移行シナリオを選択し、ソースSQL ServerとターゲットAzure SQL Databaseを接続し、データベースとテーブルを選んで移行を開始する形です。オンプレミスSQL Serverへ接続する場合は、セルフホステッド統合ランタイム（SHIR）が必要になることがあります。(Microsoft Learn)
手順を運用目線で整理すると、次のようになります。
| フェーズ | 作業 | 管理者・開発者の確認点 |
|---|---|---|
| 事前準備 | 移行先DB、DMS、権限、ネットワークを準備 | 接続元IP、SHIR、SQLログイン、SKU |
| スキーマ確認 | 互換性問題、未対応オブジェクトを確認 | T-SQL差分、計算列、CDC、ジョブ依存 |
| テスト移行 | 検証環境でDMS移行を実行 | 所要時間、エラー、テーブル単位の状態 |
| 本番停止 | 書き込み停止、最終バックアップ、関係者連絡 | 停止開始時刻、ロールバック判断基準 |
| データ移行 | DMSで移行を開始、進行状況を監視 | コピー、インデックス再構築、失敗テーブル |
| 切り替え | 接続文字列をAzure SQL Databaseへ変更 | アプリ再起動、シークレット更新、DNS不要化 |
| 移行後検証 | 件数、整合性、性能、エラーを確認 | 統計更新、クエリ性能、監視アラート |
DMSでは、移行の状態としてコピー準備、コピー、コピー完了、インデックス再構築、成功などを確認できます。テーブルごとの状態も見られるため、単に「移行ジョブが終わったか」ではなく、重要テーブルが正しくコピーされ、インデックス再構築まで完了しているかを確認してください。(Microsoft Learn)
日本語環境で特に注意したいDMSの制限
日本語圏のシステムで見落としやすいのが、テーブル名や列の仕様に関する制限です。Azure SQL Database向けDMSオフライン移行では、データ移動にAzure Data Factoryパイプラインが使われるため、その制限の影響を受けます。公式情報では、データベースあたり100,000テーブル、サービスごとに10,000個の同時データベース移行、移行速度がターゲットSKUとSHIRホストに大きく依存することなどが示されています。(Microsoft Learn)
特に確認したい制限は次の通りです。
| 制限・注意点 | 影響 | 対策 |
|---|---|---|
| 2バイト文字のAzure SQL Databaseテーブル名が移行でサポートされない | 日本語テーブル名を使うDBで失敗する可能性 | 移行前に一時的に英数字名へ変更し、移行後に戻す運用を検討 |
| 計算列は移行されない | 移行後に列やロジックが不足する | 事前にスクリプト化し、移行後に再作成 |
| 大きなBLOB列を持つテーブルがタイムアウトする場合がある | 添付ファイル、画像、文書格納テーブルで失敗しやすい | テーブル分割、別方式、リトライ計画を用意 |
| CDC有効DBでスキーマ移行にDMSを使う場合は事前無効化が必要 | CDC関連オブジェクトがターゲットに移り、移行後のCDC有効化で問題化 | 本番影響を確認した上でCDC停止手順を設計 |
| NULLと既定制約の扱いに注意 | NULLがターゲット側既定値で移行される可能性 | NULLを含む列を事前抽出し、検証SQLで確認 |
この制限は、移行リハーサルで必ず検出しておきたいポイントです。とくに日本語のテーブル名を使っている古い業務システムでは、移行当日に初めて分かると停止時間内に解決できない可能性があります。
パフォーマンスとSKU設計の注意点
移行中のボトルネックは、移行元SQL ServerのデータファイルI/O、ターゲットAzure SQL Databaseのログ生成速度、オンプレミスからAzureへのネットワーク帯域に分かれます。公式ガイドでは、Azure SQL Databaseの最大ログ生成速度やネットワーク帯域を踏まえ、必要に応じて移行中だけターゲットをスケールアップし、移行後にスケールダウンすることが推奨されています。(Microsoft Learn)
実務では、平常時の必要性能だけでAzure SQL DatabaseのSKUを決めると、移行中にコピー速度が出ず、停止時間が長くなることがあります。移行時だけ上位SKUにして、移行完了後に適正サイズへ戻す計画を立てると、停止時間とコストのバランスを取りやすくなります。
また、BACPACを使う場合は、BACPACファイルと移行先データセンターの距離を近づける、移行中は統計の自動更新や自動作成を無効にする、インデックス付きビューを削除して移行後に再作成する、といった考慮も公式ガイドに記載されています。(Microsoft Learn)
アプリケーション側で確認すべきこと
Azure SQL Databaseへ移行した後は、アプリケーションが旧SQL ServerではなくターゲットDBを使うように変更する必要があります。公式ガイドでも、データ移行後に旧ソースを使っていたすべてのアプリケーションがターゲット環境を使い始める必要があり、場合によってはアプリケーション変更が必要とされています。(Microsoft Learn)
開発者が確認すべき代表例は次の通りです。
| 確認項目 | よくある失敗 | 対応 |
|---|---|---|
| 接続文字列 | サーバー名、DB名、認証方式を変更し忘れる | Azure portalの接続文字列をもとに環境変数やKey Vaultを更新 |
| リトライ処理 | 一時的な接続エラーをそのまま画面エラーにする | 指数バックオフ付きリトライを実装 |
| タイムアウト | 移行後の初回実行や統計不足でタイムアウトする | 統計更新、クエリプラン確認、Command Timeout調整 |
| 認証 | Windowsログイン前提のまま接続する | Entra IDまたはSQLログインへ移行 |
| バッチ | SQL Agentジョブが動かない | Elastic Jobs、Azure Automation、Functionsなどへ置換 |
| 監視 | 旧SQL Serverの監視だけが残る | Azure Monitor、診断設定、SQL監査を追加 |
Azure SQL Databaseでは、クラウド側の再構成などで一時的な接続エラーが発生する可能性があるため、アプリケーションにはリトライロジックを入れることが推奨されています。初回リトライは短すぎる間隔を避け、以降は指数的に間隔を増やす考え方が示されています。(Microsoft Learn)
切り替え時の実務チェックリスト
本番切り替えでは、「移行ジョブを実行する人」だけでなく、「アプリを止める人」「接続文字列を変える人」「動作確認する人」「戻す判断をする人」を明確にします。カットオーバーの失敗は、技術的なエラーよりも役割分担と判断基準の曖昧さから起きることが多いです。
| タイミング | チェック内容 |
|---|---|
| 前日まで | リハーサル結果、移行所要時間、失敗時のロールバック手順を共有 |
| 停止直前 | 書き込み停止、ジョブ停止、バックアップ、監視抑止、関係者連絡 |
| 移行中 | DMS状態、失敗テーブル、SHIR負荷、ネットワーク、ターゲットDTU/vCore使用率 |
| 接続切替 | アプリ設定、Key Vault、環境変数、接続プール再作成、アプリ再起動 |
| 確認 | 件数、重要画面、登録・更新・検索、バッチ、帳票、外部連携 |
| 判断 | 継続、切り戻し、限定公開、追加修正の判断時刻を決める |
トランザクションレプリケーションを使う場合は、ソースとターゲットのデータが同じであることを確認したうえで、アプリケーションの接続文字列をAzure SQL Databaseへ切り替え、残りの変更が反映されたことを確認してからレプリケーションを解除します。(Microsoft Learn)
移行後に必ず行うべき確認
移行完了後は、データが入っただけで完了にしないでください。公式ガイドでは、移行後フェーズがデータ精度、完全性、性能問題に対処するために重要であり、移行完了後にフルスキャンで統計を更新すること、検証テストと性能テストを行うことが示されています。(Microsoft Learn)
最低限、次の確認を行います。
| 確認項目 | 具体例 |
|---|---|
| データ件数 | 主要テーブルの行数、日付範囲別件数、ステータス別件数 |
| データ整合性 | 合計金額、残高、注文数、親子テーブルの不整合 |
| アプリ動作 | ログイン、検索、登録、更新、削除、帳票、API連携 |
| 性能 | 主要SQLの実行時間、DTU/vCore、CPU、I/O、待機、タイムアウト |
| セキュリティ | 不要なファイアウォール規則、過剰権限、監査設定 |
| 運用 | バックアップ保持、監視アラート、障害時連絡、コスト監視 |
特に移行直後は統計情報や実行プランの影響で、オンプレミスSQL Serverと同じクエリでも性能が変わることがあります。移行前に取得した性能ベースラインと比較し、遅くなったSQLを個別に調整してください。
よくある失敗と回避策
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| 予定停止時間を超過する | DMSオフライン移行の所要時間を本番データ量で検証していない | 本番相当データでリハーサルし、停止時間を測定 |
| 移行後にアプリが接続できない | IPファイアウォール、ポート1433、認証、接続文字列の漏れ | 接続元ごとに疎通テストを実施 |
| SQL Agentジョブが消える | Azure SQL Databaseで直接サポートされない | Elastic JobsやAzure Automationに置換 |
| 日本語テーブル名でDMS移行に失敗 | 2バイト文字テーブル名の制限 | 命名変更、別方式、事前検証を行う |
| データ差異が後から見つかる | 行数だけ確認し、業務的な整合性を見ていない | 金額合計、ステータス別件数、重要トランザクションを検証 |
| セキュリティが広くなりすぎる | Azureサービス許可を安易にONにする | Private Endpoint、DB単位規則、最小権限を優先 |
| 移行後に一時エラーが表面化する | クラウドDB向けのリトライ処理がない | 接続・コマンドのリトライ設計を実装 |
管理者と開発者が次に取るべき行動
SQL ServerからAzure SQL Databaseへの移行を検討しているなら、まずは本番DBをいきなり移すのではなく、次の順番で進めてください。
- SQL Serverインスタンス、DB、ジョブ、ログイン、アプリ接続元を棚卸しする
- Azure SQL Databaseで使えない機能やT-SQL差分を評価する
- 許容停止時間を決め、DMS、トランザクションレプリケーション、BACPAC、bcpのどれを使うか選ぶ
- 移行先のSKU、ネットワーク、ファイアウォール、権限、監査を設計する
- 本番相当データでリハーサルし、移行時間と失敗パターンを記録する
- 接続文字列、リトライ処理、ジョブ置換、監視をアプリ側で対応する
- カットオーバー手順とロールバック基準を文書化する
Azure SQL Databaseへの移行は、移行ツールの操作よりも「移行前の評価」と「移行後の検証」で成否が決まります。公式ガイドの流れに沿って、互換性、ダウンタイム、ネットワーク、権限、アプリ改修を先に洗い出せば、移行当日のトラブルを大きく減らせます。
コメント