概要
| この記事の結論 AccessからSQL Serverへ移行する際は、データ型・キーの互換性、クエリやVBAの動作、ODBC接続、移行後の照合、本番切替と切戻しを確認します。テーブルの移行成功だけでは業務の動作は保証されません。Accessの画面を残す場合も、テスト環境で登録・更新・集計・帳票を確認してから切り替えます。 本記事では、移行前に調べる項目と、移行後に確かめる業務結果を順番に整理します。移行の操作手順は関連記事「AccessからSQL Serverへアップサイジングする方法」で扱い、ここでは失敗を防ぐための判断に重点を置きます。 |
この記事でわかること
- 移行対象と既存アプリの依存関係を整理する方法
- データ型・主キー・採番で見落としやすい点
- クエリ・VBA・ODBC接続の確認ポイント
- データ照合と業務テストの合格条件
- 本番切替・切戻し・保守を準備する考え方
この記事の主な内容
- 移行前にAccessの構成と影響範囲を確認する
- データ型・主キー・制約の違いに注意する
- クエリ・フォーム・VBAがそのまま動くとは限らない
- ODBC接続・権限・性能を利用環境で確認する
- 移行後はデータと業務処理を照合する
- 本番切替・切戻し・運用保守を準備する
- よくある質問
- まとめと移行相談
想定読了時間：約14分～約17分
1. 移行前にAccessの構成と影響範囲を確認する
最初に決めるのは、どのデータを移し、どの画面や処理を残すかです。AccessのSQL Server移行とは、Accessで管理していたデータをSQL Serverへ移し、必要に応じて既存のAccess画面から接続して使うことです。
確認すべき領域は、①移行範囲、②データとキー、③アプリと接続、④照合と業務テスト、⑤切替と運用の5つに分けると整理しやすくなります。この5分類は、本記事で確認漏れを減らすために用いる実務上の整理です。
画面を残してデータを移す範囲を決める
Accessの画面側をフロントエンド、データを保存する側をバックエンドと呼びます。バックエンドだけをSQL Serverへ移し、リンクテーブルを通じて既存の画面から利用する構成が可能です。リンクテーブルとは、別の場所にあるテーブルへ接続するためのAccess上の窓口です。
ただし、画面を残すことと、画面の修正が不要なことは同じではありません。フォームの参照先、検索条件、保存ボタンの処理などが、新しい接続先でも成立するかを確かめます。端末内の作業用テーブルを残す場合は、共有すべきデータが混ざっていないかも確認します。
テーブル・クエリ・VBA・帳票・外部連携を棚卸しする
対象はテーブル一覧だけでは足りません。業務で使う画面からたどり、参照するクエリ、VBA、帳票、CSV入出力、Excel連携などを記録します。月次処理や年次処理は日常の操作確認から漏れやすいため、利用頻度の低い業務も担当者へ確認してください。
| 対象 | 調べる依存先 | 確認する内容 |
|---|---|---|
| テーブル | 主キー・外部キー・他テーブル | 用途、更新元、データ量、移行対象 |
| クエリ・フォーム | リンクテーブル・フォーム参照 | 検索条件、編集可否、保存時の処理 |
| VBA・マクロ | DAO・ADO・外部ファイル | 接続先、SQL文字列、エラー処理 |
| 帳票・CSV・Excel | 出力元クエリ・ファイル仕様 | 集計条件、列順、桁数、文字コード |
| 運用処理 | バックアップ・バッチ・配布先 | 実行時刻、担当者、失敗時の対応 |
例えば、受注テーブルを移した後に受注入力だけを試験しても、請求書の集計や出荷CSVの不具合は見つからない場合があります。このような想定例を使い、ひとつのデータがどの業務まで流れるかを確認します。
バックアップとSSMA評価レポートで問題を洗い出す
Microsoft SQL Server Migration Assistant for Access（SSMA）は、移行対象の評価、変換、データ移行などを支援するツールです。まず本番とは分離したコピーを用意し、評価レポートから変換できない対象や警告を確認します。評価・変換・転送・リンク接続は、別の確認段階として扱います。
フォーム・レポート・マクロ・VBAは、SSMAでSQL Server用アプリへ自動変換されません。そのため、評価結果が良好でも、業務テストは別途必要です。作業前のバックアップにはデータだけでなく、開発用ACCDB、関連ファイル、接続設定の記録も含めます。
2. データ型・主キー・制約の違いに注意する
移行時は「転送できたか」に加え、値の意味と更新ルールが保たれているかを確認します。SSMAの型マッピングは、変換元と変換先のデータ型を対応付ける設定です。テーブル単位の設定が上位設定を上書きする場合もあるため、最終的に生成される列定義まで確認します。
文字列・数値・日付・NULLの意味を合わせる
データ型の名称だけで対応を決めると、桁数、精度、日付範囲などの差を見落とします。例えば、過去日付を格納している列では、変換先をSQL Serverのdatetimeにしたときの範囲を確認します。datetimeは1753年より前の日付を扱えないため、データ内容と変換先型の組合せが重要です。
NULLは値が存在しない状態を表します。空文字や数値の0とは区別し、未入力の扱い、必須入力、既定値を確かめます。見た目が空欄でも、抽出や集計の結果が変わることがあるため、実際に使う検索条件で比較してください。
| 確認対象 | 見落としやすい点 | 確認方法 |
|---|---|---|
| 文字列 | 最大長、日本語、空文字、比較規則 | 長い名称や似たコードで検索・照合 |
| 数値・金額 | 小数桁、丸め、上限・下限 | 端数や負数を含む金額を比較 |
| 日付・時刻 | 格納範囲、時刻の有無、精度 | 古い日付と月末・日付境界を確認 |
| NULL・既定値 | 未入力と空文字・0の違い | 未入力での登録と検索を試験 |
文字の比較規則である照合順序も確認項目です。業務コードの大文字・小文字などを区別する必要がある場合は、同一とみなす範囲を先に決めます。移行後にコードの重複や検索漏れがないかを、代表データだけでなく問題になりそうな組合せでも調べます。
添付ファイル・複数値などは代替設計を検討する
Accessの添付ファイル型や複数値フィールドは、通常の文字列列と同じ感覚で移せません。Microsoftの移行ガイドでは、添付列を含むテーブルはSSMAで移行されない対象として説明されています。使用する版での評価結果を確認し、データを退避する前に列を削除しないでください。
添付ファイルは、ファイルを取り出して保管し、元レコードとの対応を残す方法などを検討します。複数値は、親レコードと選択値を対応付ける別テーブルへ整理する方法が候補です。どちらも保存先だけでなく、画面からの登録・表示・削除とバックアップを一緒に設計します。
なお、「SQL Serverでは画像を扱えない」という意味ではありません。Access固有の保存形式と、移行先の保存・表示方法の違いを整理する必要があります。OLEオブジェクトを使っている場合も、中身とアプリの表示方法を調査してから方針を決めます。
主キー・外部キー・採番・rowversionを確認する
更新するリンクテーブルでは、対象の1行を一意に特定できることが重要です。SQL Server側にテーブルを作成できても、Accessから更新できるとは限りません。主キーや一意なインデックスがあるかを確認し、重複・NULL・外部キーの不整合を試験移行で洗い出します。
オートナンバーの移行では、既存番号の保持と、移行後の新規採番を別々に確かめます。親子データの対応が変わっていないか、新規登録が既存番号と衝突しないかを確認してください。連番に欠番がないことを業務要件としている場合は、技術的な行識別番号と業務番号を分けて検討します。
rowversionは、行の変更を検出するために使う値です。更新に応じて値が変わるため、日時を保存する列でも、固定の主キーでもありません。Accessからの更新判定に使う設計を検討する際は、列追加後のリンク情報と編集動作まで確認します。追加だけであらゆる競合が解決するとは考えないでください。
3. クエリ・フォーム・VBAがそのまま動くとは限らない
アプリの確認では、処理をどこで実行するかを整理します。Accessに残すクエリと、SQL Serverへ送るSQLでは、使える構文や参照先が異なります。移行に合わせてすべてを書き換えるのではなく、更新可否と処理量を見ながら改修対象を決めます。
Access側で実行する処理とSQL Server側へ移す処理を分ける
フォーム操作や入力チェックはAccess側に残し、大量データの抽出や集計をSQL Server側へ寄せる構成が候補です。ただし、Accessクエリを使ったからといって、処理がすべて端末で行われるとは限りません。実際に転送されるデータ量と実行状況を確認して判断します。
SQL ServerへSQLを直接送るパススルークエリを使う場合は、SQL Server側の構文で記述します。検索結果を表示する用途と、フォーム上で編集する用途を分け、通常の編集用リンクテーブルと同じ動作を前提にしないことが大切です。
関数・フォーム参照・SQL構文の違いを確認する
確認候補には、Access固有の関数、フォーム上のコントロール参照、日付の記述、文字列の連結、パラメーターの渡し方などがあります。Access側で評価する式を、そのままSQL Serverへ送っても同じ意味で実行できるとは限りません。
例えば、フォームで入力した期間を使う集計では、画面から値を受け取り、型を決めて検索条件へ渡す必要があります。SQL文字列の一括置換は避け、実行場所を決めてから修正します。通常の値に加え、未入力、引用符を含む名称、日付境界も試験してください。
更新可否と採番後の処理、トランザクションを試験する
VBAでデータを操作する場合は、DAOやADOなどの接続方法と、レコードの開き方を確認します。Microsoftは、IDENTITY列を持つSQL Serverテーブルへ所定のDAO／ODBC経路でOpenRecordsetを使う場合、dbSeeChangesの指定に注意するよう案内しています。すべてのVBAへ一律追加する対応ではありません。
新規登録後に採番された番号を取得し、その番号で明細を登録する処理は重点確認の対象です。受注ヘッダーだけが保存され、明細が失敗したときにどうなるかを確かめます。一連の処理をまとめて確定・取消するトランザクションの範囲を、実際の接続と処理単位に合わせて設計します。
また、入力エラー後の再実行で二重登録されないかも確認します。エラー表示が出るだけでなく、どの処理まで完了したかを利用者が判断できることが必要です。フォームが開くかという確認から、登録の前後でデータがどう変わるかという確認へ進めましょう。
4. ODBC接続・権限・性能を利用環境で確認する
移行担当者のPCで接続できても、利用者全員が使えるとは限りません。ODBCは、Accessなどのアプリからデータベースへ接続するための仕組みです。ドライバー、接続先、認証、ネットワークを、配布対象の環境で確かめます。
Accessのbit数とODBCドライバー、接続先をそろえる
WindowsとAccessの32bit／64bitは別に確認します。接続に使うODBCドライバーはAccessのbit数に合わせ、ドライバー名や版、DSNを利用するかどうかを記録します。DSNは接続先などを登録する設定名です。DSNを使わない接続でも、必要なドライバーの配布は省略できません。
さらに、データベース名やスキーマ、リンクテーブル名が、既存の参照と合っているかを確認します。端末ごとにフロントエンドを配布する場合は、版の管理と再リンクの方法を用意します。Runtimeで利用する端末についても、実際の起動から入力・出力まで試験してください。
認証・最小権限・暗号化と証明書を確認する
移行作業用の管理権限と、日常利用者の権限は分けます。通常業務に必要な読取・更新などの権限でテストし、管理者でしか動かない処理を残さないようにします。認証情報を配布ファイルへ安易に埋め込む運用も見直す対象です。
ODBC Driver 18以降は、接続の暗号化が既定で有効です。旧ドライバーから切り替えると、証明書の信頼や接続先名の不一致によって接続エラーになる場合があります。証明書、信頼チェーン、接続先名を確認し、暗号化の無効化を標準的な解決策にしないでください。
TrustServerCertificateによる検証省略も、証明書を正しく検証する設定と同等ではありません。検証環境の一時対応と本番設定を分け、接続できたことだけで確認を終えないようにします。
本番相当の通信・データ量で速度を測る
性能は、移行先のサーバー性能だけでは決まりません。利用拠点からの通信、検索時の取得件数、処理を繰り返す回数などを含めて確認します。少量データを使った管理者PCのテストだけでは、実際の業務速度を評価できません。
確認時は、データ量、検索条件、利用場所、同時利用状況を記録し、同じ条件で旧環境と比較します。画面の初回表示、条件検索、登録、月次集計などを分けて測ると、改善対象を特定しやすくなります。必要な応答時間は業務担当者と合意し、測定前に合格基準を決めます。
想定例として、検索画面で大量の行を取り込んでから絞り込む設計では、通信待ちが長くなることがあります。対象期間や必要な列を絞るなど、データの受け渡し方を見直します。速度改善の詳しい考え方は「AccessからSQL Serverへ移行すると速くなるのか」を参照してください。
Accessを残したSQL Server移行の確認範囲を整理しませんか
既存のテーブル・画面・VBA・外部連携の関係が分からない場合は、移行前の調査から始めると改修範囲を整理できます。現在の構成と困っている業務をお知らせください。移行対象や必要な確認項目を整理するところからご相談いただけます。
5. 移行後はデータと業務処理を照合する
移行後は、データの一致と、業務処理の正しさを別々に確認します。件数が一致していても、金額や参照先が違っていれば業務には使えません。ここからの確認方法は、受入テストを組み立てるための実務上の推奨です。
件数・キー・合計値・境界値を照合する
まず、比較対象の時点をそろえます。移行元で入力が続いている状態と、移行先の転送済みデータを比べると、正常な更新も差分として現れます。更新停止したデータや、同じ時点の検証用コピーを用いて比較してください。
件数に加え、主キーの欠落・重複、親子の対応、金額の合計、日付の最小・最大、NULLや長い文字列を確認します。意図的な変換がある場合は、単純一致ではなく承認済みの変換ルールに合っているかで判断します。説明できない差分が残ったまま本番へ進めないことが重要です。
登録・更新・削除・帳票・CSVを確認する
データ照合の後は、普段の業務シナリオを実行します。入力画面の項目だけでなく、保存結果、再表示、取消、帳票、後続システムへ渡すファイルまで確認します。旧画面と同じ操作ができるかに加えて、最終的な業務結果が正しいかを判定します。
| テスト項目 | 期待結果の例 | 残す証跡 |
|---|---|---|
| 移行データ | キー・件数・合計値が一致する | 照合結果と差分の説明 |
| 新規登録・明細登録 | 採番と親子の対応が正しい | 入力内容と登録後の値 |
| 更新・取消・削除 | 対象行だけが設計どおり変わる | 処理前後の比較 |
| 帳票・CSV | 金額・列順・日付が仕様に合う | 旧新の出力と比較結果 |
| 検索・月次集計 | 結果と処理時間が合格基準内 | 条件・件数・測定時間 |
| 異常時の再実行 | 欠落や二重登録が起きない | エラー時点と復旧結果 |
同時更新・エラー・権限別の動作を確認する
複数利用者が同じ行を更新する場面では、競合の検知と利用者への案内を確認します。上書きや再読込の扱いを決め、古い画面の値を無条件に保存する動作がないかを試験してください。競合メッセージが出ること自体が、必ずしも不具合とは限りません。
通信中断、権限不足、不正な入力なども確認します。閲覧専用の利用者が更新できないことと、更新担当者が必要な処理を実行できることを両方確かめます。各項目に担当者と期待結果を付け、業務担当者が確認した結果を本番移行の判断材料にします。
6. 本番切替・切戻し・運用保守を準備する
本番切替の手順は、テスト移行の前に作り始めます。停止できる時間、最終データの移行方法、再開の判断者を決めておくと、リハーサルで所要時間や不足作業を確認できます。
更新停止から最終移行・再開までの順番を決める
基本となる流れは、更新停止、バックアップ、最終移行、照合、接続切替、業務確認、再開です。利用者へ停止時間を周知し、画面入力だけでなくバッチやCSV取込など、データを更新する経路も止めます。
最終移行では、全件を移し直すか、差分を反映するかを事前に決めます。差分方式は追加だけでなく更新・削除も扱う必要があるため、記録方法と反映手順を検証してください。試験時と同じ方法で所要時間を測り、照合や判断の時間も停止枠へ含めます。
接続切替後は、承認されたフロントエンドを配布し、必要な端末で業務確認を行います。旧版のショートカットや自動処理が旧データを更新し続けないよう、利用経路を整理してから再開します。旧環境と新環境への二重入力は、原則として避けます。
切戻し条件と切替後の更新データの扱いを決める
切戻しとは、不具合などで新環境の利用を中止し、旧環境へ戻すことです。重要業務が実行できない、説明できないデータ差分がある、停止枠を超える見込みがあるなど、判断条件と判断期限を先に決めます。判断を現場の個人に任せず、責任者を定めてください。
新環境で入力を再開する前であれば、旧環境を維持したまま接続を戻せる場合があります。一方、再開後は新しく登録・更新・削除されたデータがあるため、バックアップを戻すだけではその内容を失うおそれがあります。
そのため、再開後に戻す可能性があるなら、変更の回収方法、旧環境への反映方法、二重登録を防ぐ照合、再開の判断まで決めます。回収できる仕組みがない場合は、「すぐ戻せる」と見込まず、再開前の確認を厚くするなど切替計画を見直します。
バックアップ・復元試験・監視・担当者を決める
バックアップの取得成功だけでなく、必要なデータを復元できるかを確認します。保存先、保持期間、復元先、復元できる時点、許容する業務停止時間を決め、テスト環境で復元手順を試します。SQL Serverのデータと、Accessの開発原本・配布物は、それぞれ保管対象として管理します。
移行先が自社管理のSQL Serverか、Azure SQL Databaseなどのサービスかによって、保守作業の分担は異なります。バックアップ、監視、更新、費用、障害連絡の担当を決めてください。サービスを利用する場合も、復元操作や業務確認を誰が行うかは決めておく必要があります。
以下の表は、本番前に使うチェックリストのひな形です。担当者名と未確認事項を記入し、未完了の重要項目がある場合は、再開可否を判断する責任者へ共有します。
| 確認項目 | 完了条件 | 担当・状況記入欄 |
|---|---|---|
| 移行対象と改修 | 依存関係と対象範囲を確認済み | 担当： 未確認事項： |
| データと業務テスト | 差分の説明と重要業務の合格を確認 | 担当： 未確認事項： |
| 端末配布と接続 | 対象端末で認証・操作を確認済み | 担当： 未確認事項： |
| 切替手順 | 更新停止・最終移行・再開を試行済み | 担当： 未確認事項： |
| 切戻し | 条件・責任者・更新データの扱いが明確 | 担当： 未確認事項： |
| 保守体制 | 復元手順・監視・連絡先を確認済み | 担当： 未確認事項： |
7. よくある質問
修正不要とは限りません。フォームやVBAはSSMAで自動変換されないため、既存の参照先、保存処理、外部連携が移行後も成立するかを試験します。画面を再利用しながら、影響のある部分を改修する考え方が基本です。
一意な行識別、クエリの更新可否、利用者権限、リンク情報などを確認します。まずテーブル単位の編集と、フォーム経由の編集を分けて試すと、データ側と画面側のどちらを調べるべきか整理できます。主キーだけを追加して解決したと判断せず、実際の業務操作まで確認してください。
通常の列型と同じ扱いで移せるとは考えないでください。SSMAの対象可否を確認し、ファイルの外部保管や関連テーブルへの分割などを検討します。元データを保全したうえで、画面から使えることと、元レコードとの対応が保たれることを確認します。
必ず速くなるとは限りません。通信量や検索条件、処理の実行場所などに左右されるため、本番相当のデータ量と接続条件で測定します。遅い業務を特定し、その処理の取得件数や通信回数を調べて改善します。
切替後の更新状況によります。新環境で入力したデータがある場合、接続だけを戻すと内容が失われたり、旧新で不整合が生じたりします。切戻し条件と、変更データの回収・反映方法をあらかじめ決めておく必要があります。
8. まとめと移行相談
AccessからSQL Serverへの移行では、データ型や主キーの確認に加え、アプリの動作と運用の準備が必要です。移行対象を棚卸しし、テスト環境でデータと業務結果を照合したうえで、本番の更新停止から再開までを確認してください。
確認範囲が明確で、検証環境と担当者を用意できる場合は、自社で試験を進められます。一方、複雑なVBAや外部連携がある、停止時間が限られる、切戻し方法を決められない場合は、計画段階から調査を依頼すると判断材料をそろえやすくなります。
既存Accessの保守・改修やSQL Serverへの移行に関するご相談を承っています。
現在の構成、利用人数、問題が起きる操作、希望する停止時間などをお知らせください。
Accessを継続利用する範囲と、移行・改修を検討する範囲を整理するところからご相談いただけます。
参考情報
[1] Microsoft Support｜Migrate an Access database to SQL Server
https://support.microsoft.com/en-us/access/migrate-an-access-database-to-sql-server
[2] Microsoft Learn｜Incompatible Access features
https://learn.microsoft.com/en-us/sql/ssma/access/incompatible-access-features-accesstosql?view=sql-server-ver17
[3] Microsoft Learn｜Migrate Access databases to SQL Server and Azure SQL
https://learn.microsoft.com/en-us/sql/ssma/access/migrating-access-databases-to-sql-server-azure-sql-db-accesstosql?view=sql-server-ver17
[4] Microsoft Learn｜Edit Type Mapping
https://learn.microsoft.com/en-us/sql/ssma/access/edit-type-mapping-accesstosql?view=sql-server-ver17
[5] Microsoft Learn｜Connection encryption troubleshooting
https://learn.microsoft.com/en-us/sql/connect/odbc/connection-troubleshooting?view=sql-server-ver17
[6] Microsoft Learn｜rowversion Transact-SQL
https://learn.microsoft.com/en-us/sql/t-sql/data-types/rowversion-transact-sql?view=sql-server-ver17
[7] Microsoft Learn｜Database.OpenRecordset method DAO
https://learn.microsoft.com/en-us/office/client-developer/access/desktop-database-reference/database-openrecordset-method-dao