SQL Server Migration Assistant（SSMA）の2026年4月更新でまず確認すべき点は、移行先としてSQL Server 2025が明確に整理されたこと、そしてSSMAの実行環境や移行元別パッケージを見直す必要があることです。SSMAは、Access、Db2、MySQL、Oracle、SAP ASEなどからSQL ServerやAzure SQLへ移行するための支援ツールですが、「入れればそのまま移行完了」というツールではありません。移行可否の評価、変換できないSQLの洗い出し、ターゲット選定、権限・接続・検証計画まで含めて使うことで効果を発揮します。Microsoft Learnの該当ページは2026年4月24日に更新され、対応ターゲットとしてSQL Server 2019、SQL Server 2022、SQL Server 2025、Azure SQL Database、Azure SQL Managed Instanceが示されています。(Microsoft Learn)
SQL Server Migration Assistantの2026年4月更新で何が変わったか
今回の更新は、SSMAの概要ページだけを見ると小さなドキュメント更新に見えるかもしれません。しかし、DBA、データエンジニア、分析基盤の責任者にとっては、移行計画の前提を見直すタイミングです。
Microsoft公式ページでは、SSMAを「Microsoft Access、Db2、MySQL、Oracle、SAP ASEからSQL Server、Azure SQL Database、Azure SQL Managed Instance、Azure Synapse Analyticsへのデータベース移行を自動化するツール」と説明しています。あわせて、SSMAのサポート対象ターゲットとしてSQL Server 2019、SQL Server 2022、SQL Server 2025、Azure SQL Database、Azure SQL Managed Instanceが列挙されています。(Microsoft Learn)
| 確認ポイント | 2026年4月更新で見るべき内容 | 実務への影響 |
|---|---|---|
| 対応ターゲット | SQL Server 2019 / 2022 / 2025、Azure SQL Database、Azure SQL Managed Instance | 移行先候補にSQL Server 2025を含めた評価がしやすくなる |
| 移行元 | Access、Db2、MySQL、Oracle、SAP ASE | 移行元ごとにSSMAパッケージと前提条件を確認する必要がある |
| サポート対象の詳細 | 移行元のサポート情報はSSMAダウンロードごとの情報を確認する形 | 古い移行元バージョンを使っている場合は事前確認が必須 |
| 実行環境 | 関連するインストールページでWindows 11以降、Windows Server 2022以降、.NET Framework 4.7.2以降などが示されている | 移行作業用端末や踏み台サーバーのOSを見直す必要がある |
| サポート窓口 | 製品ヘルプ、SQL Serverコミュニティ、Azure Database Migration Guideが案内されている | 自社対応と外部支援の切り分けを早めに決めやすい |
GitHub上のMicrosoftDocsリポジトリでは、2026年4月24日のコミット説明に「source and targetのサポートバージョン更新」と「Acrolinx修正」が含まれており、SSMA関連の複数ページにまたがって文言やバージョン情報が整理されています。(GitHub)
SSMAは何を自動化し、何を自動化しないのか
SSMAは、異種データベースからSQL Server / Azure SQLへ移行する際の「評価」「変換」「ロード」「データ移行」を支援するツールです。たとえばSSMA for MySQLやSSMA for Oracleのインストールページでは、クライアントが移行元へ接続し、データベースオブジェクトをターゲット向けに変換し、変換済みオブジェクトをロードし、データを移行する流れが説明されています。(Microsoft Learn)
ただし、SSMAが担うのは主にデータベース層です。アプリケーションコード、帳票、バッチ、認証方式、ネットワーク設計、監視、運用手順までは自動的に完成しません。特にOracleのPL/SQL、MySQL固有の関数、AccessアプリケーションのフォームやVBA、Db2やSAP ASEの独自構文は、SSMAの評価結果を見ながら人が修正方針を決める必要があります。
| 領域 | SSMAで対応しやすいこと | 人が設計・判断すべきこと |
|---|---|---|
| スキーマ | テーブル、ビュー、インデックスなどの変換支援 | 命名規則、正規化方針、不要オブジェクトの廃止 |
| SQL変換 | 移行元SQLをSQL Server向けに変換 | 変換エラー、性能劣化、互換性差分の修正 |
| データ移行 | 移行元からターゲットへのデータ移行 | 停止時間、差分同期、リハーサル、ロールバック |
| レポート | 変換結果や問題点の把握 | 優先順位付け、工数見積もり、リスク判断 |
| 接続・権限 | 接続設定と権限チェックの一部 | Entra ID、ネットワーク、監査、最小権限設計 |
| アプリ連携 | 直接は対象外 | 接続文字列、ORM、SQL呼び出し、テスト自動化 |
対応する移行元と移行先を整理する
SSMAの移行元は、Access、Db2、MySQL、Oracle、SAP ASEの5系統に分かれています。Microsoft公式ページでも、それぞれの移行元向けにSSMA for Access、SSMA for Db2、SSMA for MySQL、SSMA for Oracle、SSMA for Sybaseが案内されています。(Microsoft Learn)
移行元ごとの確認ポイント
| 移行元 | よくある移行シーン | 事前に確認すべきポイント |
|---|---|---|
| Access | 部門利用の小規模DB、古い業務アプリのサーバー化 | フォーム、レポート、VBA、リンクテーブルの扱い |
| Db2 | メインフレーム、LUW、Db2 for iからの移行 | Db2の種類、文字コード、プロバイダー、関数差分 |
| MySQL | Webサービス、LAMP系システム、SaaS基盤 | 文字セット、照合順序、日付型、ストアドプログラム、権限 |
| Oracle | 基幹系、DWH、ERP周辺システム | PL/SQL、パッケージ、シノニム、シーケンス、NUMBER型 |
| SAP ASE | 旧Sybase系の業務システム | ASE固有構文、プロバイダー、拡張パック、ロック設計 |
Db2向けページでは、Db2 on z/OS、Db2 on LUW、Db2 for iなどの対象バージョンに加え、Microsoft OLE DB Provider for Db2や4GB RAM推奨といった前提条件が示されています。SAP ASE向けページでも、SAP ASE 16.0以降、Sybase系プロバイダー、4GB RAM推奨などが明記されています。(Microsoft Learn)
移行先ごとの選び方
今回の更新で特に重要なのは、SSMAのターゲット一覧にSQL Server 2025が含まれている点です。プロジェクト作成時の移行先候補としてSQL Server 2019、SQL Server 2022、SQL Server 2025、Azure SQL Database、Azure SQL Managed Instanceを選ぶ前提で計画を立てられます。(Microsoft Learn)
| 移行先 | 向いているケース | 注意点 |
|---|---|---|
| SQL Server 2019 / 2022 / 2025 | オンプレミス、Azure VM、既存運用に近い形で移行したい | OS、バックアップ、パッチ、可用性設計を自社で持つ必要がある |
| Azure SQL Database | 単一DBまたは複数DBをPaaSで運用したい | インスタンスレベル機能や一部T-SQL差分を事前確認する |
| Azure SQL Managed Instance | SQL Server互換性を重視しつつPaaS化したい | ネットワーク、インスタンス設計、更新ポリシーを含めて検討する |
| Azure Synapse Analytics | 分析・DWH用途へ展開したい | SSMA概要では移行先として触れられているが、ターゲット一覧や各SSMAパッケージの対応範囲を個別確認する |
Azure SQL DatabaseとAzure SQL Managed InstanceはどちらもAzure SQLのPaaSですが、機能差があります。Microsoftの比較ページでは、Azure SQL DatabaseとAzure SQL Managed Instanceのデータベースエンジン機能差や移行方法が整理されています。Azure SQL Managed InstanceはSQL Serverとの高い互換性を狙う選択肢として説明されています。(Microsoft Learn)
実行環境の要件変更は見落としやすい
SSMAの更新で現場がつまずきやすいのは、ターゲットDBではなく「SSMAを動かす端末」です。2026年4月時点の各インストールページでは、Access、MySQL、Oracle、Db2、SAP ASE向けのSSMAクライアントで、Windows 11以降またはWindows Server 2022以降、.NET Framework 4.7.2以降が前提として示されています。(Microsoft Learn)
移行プロジェクトでは、本番DBサーバーだけでなく、SSMAを実行する作業端末、踏み台サーバー、検証用VMも棚卸ししてください。古いWindows Server上で過去のSSMAを使い回している場合、最新版のSSMAを入れられない、プロバイダーが合わない、接続テストで失敗する、といった問題が起こりやすくなります。
| 確認項目 | 見るべき内容 | 失敗しやすいポイント |
|---|---|---|
| OS | Windows 11以降、Windows Server 2022以降に該当するか | 古い踏み台サーバーにSSMAを入れようとして失敗する |
| .NET Framework | 4.7.2以降が入っているか | セキュリティ制約でランタイム導入が止まる |
| 移行元プロバイダー | MySQL ODBC、Oracle接続、Db2 OLE DB、Sybase系プロバイダーなど | 32bit/64bit、バージョン、接続方式が合わない |
| 権限 | 移行元・移行先の読み取り、作成、ロード権限 | 評価はできるがロードやデータ移行で失敗する |
| メモリ | 4GB RAM推奨を満たすか | 大規模スキーマの評価で動作が重くなる |
| セキュリティ設定 | テレメトリ、更新チェック、GPO | 企業ポリシーとツール設定が食い違う |
SSMAには使用状況や診断データを送信するインターネット接続機能があり、レジストリでテレメトリや自動更新チェックを制御できます。企業環境では、移行検証を始める前にセキュリティ部門と設定方針を決めておくと、導入直前の差し戻しを避けられます。(Microsoft Learn)
SQL Server 2025をターゲットに含めるときの判断基準
SQL Server 2025をターゲットにできることは魅力ですが、すべての移行で最初からSQL Server 2025を選ぶべきとは限りません。判断基準は「新機能を使いたいか」ではなく、「移行後の運用・互換性・テスト体制まで含めて採用できるか」です。
SQL Server 2025を選びやすいケース
新規基盤へ移すタイミングでSQL Serverのバージョンも上げたい場合、SQL Server 2025を評価候補に入れる価値があります。特に、移行リハーサルを複数回実施できる、アプリケーション側のSQL互換性テストを自動化できる、性能検証環境を用意できる組織では、早めに評価しておくことで将来の再移行を避けやすくなります。
既存バージョンを選ぶほうがよいケース
本番移行までの期間が短い、アプリケーションのSQL呼び出しが多い、ベンダー製アプリが特定バージョンのみ対応している、監査や規制上の承認済み環境が限定されている場合は、SQL Server 2022やAzure SQL Managed Instanceなど、互換性と運用実績を優先したほうが安全です。
Azure SQL Managed Instanceを選ぶ判断
SQL Serverに近い互換性を保ちながらPaaSへ移行したい場合は、Azure SQL Managed Instanceが候補になります。MicrosoftはAzure SQL Managed Instanceについて、SQL Server Database Engineとの高い互換性を提供するPaaSとして説明しています。(Microsoft Learn)
一方で、Managed Instanceにも更新ポリシーやデータベース形式、リンク機能、バックアップ/リストアの制約があります。SQL Server 2025との関係を含む更新ポリシーはMicrosoftが個別に説明しているため、移行先を決める前に確認しておくべきです。(Microsoft Learn)
SSMAを使った移行の実務手順
SSMAを効果的に使うには、いきなり本番データを移すのではなく、評価、変換、検証、リハーサルの順に進めます。特に異種DB移行では、1回目の実行で「何が変換できないか」を明らかにすることが重要です。
| フェーズ | 作業内容 | 成果物 |
|---|---|---|
| 現状調査 | 移行元DB、バージョン、サイズ、オブジェクト数、利用アプリを棚卸し | 移行対象一覧、除外対象一覧 |
| ターゲット選定 | SQL Server、Azure SQL Database、Managed Instanceの候補比較 | ターゲット候補と選定理由 |
| SSMA準備 | 移行元別SSMA、プロバイダー、権限、ネットワークを準備 | 接続テスト結果 |
| 評価実行 | スキーマ変換、エラー、警告、手修正箇所を確認 | 変換レポート、課題一覧 |
| 修正方針決定 | 型変換、関数、ストアド、トリガー、ビューを修正 | 修正ルール、標準SQL化方針 |
| データ移行検証 | サンプルデータ、全量データ、差分移行を検証 | データ件数比較、整合性確認 |
| 性能検証 | 主要クエリ、バッチ、レポート、APIを実行 | 性能測定結果、インデックス案 |
| 本番リハーサル | 作業手順、停止時間、ロールバックを確認 | 移行手順書、判定基準 |
| 本番移行 | 手順に沿って切り替え | 移行完了報告、残課題一覧 |
SSMAのプロジェクトは、移行元メタデータ、移行先メタデータ、接続情報、プロジェクト設定を保持します。たとえばAccessやMySQL向けのプロジェクト作成ページでは、プロジェクトを作成し、移行先を選択し、必要に応じて設定を調整する流れが説明されています。(Microsoft Learn)
移行前に必ず作るべきチェックリスト
SSMAを使う移行では、ツールの実行結果だけで完了判定をしてはいけません。以下のチェックリストを事前に作り、各項目に担当者と完了条件を設定してください。
技術チェック
| 項目 | 確認内容 |
|---|---|
| 移行元バージョン | SSMAパッケージが対象としているバージョンか |
| 移行元接続 | 必要なプロバイダー、ポート、SSL/TLS、資格情報が揃っているか |
| 移行先 | SQL Server 2019 / 2022 / 2025、Azure SQL Database、Managed Instanceのどれにするか |
| 文字コード | 文字化け、照合順序、全角半角、絵文字、特殊文字の扱い |
| データ型 | NUMBER、DATETIME、BOOLEAN相当、JSON、空文字、ゼロ日付など |
| 制約 | 主キー、外部キー、ユニーク制約、チェック制約 |
| ストアド処理 | プロシージャ、関数、トリガー、パッケージの変換可否 |
| 性能 | 移行後の実行計画、インデックス、統計情報、バッチ時間 |
| 権限 | 移行用権限と本番運用権限を分けているか |
| 監査 | ログ、診断データ、更新チェック、GPO方針を確認したか |
業務チェック
| 項目 | 確認内容 |
|---|---|
| 停止時間 | 業務側が許容できる停止時間か |
| データ整合性 | 件数、合計値、ハッシュ、代表サンプルを比較するか |
| アプリ改修 | 接続文字列、SQL、ORM、バッチ、帳票の修正範囲 |
| ロールバック | 切り戻し条件、バックアップ、旧環境保持期間 |
| 運用引き継ぎ | 監視、バックアップ、障害対応、権限申請の手順 |
| コスト | Azureの場合、検証環境と本番環境のリソース見積もり |
| 責任分界点 | DBA、アプリ担当、クラウド担当、外部ベンダーの役割 |
よくある失敗と回避策
変換率だけで移行可否を判断する
SSMAの変換レポートでエラーが少なくても、業務がそのまま動くとは限りません。たとえば、変換できたSQLでも実行計画が変わり、バッチが想定以上に遅くなることがあります。変換率は「初期見積もりの材料」であり、完了判定ではありません。
Access移行でアプリ部分を見落とす
AccessからSQL Server / Azure SQLへ移行する場合、テーブルやクエリだけでなく、フォーム、レポート、VBA、リンクテーブルの扱いが問題になります。SSMAでデータベース層を移せても、利用者が触る画面や帳票の修正が残ることがあります。部門利用のAccessでは、実ユーザーの操作パターンを聞き取り、移行対象を「DB」「画面」「帳票」「マクロ」に分けることが重要です。
Azure SQL DatabaseとManaged Instanceを同じものとして扱う
Azure SQL Databaseは単一DBやエラスティックプールに向いたPaaSで、Managed InstanceはSQL Serverに近い互換性を重視したPaaSです。Microsoftの比較ページにも、両者の機能差や移行方法が整理されています。互換性を優先するならManaged Instance、アプリをクラウドネイティブに寄せたいならAzure SQL Database、といった観点で比較しましょう。(Microsoft Learn)
古いSSMAや古いプロバイダーを使い続ける
過去の移行プロジェクトで使ったSSMAをそのまま使うと、最新ターゲットを選べない、接続できない、評価結果が現行ドキュメントと合わないといった問題が起こります。各SSMAパッケージの最新版、移行元プロバイダー、.NET Framework、OS要件を移行計画書に明記してください。
本番直前に権限不足が発覚する
評価時は読み取り権限だけで進められても、スキーマロードやデータ移行では移行先への作成権限やデータ書き込み権限が必要になります。Azure SQLを使う場合は、認証方式、ファイアウォール、プライベート接続、監査ログも含めて早めに確認しましょう。
DBA・データエンジニア・分析リーダー別の次のアクション
DBAがやるべきこと
DBAは、SSMAの対象ターゲット、実行環境、権限、バックアップ、リカバリ方針を最初に固めます。特にSQL Server 2025を候補に入れる場合は、互換性レベル、運用監視、メンテナンス手順、障害時復旧を含めて検証環境で確認してください。
データエンジニアがやるべきこと
データエンジニアは、移行後のデータ品質とパイプライン影響を確認します。移行元と移行先でデータ型、丸め、NULL、空文字、日付、タイムゾーン、文字コードが変わると、ETLやBIレポートの結果が変わることがあります。SSMAで移行した後に、件数比較だけでなく集計値比較やサンプルレコード比較を行いましょう。
分析リーダーがやるべきこと
分析基盤の責任者は、移行の目的を「DBを移すこと」ではなく「意思決定に使うデータを安定して提供すること」として定義する必要があります。Azure SQL Database、Managed Instance、Synapse Analyticsのどれを使うかは、リアルタイム性、データ量、分析用途、運用コスト、将来の拡張性で判断します。SSMAの評価結果は、移行難易度と投資判断を説明する材料として活用できます。
まとめ: まずSSMAの評価環境を最新前提で作る
2026年4月更新のポイントは、SQL Server Migration Assistantの対象ターゲットが整理され、SQL Server 2025を含む移行評価を進めやすくなったことです。一方で、移行元ごとのSSMAパッケージ、実行環境、プロバイダー、権限、Azure SQLの選定は、プロジェクトごとに確認が必要です。
次に取るべき行動は明確です。まず、移行元DBの種類とバージョンを棚卸しし、対応するSSMAパッケージを確認します。次に、SQL Server 2025、Azure SQL Database、Azure SQL Managed Instanceのどれを候補にするかを決め、検証用環境でSSMAの評価レポートを取得してください。そのレポートをもとに、変換エラー、手修正SQL、性能検証、停止時間、ロールバック計画を具体化すれば、移行プロジェクトは「何となく不安」な状態から「判断できる状態」へ進みます。
コメント