AccScan
技術

Access移行ツールSSMA|SQL Serverへの手順と落とし穴

SSMA(SQL Server Migration Assistant)はMicrosoft公式の無償ツールです。テーブルとデータはSQL Serverへ移行できますが、フォーム・VBA・パラメータクエリは変換されません。移行手順と残る手作業を解説します。

まずは、自社のAccessが「解析できるか」を無料で確認できます。

約2分・ファイル送信不要・発注義務なし

結論:SSMAはテーブルとデータを移すツールで、フォーム・VBAは移行しない

SSMA(SQL Server Migration Assistant)for Accessは、AccessのテーブルとデータをSQL Serverへ移すためのMicrosoft公式ツールです。無償で提供されており、2025年時点で対象となる移行先はSQL Server 2019以降、Azure SQL Database、Azure SQL Managed Instanceです(インストール要件 — Microsoft Learn)。

よく誤解されるのが「SSMAを使えばAccessが丸ごとSQL Serverに移る」という期待です。実際はそうではありません。フォーム、レポート、マクロ、VBAモジュールはSSMAの変換対象外で、これらはAccess側に残ります(変換対象オブジェクト一覧 — Microsoft Learn)。移行後の標準的な構成は、データ(テーブル)だけSQL Serverに移し、フォームやレポートを持つAccessをフロントエンドとして残し、リンクテーブルで接続するというものです。「SQL Serverが入った途端にAccessが要らなくなる」わけではありません。

この記事では、SSMAの具体的な作業手順と、移行後に残る手作業の範囲を整理します。クエリの変換限界など、公式ドキュメントに書かれているがあまり周知されていない点も含めて説明します。

SSMAが変換するものとしないもの

まず変換対象を整理しておきます。Microsoft公式ドキュメントに掲載されている変換結果の対応表から、主要なものを抜粋します。

AccessのオブジェクトSQL Server側の変換結果
テーブル・列・インデックステーブル・列・インデックス(変換される)
主キー・外部キー主キー・外部キー(変換される)
列のデフォルト値・検証ルールデフォルト値・CHECK制約(変換される)
SELECTクエリ(パラメータなし・クロス集計なし)ビュー(多くは変換される)
パラメータ付きクエリ・クロス集計クエリ・UPDATEクエリ等変換されない
フォーム・レポート変換されない
マクロ・VBAモジュール変換されない

特に注意が要るのはクエリです。パラメータなしの単純なSELECTクエリはビューに変換されますが、パラメータ付きクエリ、クロス集計クエリ、更新・削除などのアクションクエリは変換されません。WHERE条件があるだけで変換されなくなるわけではありませんが、Accessで実用しているクエリはパラメータを使っているものが多く、そうしたクエリは変換後に手動で書き直しが必要です。

インストールと移行前の準備

SSMAはMicrosoftのダウンロードページから入手できます。インストール要件はWindows 11以降(またはWindows Server 2022以降)と.NET Framework 4.7.2以降です。古いバージョンのSSMAを使っていた場合は、先にアンインストールしてから新バージョンを入れます。

移行前に、Accessデータベース側でやっておくべき作業があります。Microsoftの移行ガイドでは以下を挙げています。

  1. データベースのバックアップを取る(移行作業の前提として必須)
  2. 全テーブルに主キーを設定する
  3. テーブル間のリレーションシップで使う列のデータ型を揃える
  4. Attachmentフィールドを持つテーブルは事前に対処する(SSMAは変換できない)
  5. 多値フィールドは変換されないので、事前に設計を見直す

バックアップについての詳細はAccess バックアップのベストプラクティスで解説しています。主キーのないテーブルがある場合、移行後のデータ操作(更新・削除)で困ることになるため、事前の整備が必要です。

SSMAでの移行手順(主要ステップ)

SSMAを使った移行は、おおむね次の流れで進みます。公式ドキュメントの推奨手順(Migrate Access Databases to SQL Server and Azure SQL Database)に沿っています。

  1. SSMAを起動し、新規プロジェクトを作成する。移行先(SQL Server・Azure SQL Databaseなど)を選択し、接続情報を設定する。
  2. 移行元のAccess(.accdbまたは.mdb)をプロジェクトに追加する。SSMAがAccessのメタデータを読み込む。
  3. 移行先SQL Serverに接続する。接続後、SQL Serverのメタデータエクスプローラーにデータベース階層が表示される。
  4. 変換レポートを作成する。これで「何が変換できて何が変換できないか」の事前確認ができる。
  5. Accessオブジェクトを選択して「スキーマの変換」を実行する。変換はSSMAプロジェクト内で行われ、この時点ではSQL Serverにはまだ何も作成されない。
  6. 変換後のオブジェクトをSQL Serverにロードする。エラーや警告が出た場合はSQL Server Metadata Explorerで確認・修正する。
  7. データの移行を実行する。AccessからSQL Serverへデータが転送される。
  8. 必要に応じて、AccessのテーブルをSQL Serverのリンクテーブルに切り替える(Access側のフォームやVBAを引き続き使うための接続)。

ステップ5から7(スキーマ変換・ロード・データ移行)は「変換、ロード、移行」ボタンで一括実行できますが、初めて移行する場合は段階を踏んで確認しながら進める方が安全です。

移行後に残る手作業の範囲

SSMAが自動化できる主な範囲はテーブル構造・インデックス・シンプルなSELECTクエリ(ビューとして)・データの移行です。フォームやVBAはその外にあります。移行後に残る手作業を把握しておかないと、「ツールを動かしたのに業務が動かない」という状況になります。

フォームとレポートはAccess側に残り、リンクテーブル経由でSQL Serverのデータを参照します。リンクテーブルへの切り替えはSSMAで支援できますが、既存のフォームやレポートが正しく動くかの検証は人手で行います。VBAの接続文字列や、SQL Server固有の書き方への書き換えが必要になる場面もあります。

クエリについては先述のとおり、変換されないものが出てきます。変換レポートでエラーや警告として表示されたクエリは、SQL ServerのT-SQLで書き直すか、Accessのパラメータクエリとして残すか、ストアドプロシージャに置き換えるか、いずれかの対応が必要です。

また、AccessとSQL Serverを混在させた「ヘテロジニアスクエリ」(AccessのローカルテーブルとSQL Serverのリンクテーブルを同一クエリ内で結合する)は、パフォーマンス上の問題を起こしやすいとMicrosoftの移行ガイドが警告しています。移行完了後は、こうした混在クエリが残っていないかを確認してください。

移行先の選択肢比較(SQL Server以外も含む)はAccess移行先の比較記事も参考にしてください。

SSMAを使うかどうかの判断基準

SSMAは「テーブル数が多く、データ量が大きい」ケースで特に効果があります。当社の経験上、数十テーブル・数十万件のデータを手作業でSQL Serverに移そうとすると工数がかさみます。ツールで自動化できる部分を自動化しておくことで、移行作業の核心部分(クエリやVBAの改修)に人手を集中できます。

一方、フォームやVBAが複雑で、移行後もAccessをフロントエンドとして長期間使い続ける予定がある場合は、SSMAで移行してもフロントエンドの改修コストがかさみます。フロントエンドとしてのAccessは、サポート対象バージョン(Access 2024は2029年10月まで)に更新しながら使い続けることも選択肢に入ります。ただし使っているバージョンのサポートが切れているなら、バージョン更新かフロントエンド自体の見直しが別途必要です(Accessのサポート終了スケジュール)。「とりあえずデータだけSQL Serverに移しておく」という段階的なアプローチの第一歩として使うのが、SSMAの現実的な使い方です。

現在のAccessデータベースがSSMAで移行できる構成かどうか、まず構造を確認したい場合は無料の解析可否チェックで現状を把握するところから始めることができます。ファイルの送信は不要です。

よくある質問

Q. SSMAはいくらで使えますか。

無償です。Microsoftの公式ダウンロードページから入手でき、ライセンス費用はかかりません。ただし移行先となるSQL ServerやAzure SQL Databaseについては、エディションやサービスプランによって費用が発生します。SQL Server Expressは無償で使えるエディションです。

Q. SSMAを使えばAccess 2019のフォームもSQL Serverで動きますか。

動きません。フォーム・レポート・マクロ・VBAモジュールはSSMAの変換対象外で、これらはAccess側に残ります。移行後もフォームはAccessに残り、リンクテーブル経由でSQL Serverのデータを操作する構成が標準です。

Q. SSMAで変換できなかったクエリはどうすればいいですか。

主な選択肢は3つです。SQL Server側でT-SQLのビューまたはストアドプロシージャとして書き直す、Access側のパラメータクエリとしてリンクテーブル経由で引き続き使う、もしくは業務フローを見直してそのクエリ自体が不要になる形に変更する。変換レポートでエラーや警告として出てきたクエリを一覧化し、業務上の優先順位を付けて対処するのが現実的な進め方です。

Q. SSMA以外の移行方法はありますか。

Accessにはかつてアップサイジングウィザードという機能がありました。AccessのテーブルをSQL Serverへ移すためのものでしたが、Access 2013で削除されています(Access 2013の廃止機能 — Microsoft Support)。現在の代替手段はSSMAが主流です。小規模なデータであれば、SSMSのインポートおよびエクスポートウィザードを使ってAccessのデータをSQL Serverへ取り込む手順も取れます。

触れないAccessが「診断できるか」だけ、確かめませんか。

顧客データは送信不要。発注の義務もありません。

約2分・ファイル送信不要・発注義務なし/説明はオンライン・売り込みはしません