概要
| この記事の結論 AccessからSQL Serverへのアップサイジングは、主にテーブルとデータをSQL Serverへ移し、Accessのフォームや帳票からリンクテーブルを通じて利用する方法です。SSMAで事前評価・変換・移行を進め、接続設定、VBAやクエリの確認、業務テストを行ってから本番へ切り替えます。 データの増加や処理の遅さが気になっても、すべての画面を作り直す必要があるとは限りません。本記事では、既存のAccessを活かす構成を前提に、移行を7段階で説明します。移行できる範囲と改修が必要な箇所を整理し、検証から本番運用まで見通せるようにしましょう。 |
この記事でわかること
- アップサイジング後の構成と、SQL Serverへ移すもの
- 移行前に確認する主キー・データ型・外部連携
- SSMAによる評価・変換・データ移行の進め方
- ODBC接続後の動作確認と、更新・性能トラブルへの備え
- 本番切替・切戻しの準備と、専門支援を検討する基準
この記事の主な内容
- アップサイジングとは？Accessの画面を活かしてデータを移す
- 移行前に確認することと7段階の全体像
- SSMAでSQL Serverへ移行する手順
- AccessからSQL Serverへ接続し、動作を確認する
- 移行後に起きやすい問題と改善の考え方
- 移行を相談する判断基準とまとめ
- よくある質問
想定読了時間：約20分～約25分
1. アップサイジングとは？Accessの画面を活かしてデータを移す
Accessのアップサイジングとは、主にデータの保存・管理をSQL Serverへ移し、Accessを操作画面として継続利用できる構成へ変更することです。入力画面や帳票を活かしながら、データを管理する基盤を見直せます。
ただし、移行するだけで処理が必ず速くなるわけではありません。また、画面の見た目が同じでも、裏側のクエリやVBAに修正が必要な場合があります。まずは「何を残し、何を移すのか」を把握することが出発点です。
移行前後の構成はどう変わる？
Accessのデータベースには、データを保存するテーブルと、入力・検索・印刷を行うフォームやレポートなどがあります。これらが一つのファイルに入っている構成もあれば、画面側とデータ側を分けている構成もあります。
画面や処理を担う部分を「フロントエンド」、データを保存する部分を「バックエンド」と呼びます。アップサイジングでは、共有するデータの保存先をAccessのバックエンドからSQL Serverへ変更します。
利用者の端末にはAccessのフロントエンドを配置し、ODBCというデータベース接続の仕組みを通してSQL Serverを利用します。Access側には「リンクテーブル」を作成しますが、実際の業務データを保存する場所はSQL Serverです。
SQL Serverへ移すものとAccessに残すもの
主な移行対象はテーブルとデータです。主キー、インデックス、リレーションに関係する制約なども、変換結果を確認します。一方、フォームやレポート、VBAがそのままSQL Server上で動くようになるわけではありません。
| 資産 | 基本的な扱い | 確認する点 |
|---|---|---|
| テーブル・データ | SQL Serverへ移行 | 型・件数・値・参照関係 |
| 主キー・インデックス・制約 | 変換結果を確認して反映 | 未変換や不整合がないか |
| フォーム・レポート | Access側で継続利用 | 参照先と表示・更新・印刷 |
| VBA・マクロ | Access側で確認・改修 | 採番・更新・外部連携 |
| クエリ | 残す処理と移す処理を選別 | 固有関数・パラメーター・性能 |
クエリは、Access側に残すものと、SQL Server側へ処理を移すものを個別に判断します。画面の値を参照する条件やVBA関数を含む処理は、単純にSQL文を移し替えるだけでは動かないことがあります。
例えば、受注入力画面はAccessに残し、受注テーブルをSQL Serverへ移す構成が考えられます。そのうえで、時間のかかる集計はSQL Server側にまとめる、といった段階的な改修も可能です。この例は構成を説明するためのもので、特定案件の実績ではありません。
2. 移行前に確認することと7段階の全体像
移行作業は、バックアップと資産の棚卸しから始めます。いきなり本番データを変換するのではなく、検証用のコピーと移行先を準備し、問題を解消してから本番移行へ進む流れにしましょう。
この記事では、公式資料の移行操作に事前準備と運用確認を加え、次の7段階に整理しています。各工程には、次へ進めるかを判断するための完了条件を設けます。
| 工程 | 行うこと | 完了の目安 |
|---|---|---|
| 1 | バックアップ・棚卸し | 復旧用データと対象資産が確認できる |
| 2 | 移行先・接続環境の準備 | 検証先への接続と必要権限を確認できる |
| 3 | SSMAプロジェクト・評価 | エラー・警告への対応方針が決まる |
| 4 | 変換・スキーマ反映 | 必要なテーブルと制約が作成される |
| 5 | データ移行・照合 | 件数と重要項目・関係性が一致する |
| 6 | ODBC再リンク | 利用者端末から正しい接続先を参照できる |
| 7 | 業務テスト・本番切替 | 業務確認と切替・復旧準備が完了する |
STEP 1 バックアップを取得し、資産を棚卸しする
まず、利用者の更新を止められる時間を確保し、Accessファイルのバックアップを取得します。分割構成の場合は、フロントエンドとバックエンドの両方が対象です。移行先に既存のSQL Serverデータベースを使う場合は、そちらも保護します。
バックアップは保存しただけで終わらせず、コピーを開けるか、必要なデータやオブジェクトが含まれるかを確かめます。元のファイルと検証用ファイルを明確に分け、検証側から本番データを更新しないよう接続先も確認してください。
棚卸しでは、テーブル一覧だけでなく、そのテーブルを使うフォーム、帳票、クエリ、VBA、CSV入出力まで調べます。月末や年度末にしか使わない処理も、移行後のテスト対象に含める必要があります。
- データの実体があるファイルと、各端末からのリンク先
- テーブルごとの件数、主キー、データ型、リレーション
- クエリ・フォーム・帳票・VBAが参照するテーブル名
- Excel・CSV・他システムとの入出力と、自動実行の時刻
- 利用者、利用時間、権限、現在の処理時間
説明用の受注管理システムなら、「受注入力→納品書印刷→売上CSV出力」を一つの業務として追います。画面が開くだけでは、最後のCSV出力まで動くことは確認できません。業務のまとまりで記録すると、テスト漏れを減らせます。
主キーとデータ型を先に確認する
主キーは、各レコードを一意に識別する項目です。SQL Serverへ移した後、Accessからデータを更新するには、対象行を識別できるキーが重要になります。更新対象のテーブルに主キーや適切な一意インデックスがあるか確認します。
主キーがない場合でも、根拠なく既存列を主キーに指定してはいけません。重複やNullを調べ、業務上の識別方法を決めてから整備します。親テーブルと子テーブルの関係がある場合は、参照先が存在しないデータも洗い出しましょう。
| 対象 | 確認すること |
|---|---|
| 文字・商品コード | 文字数、日本語、先頭ゼロ、空文字とNullを確認する |
| 数値・金額 | 桁数・小数桁・丸め・合計値への影響を確認する |
| オートナンバー | 既存キーの保持と、移行後の新規採番を確認する |
| Yes/No | 移行先bit列のNull許可、既定値と既存値を確認する |
| 日付・時刻 | 選択する日付型の範囲と精度、Accessとの互換性を確認する |
| 添付・OLEオブジェクト | 抽出・保存方式と、画面での表示・登録方法を検討する |
| 複数値・ルックアップ | 実データと表示の仕組みを分け、必要なら関連テーブルへ設計し直す |
特に添付ファイル型や複数値フィールドは、同じ操作性のまま自動移行できると考えないことが重要です。添付を外部ファイルとして管理するか、別の保存方法を使うかによって、画面側の変更内容も変わります。移行前に保存方式と利用方法を決めます。
STEP 2 移行先と接続環境を準備する
移行先のSQL Serverには、サーバー名、インスタンス名、データベース名、認証方法、接続経路を用意します。サーバーの管理者と、どの端末から接続できるようにするか、移行作業に必要な権限は何かを確認してください。
SQL Server Management Studioなどの管理ツールは、SQL Serverを管理するためのものです。管理ツールをインストールしただけで、データを保存するSQL Server本体が用意されたことにはなりません。接続先となるデータベースが利用できる状態か確認します。
あわせて、SSMA for Accessを実行する環境と、Accessから接続する端末のドライバを確認します。SSMAの対応版、Accessや関連プロバイダーのbit数、利用するODBCドライバの組み合わせは、採用するバージョンの要件に従います。
Windowsが64bitでもAccessが32bitの場合があります。端末側のODBC設定はAccessのbit数に合わせて確認し、移行用の作業環境と、一般利用者が使う実行環境を混同しないようにしましょう。
移行作業用の権限を、そのまま全利用者へ配布する運用は避けます。また、接続エラーが出た場合は、サーバー名、通信経路、認証、証明書を順に確認します。暗号化や証明書検証を無効にすることを、通常の解決策にはしません。
3. SSMAでSQL Serverへ移行する手順
SSMA for Accessは、Microsoftが提供する移行支援ツールです。Accessデータベースを評価し、変換したオブジェクトを移行先へ反映したうえで、データを移す作業を支援します。
ここでは、評価・変換・データ移行を分けて説明します。画面の表示名や対応環境は採用版により異なるため、実際の操作では、その版のヘルプと変換結果を確認しながら進めてください。
STEP 3 プロジェクトを作成して事前評価する
最初にSSMAで新しいプロジェクトを作成し、移行先の種類・バージョンを指定します。次に、検証用に用意したAccessデータベースを追加します。分割済みの場合は、どのファイルに実テーブルがあるのかを確認して対象を選びます。
SQL Serverへ接続したら、移行元と移行先のデータベース・スキーマの対応を確認します。スキーマとは、SQL Server内でテーブルなどを分類・管理する枠組みです。例としてdboがありますが、既存環境では管理方針に合わせてください。
続いて対象のオブジェクトについて評価レポートを作成し、変換できない項目や警告を確認します。「すべて成功したか」だけでなく、どのテーブル・列・クエリに、どのような影響があるのかを読み取ることが大切です。
- 変換エラーがある対象と、その原因を記録する
- 警告がデータ・制約・処理へ与える影響を判断する
- データ型や移行対象を見直し、再評価する
- 自動変換できない処理の改修方法を決める
評価レポートは、移行方針を検討する材料です。エラーがなくても、フォームの動作、帳票の数値、CSVの出力形式まで保証されるわけではありません。業務テストは別工程として残します。
STEP 4 オブジェクトを変換し、スキーマを反映する
評価結果を整理したら、対象をSQL Server向けに変換します。ここでの「変換」は、主にAccessの定義をSQL Server向けの定義へ置き換える作業です。変換が完了しても、それだけで移行先へすべてのテーブルやデータが作成されるわけではありません。
変換後は、列の型・桁数・Nullの許可、主キー、インデックス、外部キーなどを確認します。自動的に割り当てられた型が、業務にとって適切とは限らないため、コードの先頭ゼロ、金額の小数桁、日時の範囲などにも目を通します。
確認できた定義をSQL Serverへ反映します。SSMAの同期・読み込み操作などを使う際は、変更対象を確認してから実行します。既存のテーブルがあるデータベースでは、同名オブジェクトへの影響を把握せずに進めないでください。
反映後は、移行先でテーブルと制約が意図した状態になっていることを確認します。「テーブルは作成できたが外部キーは作成されていない」といった状態を残すと、後からデータの不整合を招く可能性があります。
STEP 5 データを移行し、結果を照合する
移行先の構造を準備したら、SSMAで対象データを移行します。処理が終わったら、移行結果とエラーを確認し、必要な行が取り込まれているかを調べます。再実行が必要な場合は、移行済みデータの扱いを確認してから行ってください。
検証のために何度か試す場合は、同じ初期状態からやり直せる手順を用意すると比較しやすくなります。前回のデータが残った状態で別条件の移行を行うと、今回の結果なのか、以前の残りなのか判断できなくなるためです。
照合はテーブルごとの件数から始め、主キーの欠落・重複、金額の合計、日付の範囲、Nullの数などへ進めます。件数が一致していても、値の変化や参照関係の問題がないとは限りません。
また、比較する時点をそろえることも必要です。移行元で更新が続いていれば、移行後の件数と比較しても一致しないことがあります。同じ時点のコピー、または更新停止後のデータを使って照合しましょう。
例えば、説明用の受注テーブルなら、総件数だけでなく月別の件数・受注金額、代表的な受注番号の明細も確認します。さらに、備考の日本語、空文字とNull、キャンセル済みのフラグなど、業務で使う値を確認すると実用的です。
4. AccessからSQL Serverへ接続し、動作を確認する
データ移行後は、AccessがSQL Serverのテーブルを使うようにリンクを設定します。その後、入力から帳票・外部連携までの業務動作を確認します。SSMAでデータが移せた時点を、システム移行の完了にはしないことが重要です。
STEP 6 ODBCで再リンクし、テーブル名を確認する
リンク方法には、SSMAのリンク機能を使う方法と、AccessからODBCのリンクテーブルを作成する方法があります。SSMAのリンク機能は移行元のAccessファイルを変更するため、バックアップした検証用コピーを対象にします。
Access側で作成する場合は、外部データの取り込み機能からODBCデータベースを選び、「リンクテーブルを作成する」方法で接続先と対象テーブルを指定します。「インポート」を選ぶとAccess内にデータをコピーするため、継続してSQL Serverを使う構成とは異なります。
すでにSQL Serverへのリンクがある場合は、リンクテーブルマネージャーなどで接続先を確認・更新します。新規リンク作成なのか既存リンクの変更なのかを区別し、検証用と本番用の接続先を取り違えないようにしてください。
リンク名には、dboなどのスキーマ名に由来する接頭辞が付く場合があります。既存クエリやフォームが「受注」を参照しているのに、リンク名が別名になれば影響が出ます。Access上のリンク名とSQL Server上の実テーブル名を分けて確認しましょう。
DSNという接続設定名を使う場合は、必要な設定を利用端末へそろえます。設定方式にかかわらず、Accessのbit数、ドライバ、接続先、認証、権限を確認し、開発端末だけでなく実際の利用者端末で接続テストを行います。
なお、リンク後にAccess側へ残っている旧テーブルのデータは、SQL Serverの更新と自動的に同期されるものではありません。バックアップ用と現行用を明確に分け、旧データを誤って更新する運用を防ぎます。
STEP 7 業務テストで移行前後を比較する
テストでは、画面が開くかだけでなく、同じ入力に対して同じ業務結果になるかを確認します。利用者の通常権限で操作し、移行前後の画面表示、帳票、出力ファイル、所要時間を比較しましょう。
| 確認対象 | 主な操作・比較項目 | 合格の考え方 |
|---|---|---|
| データ | 件数、キー、金額、日付、Null、親子関係 | 差異がない、または承認した変換結果と一致 |
| 入力・更新 | 新規登録、修正、削除、採番、入力エラー | 通常権限で期待する結果になり、不整合が残らない |
| 帳票・集計 | 納品書、月次集計、印刷・PDF | 条件・合計・明細・表示が業務要件と一致 |
| 外部連携 | Excel・CSV出力と取込、自動実行 | 列順・文字コード・形式・連携結果が一致 |
| 同時利用 | 別レコードと同一レコードの編集 | データ整合が保たれ、競合時の案内が適切 |
| 性能 | 検索、保存、集計、一覧表示 | 合意した応答時間を満たし、著しい悪化がない |
正常な操作に加え、入力漏れ、重複登録、存在しないコードなども試します。エラー時に処理が途中まで進むと、ヘッダーだけ登録されて明細がない、といった不整合が起きる場合があるためです。
同時利用のテストでは、複数人が別のレコードを編集する場合と、同じレコードを編集する場合を分けます。競合のメッセージや再読込の案内が、利用者にとって理解できるかも確認してください。
性能は、同じデータ量・抽出条件・端末・通信経路で測定します。検索開始から一覧表示、更新ボタンから保存完了など、計測の始点と終点をそろえます。速い処理だけで判断せず、日常業務の代表的な処理を比較しましょう。
本番切替と切戻しを準備する
テストで問題を解消したら、本番の更新停止時間を決めます。利用者の手入力だけでなく、CSV取込、夜間バッチ、外部システムの自動更新も停止対象に含めます。停止漏れがあると、最終移行後に旧側へ新しいデータが追加されるおそれがあります。
一般的な切替の流れは、「更新停止→最終バックアップ→最終データ移行→照合→接続先切替→業務確認→利用再開」です。実際の工程と所要時間は、検証時の結果に基づいて決めます。
移行後に重大な問題が出た場合に備え、切戻しを判断する人、判断時刻、復旧の手順も用意します。特に、利用再開後にSQL Server側へ登録・更新・削除されたデータをどう扱うかは、事前に決めておく必要があります。
古いAccessバックアップへ戻すだけでは、切替後に行われた更新を保持できません。切替後更新分の抽出・再反映が必要な場合は、その方法まで検証します。データの整合を保てないまま、新旧両方のシステムを自由に更新させないようにしてください。
運用引継ぎでは、SQL Serverのバックアップ・復元、障害通知、権限変更、フロントエンドの配布・更新を担当者へ引き継ぎます。Accessファイルをコピーする従来のバックアップだけでは、SQL Server内のデータを保護できなくなります。
使い慣れたAccessを活かした移行を検討している方へ
移行範囲が見えない場合は、既存テーブルだけでなく、クエリ・VBA・外部連携も含めて確認すると、必要な改修と検証を整理できます。Accessの継続利用を含めたSQL Server移行についてご相談いただけますので下記よりお気軽にご連絡ください。
5. 移行後に起きやすい問題と改善の考え方
移行後のトラブルは、「接続できない」「接続できるが更新できない」「動くが結果や速度が違う」に分けると調べやすくなります。症状だけで設定を変え続けず、どの操作・どのテーブル・どの端末で起きるかを記録して切り分けます。
更新できない・競合する場合はキーと権限から確認する
一覧を表示できるのに保存できない場合は、まず利用者に更新権限があるか、Accessが対象行の一意キーを認識しているかを確認します。主キーがあるテーブルでも、クエリに必要なキー列が含まれていないと更新できない場合があります。
集計・結合などを含むクエリやフォームでは、そのデータ構成自体が更新可能かを調べます。SQL Serverのテーブルを直接リンクした状態では更新できるかを確認すると、テーブル側と画面・クエリ側の問題を分けやすくなります。
また、SQL Server側で定義を変更した場合は、Access側のリンク情報の更新が必要になることがあります。古い列情報のままで動かしていないかを確認しましょう。
rowversionは、行の変更を識別するためにSQL Serverが自動的に更新する値です。Accessとの連携で変更検出を扱いやすくするために検討されますが、主キーの代わりでも、登録日時を保存する列でもありません。追加だけですべての更新競合が直るとは考えず、原因に応じて判断します。
データ型やVBAの違いによる不具合を確認する
同じような名前のデータ型でも、扱える範囲やNullの扱い、Access側から見える値が異なることがあります。型変換の問題が疑われる場合は、エラーになった行だけでなく、同じ列を使う検索・集計・入力処理も確認します。
Yes/Noの列なら、移行後のbit列にNullを許すか、既存データをどう扱うかを確認します。日付なら、移行先に選ぶ型の範囲と精度を確認します。datetimeの制約を、datetime2など別の型にも共通する制約として判断してはいけません。
VBAについては、レコードの追加後に採番値を読み取るタイミングや、DAOでレコードセットを開く際のオプションなどに注意が必要です。SQL ServerのIDENTITY列を扱う処理では、dbSeeChangesが関係するケースもあります。
ただし、原因を確認せずにVBA全体を書き換える必要はありません。どのSQL文やレコード操作で失敗するかを特定し、入力チェック・画面制御はAccess、まとめて行うデータ処理はSQL Server、と役割を整理して修正します。
遅くなる場合は取得件数と処理の場所を見直す
SQL Serverへ移しても、Access側で大量のデータを受け取って処理すれば、通信時間が増える場合があります。特に、全件を表示するフォームや、1件ずつ更新するVBA処理は、移行前と異なる待ち時間が生じることがあります。
まず、画面を開いたときに必要なデータだけを取得するようにします。受注一覧なら、対象期間や担当者などを指定してから表示する方法です。不要な列を減らし、検索に使う条件とインデックスの設計も合わせて確認します。
集計や大量更新は、SQL Server側のビュー、ストアドプロシージャ、パススルークエリなどの利用を検討します。パススルークエリはSQLをサーバーへ直接渡す方法ですが、返された結果を通常のリンクテーブルと同じように編集できるとは限りません。
読み取り用の帳票と、入力・更新用のフォームでは求められる動作が違います。すべてのクエリを一律に置き換えるのではなく、遅い処理を測定し、結果・更新可否・保守性まで確かめながら改善しましょう。
6. 移行を相談する判断基準
アップサイジングは、Accessを残したままデータ基盤を見直す選択肢です。実施できるかは、データ量だけでなく、既存処理の複雑さや業務停止の制約、運用体制を含めて判断します。
自社対応と専門支援の境界
対象が小さく、依存する処理が少なく、検証環境と復旧手順を準備できる場合は、自社で事前評価から始められます。その場合も、データ移行の成功と業務運用の成功は分けて判断してください。
一方、次の条件がある場合は、操作を始める前に移行計画を相談すると、後から見つかる改修や停止時間の見落としを減らせます。
- 業務停止できる時間が短く、失敗時の復旧が難しい
- クエリ・VBA・帳票が多く、影響範囲を把握できていない
- 添付ファイルや複数値など、保存方法の見直しが必要
- CSV・Excel・外部システムの自動連携がある
- 認証・権限・バックアップを含む運用担当を決めたい
まとめ
AccessからSQL Serverへのアップサイジングは、既存の画面を活かしながら、データの保存・管理を見直す方法です。バックアップと棚卸しから始め、SSMAによる評価・変換・データ移行、ODBC接続、業務検証の順に進めます。
移行後は、データが一致するだけでなく、必要な操作ができ、適切な時間で処理が終わり、障害時に復旧できることが大切です。本番切替と切戻しまで準備することで、移行後の運用を見据えた計画になります。
既存Accessのテーブル・クエリ・VBA・外部連携を踏まえた移行のご相談を承ります。現在の構成と課題を整理し、Accessの継続利用、必要な改修、検証・本番切替を含めて検討したい方はお問い合わせください。
よくある質問
継続利用できる構成にできます。ただし、リンク名、データ型、クエリの更新可否などの影響で改修が必要な場合があります。入力・検索・帳票・出力まで、実際の業務手順で確認してください。
必ず速くなるわけではありません。取得するデータ量、クエリやVBAの設計、ネットワーク、サーバーの構成に左右されます。移行前後を同じ条件で測定し、遅い処理の実行場所や取得条件を見直します。
すべては自動移行できません。SSMAで変換できるクエリには制約があり、VBAはSQL Server上でそのまま実行されません。Access側に残す処理とSQL Server向けに改修する処理を分けます。
移行先の候補になります。ただし、採用するSSMAの対応版に加え、各製品の容量・機能・運用上の制約を確認してください。Azure SQLでは通信経路や認証なども含めて設計します。この記事の操作を、すべての環境へ無条件に当てはめることはできません。
テーブル数だけでは決まりません。データの整備、クエリ・VBAの改修、外部連携、業務テスト、停止可能な時間、移行後の運用範囲を整理して見積もります。まず棚卸しと事前評価を行うと、見積もりの前提をそろえやすくなります。
参考情報
Microsoft Support｜Migrate an Access database to SQL Server
Microsoft Learn｜SQL Server Migration Assistant for Access
Microsoft Learn｜Link Access applications to SQL Server and Azure SQL
Microsoft Learn｜Prepare Access databases for migration
Microsoft Learn｜Incompatible Access features
Microsoft Learn｜Connect to SQL Server
Microsoft Learn｜Migrate Access databases to SQL Server and Azure SQL
Microsoft Learn｜Migrate Access data into SQL Server and Azure SQL