古いAccessシステムを移行する方法｜移行先の選び方と注意点

概要

この記事でわかること

• 自社に合う移行方法と残せる機能
• 開発原本・データ・利用環境の調べ方
• MDBと32bit／64bitで注意すること
• 検証から本番切替までの進め方
• 費用・期間の確認項目と相談の目安

この記事の主な内容

1. 古いAccessシステムを移行する3つの方法
2. 移行前に開発原本・データ・利用環境を調べる
3. 古いAccess特有の互換性を確認する
4. 検証から本番切替まで5段階で進める
5. 移行費用と期間を左右する5つの条件
6. 移行後も保守できる状態で引き継ぐ
7. よくある質問

想定読了時間：約18分

1 古いAccessシステムを移行する3つの方法

古いAccessシステムの移行とは、既存業務のデータと必要な機能を確認し、利用環境やデータの保存先、画面・処理を新しい構成へ引き継ぐことです。PC更改への対応なのか、データ管理の改善なのか、ブラウザーで使いたいのかを整理すると、移行方法を選びやすくなります。

現行Accessへ移して画面や帳票を活用する

今の業務や操作方法を大きく変えず、PCやAccessの環境を更新したい場合の選択肢です。既存の画面・帳票・VBAを活用できれば、利用者が操作を覚え直す負担を抑えられます。ただし、古い形式や外部部品への依存があると、変換や改修が必要になります。

例えば、新しいPCで請求書の印刷ボタンだけが動かない場合、原因はAccess本体とは限りません。参照ライブラリ、プリンター設定、出力先のフォルダーなどを調べ、必要な変更を絞ります。古いという理由だけで、全面的な作り直しを決める必要はありません。

Accessを残してデータをSQL Serverなどへ移す

画面や帳票を使い続けながら、データの保存先をSQL ServerやAzure SQL Databaseへ移す構成もあります。画面・帳票・処理を担う側を「フロントエンド」、データを保存する側を「バックエンド」と呼びます。この方法では、主にバックエンドを変更します。［S03］

データ量の増加や共有・権限管理が課題なら、検討する価値があります。一方、移行するだけで必ず速くなるわけではありません。データの取り方や通信条件も影響するため、代表的な検索・集計・更新を実際の利用条件で比較します。画面やVBAの調整が必要になる場合もあります。

関連記事：Access＋SQL Server構成の役割と仕組み

Web・Power Apps・業務SaaSなどへ再構築する

ブラウザーやスマートフォンから使いたい場合、業務の流れ自体を変えたい場合は、画面と処理の再構築を検討します。業務SaaSはサービス側の標準機能に合わせる方式、独自Web開発は必要な機能を設計する方式です。Power Appsも、要件に合わせた画面や処理の設計が必要です。

移行先では、帳票、承認、外部連携、権限、費用を確認します。Accessの画面やVBAがそのまま別製品へ移ると考えず、機能ごとに引継ぎ方法を決めてください。なお、データだけをクラウドDBへ移すことと、ブラウザーで動くアプリへ変えることは別です。

移行方法の比較

2 移行前に開発原本・データ・利用環境を調べる

最初の作業は、使っているファイルと動作条件の棚卸しです。画面を開くファイルだけでは、実データや必要な部品がそろわないことがあります。どのPCから、どのデータへ接続しているかを確認してから、移行対象を決めます。

MDB・ACCDBとMDE・ACCDEの原本を探す

MDBやACCDBはAccessのデータベース形式です。MDEやACCDEは配布に使われる形式で、通常の操作ではVBAやフォーム・レポートの設計を修正できません。ACCDEでは作成時に編集可能なVBAソースが取り除かれるため、修正には元のACCDBを保管しておくことが重要です。［S04］

原本が見つからない場合は、旧PC、共有フォルダー、バックアップ、納品物を順に探します。見つからなければ、現行システムの操作と帳票を記録し、取得可能なデータと再構築が必要な機能を調査します。拡張子を書き換えても、失われたソースや編集可能な設計は戻りません。

Accessの製品名・Build・bit数と外部部品を記録する

旧PCと移行先PCの両方で、Windows、Accessの製品名・Build・32bit／64bit、製品版かRuntimeかを記録します。Windowsが64bitでも、Accessは32bitという構成があります。見た目が似ていても動作条件は異なるため、Officeのbit数を別に確認してください。

あわせて、VBAの参照設定、ActiveX・OCX・DLLなどの外部部品を確認します。これらはカレンダー表示、通信、ファイル処理などを補う部品です。Accessファイルに含まれないものもあるため、配布元、バージョン、再導入方法を記録しておきます。

リンク先と日次・月次の業務を棚卸しする

リンクテーブルは、別ファイルやサーバー上のテーブルをAccessから利用する仕組みです。画面側のファイルを移しても、リンク先に接続できなければ業務は動きません。データの保存先に加え、Excel・CSVの入出力先、共有フォルダー、実行用アカウントの権限も調べます。

業務の確認では、毎日使う処理だけでなく、月末締め、取消、再発行、年次更新を含めます。担当者に操作を見せてもらい、入力する情報と最終的な帳票・ファイルを記録すると、仕様書がなくても検証の手掛かりになります。使っていない機能も区別しましょう。

移行前の棚卸し項目

3 古いAccess特有の互換性を確認する

互換性は「ファイル形式」と「実行環境」に分けて確認します。MDBをACCDBへ変換できても、外部部品やVBAが新環境で動くとは限りません。また、現行環境でファイルを開けることと、正しい業務結果が得られることも別に検証します。

Access 97などのMDBは変換経路を分ける

MDBは、拡張子が同じでも内部の形式が異なります。Microsoftは、Access 97形式をAccess 2013以降で直接ACCDBへ変換できないと説明しています。必要に応じて、対応する旧バージョンで中間形式へ変換してから、次の環境へ引き継ぎます。［S01］

旧バージョンを使う変換作業は、本番ファイルを保全したコピーで行います。利用可能な正規環境とライセンスを確認し、サポートが終了した環境は変換用の管理された環境として扱ってください。変換できた後も、画面・帳票・処理を確認する必要があります。

また、ACCDBはMDBのレプリケーションや旧ユーザーレベルセキュリティをサポートしません。該当する機能を使っている場合は、共有や権限の仕組みを見直します。すべてのMDBを無条件にACCDBへ変換するのではなく、利用機能と移行先の要件から判断します。［S01］

関連記事：mdbとaccdbの違いと変換時の注意点

32bitから64bitへの変更はVBAと外部部品を確認する

64bit版Accessへ移す場合、Windowsの機能を呼び出すVBAのAPI宣言を点検します。PtrSafeを加えるだけで完了とは限らず、メモリー位置やウィンドウを表すポインター・ハンドルを適切な型で扱う必要があります。Longを一括でLongPtrへ置き換える方法も適切ではありません。［S02］

外部部品の対応も別に確認します。32bitのActiveX部品は、そのまま64bit版Officeへ読み込めません。提供元の対応版を調べ、入手できなければ別の部品や処理へ置き換えます。環境のbit数だけを変えて解決できると判断しないことが大切です。［S02］

MDE・ACCDEも、作成した環境と実行先のbit数を確認します。64bit版Accessへ変更する場合は、編集可能な原本を対応させて再コンパイルし、配布先で検証するのが基本です。配布用ファイルしかない状態で、bit数の変更を先に進めないようにしましょう。［S09］

参照設定・ODBC・Runtime・信頼設定をそろえる

VBAの参照先が見つからない場合は、何の処理で使っているかを確認します。不足した参照を外すだけでは、該当機能が動かなくなる場合があります。また、外部DBへつなぐODBCは、Accessから利用できるドライバーと接続先・認証情報をそろえ、読み込みと更新を試します。

Access Runtimeは、Accessアプリを実行するための環境です。Runtimeで運用するなら、起動フォームから必要な操作を完了できるか、エラー後に操作へ戻れるかも確認します。コードがブロックされた場合は、ファイルの入手元と管理方針を確認し、保護を一律に解除する対応は避けます。［S10］

なお、Access 2016／2019は、2026年9月の確認時点でサポートを終了しています。動作していることだけで継続の判断をせず、移行先のサポート状況も確認しましょう。これはAccessという製品全体の提供終了を意味するものではありません。［S06・S07］

原本や外部部品が分からないときは

旧PCでは動いていても、原本や必要な部品が分からない場合は、移行作業に入る前の調査が役立ちます。既存Accessの構成を確認し、改修で引き継げる範囲と再構築が必要な範囲の整理をご相談いただけます。

4 検証から本番切替まで5段階で進める

移行作業は、本番と切り離した環境で試し、データと業務結果を照合してから切り替えます。次の5段階は、確認漏れを防ぐための進め方です。移行先や停止できる時間に合わせて、担当者と完了条件を具体化してください。

1 バックアップと検証用コピーを用意する

画面側のファイルだけでなく、実データ、外部ファイル、接続設定を含めて保全します。ファイル型の共有DBでは利用者を終了させるなど、整合した状態を確保してからバックアップします。SQL Serverなどの外部DBは、そのDBに適したバックアップ手段を使います。

保存しただけで安心せず、検証環境へ戻して開けるかを確認します。テスト用Accessが本番データへリンクしたままだと、試した更新が本番に反映されます。コピー後はリンク先を検証用へ変更し、メール送信や外部システムへの書込みも停止・分離してから試します。

2 移行方針を決めて変換・改修する

棚卸しした機能を「残す」「変更する」「廃止する」に分け、移行後の構成を決めます。現行Accessへ移す場合は形式や互換性を調整し、Web等へ移す場合は画面・処理・データの対応を設計します。複数の変更を行うときは、変更点を記録して原因を追えるようにします。

SQL Serverへデータを移す場合は、Microsoftの移行支援ツールSSMAなどで評価します。ただし、フォーム・レポート・マクロ・VBAはSSMAで変換されません。残すAccess側の動作確認も必要です。操作手順は次の関連記事で確認できます。［S03］

関連記事：AccessからSQL Serverへアップサイジングする方法

関連記事：AccessとSQL ServerをODBC接続する方法

3 データと業務処理を照合する

同じ条件のデータを使って旧環境と新環境を比較します。件数が合っていても、コードの先頭ゼロ、金額、日付、空欄などが変わっている可能性があります。登録・更新・削除に加え、取消や締め処理を含めて、業務担当者が結果を確認できる形にします。

業務テストと照合の例

移行対象に説明できない差異が残っている場合は、本番切替を進めません。不要データの削除など、意図した違いがある場合は対象と理由を記録します。性能も、実際のデータ量・ネットワーク・利用者数に近い条件で測り、業務上の許容時間を満たすか確認してください。

関連記事：SQL Server移行前後の注意点と確認項目

4 更新を止めて最終データを移し切り替える

本番切替では、誰がいつ旧環境の更新を止め、最終データを移し、照合して再開を判断するかを決めます。日中に試験用データを移しただけでは、その後の入力が反映されません。停止時間を短くするため差分を移す場合も、差分の特定方法と重複・漏れの防止を設計します。

切替後は接続先、配布ファイル、ショートカットをそろえます。旧新の両方へ入力されないよう、旧環境の利用制限や周知も必要です。最終照合が終わらない、主要な帳票が出ないなどの中止条件と、切戻しを判断する責任者・時刻を事前に決めておきましょう。

5 稼働確認を行い保守へ引き継ぐ

稼働後は、起動だけでなく、入力・更新・帳票・外部連携を確認します。日次処理が正常でも月次処理が未確認なら、初回の締めまで確認を続けます。問い合わせ窓口と障害の記録方法を決め、利用者が問題を報告できる状態にしておきます。

不具合で旧環境へ戻すときは、新環境で入力されたデータを先に保全します。例えば、切替後に受注を20件登録したなら、旧データへ戻すだけではその20件が失われます。これは説明用の例ですが、追加だけでなく更新・削除・外部送信の履歴も切戻し時の確認対象です。

切戻しは、更新を止める、新環境のデータを保全する、旧環境へ反映する差分を決める、照合して再開する順に進めます。差分反映は事前に検証し、安全に戻せない場合は業務を止めた状態で復旧方法を判断します。旧ファイルの保管と、更新データの整合確認をセットで準備してください。

5 移行費用と期間を左右する5つの条件

費用や期間は、Accessの古さだけでは決まりません。原本の有無、必要な機能、連携、データ、停止条件によって調査と改修の量が変わります。見積りを比較するときは、移行先の製品名だけでなく、含まれる作業と完了条件をそろえましょう。

原本と仕様書の有無

編集できる原本と仕様書があれば、現状を把握しやすくなります。一方、配布用ファイルしかない、処理の意味を知る人がいない場合は、探索・操作確認・業務ヒアリングから始めます。最初の調査と、その結果を踏まえた改修・再構築を分けると、見積りの前提を確認できます。

使い続ける画面・帳票・処理の量

ファイルの数が少なくても、複雑な締め処理や多数の帳票があれば作業量は増えます。画面数だけで判断せず、入力チェック、例外処理、帳票の種類を確認してください。使わなくなった機能を整理すると、移行後のテストや保守の対象も絞れます。

外部部品と他システム連携の数

外部部品の置換や、他システムとの接続変更には、別の担当者との調整が必要になる場合があります。CSV連携でも、文字コード、列の順序、ファイル名、受渡し時刻が業務上の約束になっていることがあります。連携先のテスト日程も含めて計画します。

データの不整合と移行量

重複したコード、関連先が存在しないデータ、値の表記ゆれは、移行前に扱いを決めます。自動的に削除・修正すると業務上の意味が変わるため、必要なデータと整理方法を業務担当者が確認します。移行量は、データ転送だけでなく照合・バックアップの時間にも影響します。

停止可能時間と業務テストの範囲

停止できる時間が短いほど、事前移行、差分反映、切替リハーサルなどの準備が重要になります。また、月次・年次の処理は、確認用の条件や担当者の予定をそろえる必要があります。通常時の入力だけを試す見積りと、締め処理まで検証する見積りを同じ条件で比較しないようにします。

見積り前に整理する情報

見積書では、調査、改修・再構築、テスト・切替、ライセンス、移行後の保守を分けて確認します。担当者への操作説明や復旧手順の引継ぎも範囲に含むかを確認すると、導入後に必要な作業が残るのを防ぎやすくなります。

6 移行後も保守できる状態で引き継ぐ

移行の完了条件には、業務が動くことに加え、次の担当者が改修・復旧できることを含めます。開発原本、配布版、データ、設定、運用手順をそろえ、PC更改や障害時に必要な情報を探せる状態で引き継ぎましょう。

開発原本・配布版・データを分けて管理する

開発原本には版番号と変更内容を記録し、利用者へ渡すファイルや実データと区別します。ACCDEを配布する場合も、元のACCDBを保管します。複数人で使う構成では、どの画面ファイルがどのデータへ接続するかも管理対象です。

共有方法も確認してください。Microsoftは、OneDriveやSharePointのドキュメントライブラリからAccessデータベースを直接開くことを避けるよう案内しています。保存・同期できることだけを根拠に複数人利用を始めず、ネットワークやDBの構成に合った共有方式を選びます。［S05］

構成と復旧手順を後任へ残す

最低限、原本とデータの保存先、対応する実行環境、接続設定、バックアップ・復元手順、配布方法を残します。認証情報は組織の管理方法に従い、一般の操作説明書へ平文で書き込まないようにします。設定の変更日と変更者も追えるようにしておきましょう。

復旧手順は、担当者が読めば実行できる具体性が必要です。どのバックアップを選び、どこへ戻し、何を確認して再開するかを記載します。利用者の異動や部品の更新があったときに、構成表を更新する担当者も決めてください。

自社で対応する範囲と専門家へ相談する範囲を決める

原本と構成が分かり、バックアップから復元でき、検証環境と業務確認担当を確保できる場合は、自社で進められる範囲を検討できます。まず検証用コピーで代表的な処理を試し、変更点と結果を残しながら進めることが基本です。

原本がない、旧部品の代替が分からない、連携や締め処理の仕様が不明な場合は、現状調査を先に行います。停止時間が厳しい移行や、SQL・Webへの構成変更も設計が重要です。最初の棚卸し表を埋め、不明点と残したい業務を整理することから始めてください。

よくある質問（FAQ）

古いAccessの移行方針を相談したい方へ

古いAccessの移行では、原本やデータの保存先、外部部品の状況によって必要な対応が変わります。既存システムを調査し、Accessを活用する改修からデータベース移行・再構築まで、業務に合う進め方をご相談いただけます。

お問い合わせの際は、分かる範囲の利用環境、困っている操作、残したい機能、停止できる時間をお知らせください。原本や仕様書の所在が不明な場合も、その状況を含めてご相談いただけます。

参考情報

S01　Microsoft　ACCDB形式への変換
S02　Microsoft　Office 32／64bit互換性
S03　Microsoft　AccessからSQL Serverへの移行
S04　Microsoft　Hide VBA code from users
S05　Microsoft　Ways to share an Access desktop database
S06　Microsoft　Access 2016 ライフサイクル
S07　Microsoft　Access 2019 ライフサイクル
S08　Google　Search Central 更新情報
S09　Microsoft　64bit版と32bit版のOfficeの選択
S10　Microsoft　Accessアプリケーションの展開