Azure Arc-enabled SQL ServerをAzure VMへ移行する方法｜統合ワークフローとSQL MIの選び方

Azure Arcで管理しているオンプレミスのSQL Serverは、Azureポータルの統合ワークフローから、Azure SQL Managed Instance（SQL MI）またはAzure VM上のSQL Serverを選んで移行できるようになりました。Azure VM向けのデータベース移行は2026年6月に一般提供となり、評価、移行先の選択、データ転送、監視、カットオーバーまでをArcの管理画面から進められます。(Microsoft Azure)

移行先の判断基準は明確です。OSやファイルシステムへのアクセス、特定バージョンの維持、サードパーティ製エージェント、SQL Server固有機能への依存がある場合はAzure VMが適しています。一方、OSの管理、パッチ適用、バックアップ、高可用性の運用負担を減らしたい場合はSQL MIが有力です。

なお、Azure Update 567362は機能追加の一般提供を知らせるものであり、オンプレミスSQL Serverの強制移行やAzure Arc管理の終了を告知するものではありません。発表内に移行期限は示されていないため、自社のSQL Serverサポート期限、ハードウェア更新、データセンター退去などに合わせて計画できます。

Azure Arc-enabled SQL Server migrationの一般提供で何が変わったのか

Azure Arc-enabled SQL Server migrationでは、Arcに接続されたSQL Serverのインベントリと評価結果を利用し、AzureポータルからAzure SQLへの移行を開始できます。

公式リリースノートでは、SQL MI向けのデータベース移行が2025年10月に一般提供され、Azure VM上のSQL Server向け移行が2026年6月に一般提供されたと整理されています。これにより、Arcで管理している同じSQL Serverリソースから、PaaSとIaaSの両方を移行先として比較できるようになりました。(Microsoft Learn)

主な流れは次の4段階です。

段階	実施内容
ソース評価	SQL Serverと各データベースの互換性、性能、移行阻害要因を確認
ターゲット選択	SQL MIまたはAzure VM上のSQL Serverを選択
データ移行	移行先に応じた方法でデータを転送
監視とカットオーバー	進捗や同期状態を確認し、本番接続を移行先へ切り替え

Arcの移行評価は定期的に自動生成され、必要に応じて手動実行もできます。評価結果には、移行可否だけでなく、推奨構成、互換性上の警告、想定コストも表示されます。(Microsoft Learn)

統合されたのは管理導線であり、移行方法そのものではない

「統合ワークフロー」と聞くと、SQL MIとAzure VMで同じ方式を使ってデータが移動するように見えます。しかし、共通化されたのは主にAzureポータル上の操作と監視です。

実際のデータ移行方式は移行先によって異なります。

Azure VM上のSQL Server：Azure Blob Storageを介したバックアップと復元
SQL MI：Managed Instance linkによるオンライン移行、またはLog Replay Serviceによるバックアップベースの移行

また、Arcの画面で開始できるのは基本的にユーザーデータベースの移行です。OS、SQL Server Agentジョブ、資格情報、SSISパッケージ、高可用性構成などがすべて自動移行されるわけではありません。(Microsoft Learn)

Azure Update 567362に移行期限はあるのか

Azure Update 567362および2026年6月のリリースノートには、次のような期限は記載されていません。

Azure Arc-enabled SQL Serverからの移行期限
Azure VM上のSQL Serverを選択しなければならない期限
SQL MIへの移行義務
既存のArc管理機能の終了日
旧移行ツールの廃止日

したがって、この更新を理由に直ちに本番移行を実施する必要はありません。今回の更新は、移行先の選択肢が増えたという情報提供です。(Microsoft Azure)

ただし、実務上は次の期限を別に確認する必要があります。

使用中のSQL Serverバージョンのサポート終了時期
Extended Security Updatesの契約や終了時期
Windows Serverのサポート期限
物理サーバーや仮想基盤の更新時期
データセンターや保守契約の終了時期
業務システムベンダーの対応期限

今回の一般提供を「すぐ移行する理由」ではなく、次回更新時にAzure VMとSQL MIを正式に比較できるようになった機会と捉えるのが適切です。

なお、一部の個別準備ページにプレビュー表記が残っている場合がありますが、2026年6月の上位リリースノートと「新機能」ページでは一般提供と明記されています。機能状態を確認するときは、最新のリリースノートを優先してください。(Microsoft Learn)

Azure SQL MIとAzure VM上のSQL Serverの選び方

Microsoftの選定ガイドと移行ドキュメントを整理すると、次の基準で判断できます。(Microsoft Learn)

判断項目	Azure SQL Managed Instance	Azure VM上のSQL Server
サービス形態	PaaS	IaaS
OSへのアクセス	不可	可能
ファイルシステムへの直接アクセス	制限あり	可能
SQL Serverバージョンの固定	サービス側の更新方針に従う	対応範囲内で選択しやすい
OS・SQL Serverのパッチ管理	Microsoft側の管理範囲が大きい	利用者が設計・管理
バックアップと高可用性	組み込み機能を利用可能	利用者が構成・運用
SQL Serverとの互換性	高いが未対応機能がある	最も高い
サードパーティ製エージェント	SQL Serverと同一OSには導入できない	同一VMへ導入可能
FILESTREAMやFileTable	要件によっては不適合	利用しやすい
SSIS・SSRS・SSAS	別サービスや別構成の検討が必要	同一VMまたは関連VMで構成可能
運用負荷	比較的小さい	比較的大きい
向いている移行	運用モダナイズ	互換性重視のリホスト、リプラットフォーム

Azure VM上のSQL Serverを優先すべきケース

次のいずれかに該当する場合は、SQL MIよりもAzure VMが安全です。

OSに業務アプリケーションや監視エージェントをインストールしている
ファイル共有やローカルディスクをSQL Serverから直接利用している
特定のSQL Serverバージョンを維持しなければならない
FILESTREAM、FileTable、PolyBaseなどへの依存がある
SQL Serverと同一サーバー上でSSIS、SSRS、SSASを稼働させている
SQL Serverの構成、サービスアカウント、レジストリを細かく制御したい
ベンダーの製品サポート条件が「Windows Server上のSQL Server」に限定されている

SQL MIの互換性評価が「Ready」であっても、データベース外の依存関係までは別途確認する必要があります。

Azure SQL Managed Instanceを優先すべきケース

次の条件を満たす場合は、SQL MIを第一候補にできます。

OSを管理したくない
パッチ適用やバックアップ運用をサービス側に任せたい
高可用性を個別に構築する負担を減らしたい
SQL Serverに近い機能を維持しながらPaaS化したい
Managed Instance linkを使い、停止時間を短縮したい
SQL Server Agentやクロスデータベースクエリなど、SQL MIでサポートされる機能の範囲で要件を満たせる
将来の運用標準化を優先したい

SQL MIは「SQL Serverと完全に同じ」ではありません。互換性評価に加え、ログイン、ジョブ、リンクサーバー、暗号化証明書、外部接続などを個別に確認してください。

移行前に確認するチェックリスト

移行操作を始める前に、少なくとも次の項目を確定させます。

確認項目	実務上の確認内容
Arc接続状態	対象インスタンスとデータベースがAzureポータルに表示されているか
拡張機能	Azure Extension for SQL Serverが最新か
評価日時	古い評価結果を使っていないか
互換性	Not readyや警告の原因を確認したか
性能	CPU、メモリ、IOPS、スループットのピークを把握したか
ネットワーク	オンプレミス、Azure、Blob Storage間の通信が可能か
権限	Azure RBAC、SQL Server権限、マネージドIDを準備したか
インスタンスオブジェクト	ログイン、ジョブ、資格情報、リンクサーバーを一覧化したか
カットオーバー	書き込み停止、接続先変更、確認担当者を決めたか
ロールバック	移行後に戻す条件と手順を決めたか

Arcの評価画面には、推奨ターゲット、移行可否、推奨SKU、月額コストの概算が表示されます。ただし、推奨ターゲットは純粋な互換性だけで決まるわけではありません。

既定の「PaaSへのモダナイズ」戦略では、移行可能であればSQL MIなどのPaaSが優先されます。「コスト最小化」を選ぶと、移行問題が少なく、月額費用が低いターゲットが優先されます。したがって、推奨結果をそのまま採用するのではなく、自社の運用方針に合った評価戦略を設定することが重要です。(Microsoft Learn)

また、評価画面の料金は比較用の概算です。実際のリージョン、予約、Azure Hybrid Benefit、ストレージ、バックアップ、通信費を含めた最終予算は、別途料金計算を行ってください。

Arc inventoryから始める統合ワークフロー

Azure Arc-enabled SQL Server migrationの基本手順は、移行先がSQL MIでもAzure VMでも共通です。

手順	Azureポータルでの操作	完了条件
対象選定	ArcのSQL Server一覧または移行ダッシュボードを開く	移行対象インスタンスを特定
評価	`Migration`から評価を開き、必要なら再実行	阻害要因と推奨構成を確認
ターゲット決定	SQL MIまたはSQL Server on Azure VMを選択	移行先方式を承認
環境準備	ネットワーク、権限、ストレージ、移行先を構築	接続テストに成功
データ移行	`Database migration`から移行を開始	データ同期または復元完了
監視	`Monitor migrations`で進捗を確認	Ready for cutoverになる
カットオーバー	書き込み停止後に切り替え	アプリが移行先へ接続
移行後確認	性能、ジョブ、認証、バックアップを確認	業務受入が完了

評価結果は直前に再実行する

Arcの評価は定期的に自動更新されますが、移行設計の確定前と本番移行前には手動で再実行するのが安全です。

評価後にデータベースを追加した場合、最新のデータベースや料金が結果に含まれていない可能性があります。評価画面では、次の状態を確認します。

Ready：重大な移行阻害要因が見つかっていない
Not ready：互換性、構成、性能のいずれかに問題がある
Unknown：検出中または評価処理に問題がある

Readyであっても、警告やデータベース外の依存関係が残っていないとは限りません。(Microsoft Learn)

Azure VM上のSQL Serverへ移行する具体手順

移行先のSQL Server VMを準備する

移行先は、既存のSQL Server VMまたは新しく作成するSQL Server VMから選べます。

既存VMを使う場合は、SQL IaaS Agent extensionへの登録が必要です。新規VMをワークフロー内で作成した場合は、通常は登録処理も含めて構成されます。(Microsoft Learn)

VMサイズだけでなく、次の項目を事前に設計します。

SQL Serverのバージョンとエディション
データ、ログ、tempdbのディスク構成
IOPSとスループット
バックアップ方式
可用性ゾーンや可用性セット
Always On可用性グループの要否
Azure Hybrid Benefitの適用可否
監視、パッチ適用、ウイルス対策の運用方法

Arcの移行処理は、移行元の高可用性構成をそのまま再現しません。可用性グループやディザスターリカバリーは、移行後の構成として別途設計する必要があります。

Azure Blob Storageと権限を準備する

Azure VM向けのArc移行では、バックアップファイルの中継場所としてAzure Blob Storageを使用します。

公式手順では、ストレージアカウントを移行先SQL Server VMと同じサブスクリプションおよびリージョンに用意します。移行実行者とVMのマネージドIDには、Blob Storageを読み取る権限が必要です。(Microsoft Learn)

確認する項目は次のとおりです。

ストレージアカウントのファイアウォール
VMからBlob Storageへのアウトバウンド通信
移行実行者のAzure RBAC
VMのシステム割り当て、またはユーザー割り当てマネージドID
Blobコンテナーへの読み取り権限
バックアップファイルのフォルダー構成

データベースを複数移行する場合は、データベースごとに別フォルダーを作成します。各データベースのフォルダー内はフラットにし、さらに入れ子のフォルダーを作らないようにします。

バックアップを作成してアップロードする

最初にフルバックアップを取得します。継続移行を行う場合は、差分バックアップやトランザクションログバックアップも同じ場所へアップロードします。

バックアップには、次のオプションを付けることが推奨されています。

BACKUP DATABASE [SampleDB]
TO DISK = 'C:\Backup\SampleDB_full.bak'
WITH COMPRESSION, CHECKSUM;

COMPRESSIONは転送量を抑え、CHECKSUMは破損したバックアップを移行するリスクを低減します。ログバックアップを使う場合は、対象データベースを完全復旧モデルに設定しておきます。(Microsoft Learn)

Azureポータルから移行を開始する

対象のArc-enabled SQL Serverリソースを開き、次の順序で操作します。

MigrationからDatabase migrationを開く
Assess source instanceで評価結果を確認する
Select targetで既存または新規のSQL Server VMを指定する
Migrate dataを選択する
Migrate using backup and restoreを選ぶ
移行するデータベースを選択する
Blob Storageのサブスクリプション、リソースグループ、コンテナー、ディレクトリを指定する
警告とエラーを確認し、データ移行を開始する

移行画面を開く前に、少なくとも1つのフルバックアップがBlob Storageに存在し、権限が設定されている必要があります。(Microsoft Learn)

監視してカットオーバーする

移行開始後は、Monitor migrationsから次の情報を確認できます。

移行中または完了したデータベース
選択した移行方式
移行先インスタンス
開始時刻
所要時間
エラーやログ

継続移行を行う場合は、カットオーバーまで差分バックアップやログバックアップをアップロードし続けます。

本番切り替え時は、次の順序で進めます。

アプリケーションからの書き込みを停止する
最終ログバックアップを取得してアップロードする
移行状態がReady for cutoverになるまで待つ
Cutoverを実行する
接続文字列、DNS、別名などを移行先へ切り替える
読み書きと性能を確認する

カットオーバー直後に移行元を削除するのではなく、一定期間は書き込みを停止した状態で保持すると、問題発生時の調査やロールバック判断がしやすくなります。

SQL MIへ移行する場合の手順と方式

SQL MIを選択した場合も、ArcリソースのDatabase migrationから移行を進めます。評価、ターゲット選択、データ移行、監視、カットオーバーという画面構成はAzure VM向けと共通です。(Microsoft Learn)

データ移行方式は主に次の2つです。

移行方式	特徴	適したケース
Managed Instance link	分散可用性グループによるほぼリアルタイムのレプリケーション	停止時間を最小化したい
Log Replay Service	フル、差分、ログバックアップを順次復元	バックアップベースで移行したい

Managed Instance link

Managed Instance linkでは、オンプレミスSQL ServerとSQL MIの間で変更を継続的に同期します。

本番切り替えまでは移行元を稼働させられるため、業務停止時間を短縮できます。ただし、SQL Serverのバージョンやエディション、ネットワーク、ポート、可用性グループ関連の前提条件があります。

カットオーバー前には、レプリケーション遅延を確認します。遅延が大きい場合は、次の対処が必要です。

移行元の負荷を下げる
アプリケーション接続を一時停止する
ネットワーク帯域を見直す
SQL MI側のリソースを増やす

同期が完了していない状態で切り替えると、カットオーバーが長時間化したり、失敗したりする可能性があります。(Microsoft Learn)

Log Replay Service

Log Replay Serviceでは、Azure Blob Storageに配置したバックアップをSQL MIへ順次適用します。

ネットワークでリアルタイムレプリケーションを構成しにくい場合や、バックアップ運用を利用して段階的に移行したい場合に適しています。一方、移行中の対象データベースは復元中の状態になるため、Managed Instance linkとは利用方法が異なります。

SQL MI移行時に別途対応するもの

SQL MIへのデータベース移行だけでは、次の項目がすべて自動で移動するわけではありません。

SQLログインとWindowsログイン
SQL Server Agentジョブ
資格情報
サーバーレベルのトリガー
リンクサーバー
暗号化証明書
masterやmsdbに保存された設定
SSIS、SSRS、SSASの構成

特にシステムデータベースの復元はサポートされないため、必要なオブジェクトをスクリプト化し、移行先で再作成します。(Microsoft Learn)

また、Arcの移行画面からSQL MIへのリバース移行を直接実行することはできません。移行を戻す可能性がある場合は、Managed Instance linkの更新ポリシーや逆移行の対応条件を事前に確認し、ネイティブバックアップなどの代替手順を準備してください。(Microsoft Learn)

Azure VM移行で失敗しやすいポイント

データベース移行をサーバー全体の移行と誤解する

Arcの統合ワークフローは、主にデータベースを移行する機能です。次の項目は別途移行または再構築が必要です。

SQL Server Agentジョブ
資格情報
SSISパッケージ
サーバー監査
高可用性と災害対策構成

移行前にmaster、msdb、Windowsタスク、ファイル共有、サービスアカウント、証明書を含む棚卸しを行ってください。(Microsoft Learn)

既存データベースを上書きしようとする

Azure VM向けのポータル移行では、移行先に同名のデータベースが存在する場合、そのデータベースを上書きできません。

テスト移行後に本番移行をやり直す場合は、移行先データベースの削除、名称変更、別VMの利用などを事前に計画します。

Blob Storageの権限だけを見てネットワークを確認しない

RBACが正しくても、ストレージアカウントのファイアウォールやVMのアウトバウンド通信が遮断されていると、バックアップを読み取れません。

本番移行前に、移行先SQL Server VMからRESTORE HEADERONLYなどを実行し、バックアップファイルへアクセスできることを確認しておくと安全です。

平均負荷だけでVMを選ぶ

平均CPU使用率が低くても、月末処理、バッチ、バックアップ、インデックス再構築時に負荷が集中することがあります。

VMサイズは平均値ではなく、次のピーク値を基準に決定します。

CPU
使用メモリ
データファイルのIOPS
ログ書き込み量
ストレージスループット
tempdb負荷

一度に大量のデータベースを移行する

公式ドキュメントでは、同じAzure VMへ移行できるデータベース数や、移行処理を順次実行する際の制約が示されています。多数のデータベースを一括移行すると、開始処理とカットオーバー処理だけでも時間がかかります。

大規模環境では、業務単位や依存関係単位でバッチを分け、移行時間を実測してから本番計画を作成してください。(Microsoft Learn)

フェールオーバークラスターインスタンスをそのまま移行しようとする

Arcのデータベース移行では、SQL Serverフェールオーバークラスターインスタンスからの移行がサポートされないケースがあります。

FCIや既存の可用性グループを構成ごと移したい場合は、Azure Migrateによるサーバー単位のリフトアンドシフトを検討します。

統合ワークフローを使わない代替策

Arcのポータル移行が常に最適とは限りません。移行対象や停止時間によっては、別方式が適しています。(Microsoft Learn)

状況	代替策	選ぶ理由
OSやSQL Server構成を含めて移したい	Azure Migrate	サーバー単位でリフトアンドシフトできる
FCIや可用性グループを構成ごと移したい	Azure Migrate	ArcのDB移行では扱えない構成に対応しやすい
少数DBで停止時間を確保できる	ネイティブバックアップと復元	構成が単純でトラブルを切り分けやすい
Azure VMへ低停止で移したい	分散可用性グループ、ログ配布	継続同期後に切り替えられる
SQL MIへ低停止で移したい	Managed Instance link	ほぼリアルタイムで同期できる
Arcに接続していないSQL Serverを移したい	SSMSの移行機能、Azure Database Migration Service	Arcの事前登録なしで進められる方式がある
ネットワーク帯域が不足している	オフライン転送とバックアップ復元	大容量データをネットワークだけに依存せず移せる
データの一部だけ移したい	レプリケーション、bcp、Data Factory	テーブル単位や変換を伴う移行に対応できる

Azure Migrateのリフトアンドシフトは、OS、SQL Server、BI関連サービスなどを含めて環境を大きく変えずに移したい場合に向いています。一方、Arcの統合ワークフローは、移行先を評価しながらデータベース単位でAzure SQLへ移行したい場合に向いています。

実務でのおすすめの進め方

本番環境を安全に移行するには、次の順序が現実的です。

非機能要件を先に固定する

最初に、移行先に必須となる条件を整理します。

許容停止時間
必要なSQL Server機能
OSアクセスの要否
バージョン固定の要否
目標性能
可用性と復旧時間
運用担当者の体制
月額費用の上限

これらを決めずにArcの推奨結果だけを見ると、PaaS化を優先すべきか、互換性を優先すべきか判断できません。

Arc評価を最新化する

対象SQL Serverの評価を手動実行し、SQL MIとAzure VMの両方について次を比較します。

Ready、Not ready、Unknown
互換性の警告
推奨SKU
推奨移行先
コスト概算
修正が必要なオブジェクト

非本番データベースで試行する

最初から全データベースを移行せず、業務影響が小さいデータベースで次を実測します。

バックアップ時間
Blob Storageへの転送時間
復元時間
カットオーバー時間
アプリケーションの変更箇所
移行後のSQL性能
ログインやジョブの再作成時間

本番と同じ手順でリハーサルする

データ量が少ないテスト環境だけでは、本番の移行時間を予測できません。可能であれば、本番バックアップを使った復元リハーサルを実施し、移行手順書に実測時間を記録します。

カットオーバー判定基準を数値化する

「問題なければ切り替える」ではなく、次のような判定基準を決めます。

未同期ログがない
主要テーブルの件数が一致する
DBCC CHECKDBで重大エラーがない
主要SQLの応答時間が許容範囲内
バックアップジョブが正常に完了する
監視アラートが設定されている
業務担当者の受入確認が完了している

まとめ

Azure Arc-enabled SQL Server migrationでは、Arcで管理しているSQL Serverを、AzureポータルからSQL MIまたはAzure VM上のSQL Serverへ移行できます。Azure VM向け移行が一般提供されたことで、互換性重視のIaaS移行と運用モダナイズを重視するPaaS移行を、同じ評価結果から比較しやすくなりました。

判断の基本は次のとおりです。

OS、ファイル、特定バージョン、未対応機能への依存があるならAzure VM
パッチ、バックアップ、高可用性の運用負担を減らすならSQL MI
サーバー全体やFCIを構成ごと移すならAzure Migrate
停止時間を最小化するなら、SQL MIではManaged Instance linkを検討
Arcの推奨結果だけでなく、データベース外の依存関係も確認する

最初に行うべき作業は、Arc inventoryから対象インスタンスを選び、最新の移行評価を実行することです。そのうえで、SQL MIとAzure VMの互換性、運用負荷、停止時間、費用を比較し、非本番データベースで移行リハーサルを実施してください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure Arc-enabled SQL ServerをAzure VMへ移行する方法｜統合ワークフローとSQL MIの選び方