概要
| この記事の結論 Accessマイグレーションとは、Accessで使っているデータや業務機能を、新しい環境へ移すことです。画面をAccessのまま残してデータをSQL Serverへ移す方法もあり、全面的な作り直しが必要とは限りません。まずは実行環境、データ、画面や処理を分けて、何を残し、何を移すかを整理しましょう。 この記事では、移行方法の違い、引き継げる資産、費用・期間を左右する要因、調査から本番切替までの流れを解説します。現在のAccessを使い続けるか、別の仕組みに移すかを検討している業務担当者・情報システム担当者向けの内容です。 |
この記事でわかること
- マイグレーションとアップサイジング・Web化の関係
- 業務の課題に合う移行範囲と移行先の選び方
- データ・フォーム・帳票・VBAを引き継ぐときの注意点
- 費用・期間の見積もりに必要な情報
- 業務停止やデータ不整合を防ぐ進め方
この記事の主な内容
- Accessマイグレーションとは？移行する対象と用語の違い
- Accessマイグレーションを検討するきっかけ
- Accessを残す？移行方法と移行先を比較する
- 移行できる資産と、作り替え・調整が必要な資産
- 費用・期間は何で変わる？見積もり前の確認項目
- Accessマイグレーションの進め方と失敗を防ぐポイント
- よくある質問（FAQ）
- まとめ 自社に必要な移行範囲を先に決める
想定読了時間：約16分～約20分
1. Accessマイグレーションとは？移行する対象と用語の違い
Accessマイグレーションは、既存のAccessシステムのデータや業務機能を、新しい実行環境・データ基盤・アプリケーションへ移す取り組みです。特定の製品への変換だけを指す言葉ではなく、移行先と対象範囲によって作業内容が変わります。
実行環境・データ・画面や処理の3層で整理する
最初に、現在のAccessを次の3層に分けて考えます。これは移行範囲を整理するための分類です。「パソコンを更新したい」のか、「データの管理方法を変えたい」のか、「ブラウザから業務を行いたい」のかによって、手を加える場所が異なります。
- 実行環境：Windows、Office／Access、ドライバー、外部部品など
- データ：テーブル、主キー、データ型、テーブル間の関係など
- 画面や処理：入力フォーム、帳票、クエリ、VBA、外部システムとの連携など
例えば、使い慣れた入力画面を残し、データだけをSQL Serverへ移す構成があります。一方、スマートフォンやブラウザで入力したい場合は、画面や操作方法の設計も必要です。この区別が曖昧なままでは、見積もりに含まれる作業や、移行後にできることを比較できません。
アップサイジング・Web化・リプレースとの関係
マイグレーションに関連する言葉は、必ずしも互いに排他的ではありません。本記事では、次のように使い分けます。依頼先によって呼び方が異なることもあるため、提案書では言葉の定義だけでなく、変更対象と納品物まで確認してください。
表1 移行に関する用語の関係
| 用語 | 本記事での意味 | Accessでの例 |
|---|---|---|
| マイグレーション | データや業務機能を新しい環境へ移す取り組み | 環境更新、DB移行、別アプリへの移植 |
| アップサイジング | 主にデータ基盤をサーバーDBへ移す方法 | 画面はAccess、データはSQL Server |
| Web化 | ブラウザから使う画面や処理を構築すること | 受注入力をWeb画面に作り替える |
| リプレース | 既存の仕組みを別の仕組みに置き換えること | Access業務をSaaSへ置き換える |
例えば、AccessからWebシステムへ移す計画では、マイグレーションとWeb化の両方を行います。既存機能をどこまで維持するか、新しい業務に合わせて何を変更するかを決めると、必要な作業が明確になります。
2. Accessマイグレーションを検討するきっかけ
移行を検討する目安は、現在の仕組みで業務上の要件を満たせなくなったときです。ファイルが古い、利用者が増えたといった状況だけで決めず、困っている症状と、その原因を分けて調べましょう。
PC更新・互換性・保守担当者の不在
パソコンやOfficeの更新で、以前のAccessが動かなくなることがあります。確認するのはAccessの製品名・バージョンに加え、Officeの32bit／64bit、VBAが呼び出す外部部品、データ接続用のドライバーです。WindowsとOfficeのbit数は別々に確認します。
特に、Windowsの機能を呼び出すVBAのDeclare文は、64bit Officeへの対応が必要な場合があります。PtrSafeを付けるだけでなく、ポインターやハンドルを保持する型も確認します。互換性の修正で対応できるなら、画面を全面的に作り直す必要はありません。[5]
また、作成者の退職で改修方法が分からなくなった場合は、開発原本、仕様書、外部ファイルの所在を調べることが先です。新しい製品に移しても、仕様や運用担当者が不明なままでは保守の問題が残ります。
データ増加・同時利用・拠点や端末の拡張
データ量の増加で集計が遅くなった、同時更新で業務が止まる、別拠点から利用しにくいといった問題は、データ基盤を見直すきっかけになります。ただし、人数や件数だけで移行の要否を判断することはできません。処理内容、更新頻度、回線条件によって負荷が異なるためです。
例えば、集計が遅い原因が不要な全件読込みにあるなら、データベースを移すだけでは改善しないことがあります。外出先からの入力が目的なら、データ基盤に加えて画面や認証の仕組みも検討します。
改修・運用改善で対応できるかを先に確認する
まずは、どの操作で困るか、いつ発生するか、誰が使うかを記録しましょう。そのうえで、クエリ、データの配置、通信、バックアップ、更新手順を確認します。原因が限定されていれば、現在のAccessを改修して対応する方法もあります。
移行は、その調査結果と今後の要件を踏まえて選びます。「遅いからWeb化」「担当者がいないから別製品」と決める前に、現状改善で解決できる範囲と、新しい仕組みが必要な範囲を分けることが大切です。
3. Accessを残す？移行方法と移行先を比較する
移行先は、残したい機能と利用方法から選びます。ここでは代表的な選択肢を4つに整理します。一度にすべてを移す必要はなく、データ基盤を先に整え、その後に必要な画面を作り替える進め方もあります。
Accessを継続して実行環境を更新する
現在の画面・帳票で業務が成り立ち、課題がPCやOfficeとの互換性にある場合は、Accessを継続する方法が候補です。VBAや外部部品の修正、接続設定の変更、配布方法の見直しを行い、新しい環境で動作を確認します。
ただし、環境更新だけでは、分かりにくい処理や未整理の業務ルールまで解消しません。修正箇所とテスト結果を記録し、次の担当者が保守できる状態にすることも作業に含めましょう。
SQL Server／Azure SQL Databaseへデータを移す
Accessの画面や帳票を活用したい場合は、データをSQL ServerやAzure SQL Databaseへ移す構成を検討できます。画面・帳票など利用者側の部分を「フロントエンド」、データを保存・管理する側を「バックエンド」と呼びます。[6]
この構成では、Accessからサーバー側のデータへ接続します。ただし、接続先を変更するだけで完成するとは限りません。クエリや更新処理の調整、通信条件に合わせた読込み方法の見直しが必要です。Access側の配布・更新管理も引き続き行います。
Azure SQL Databaseを使う場合も、Accessの画面が自動的にブラウザ用になるわけではありません。データのクラウド化とWeb化は分けて判断します。
Dataverseを基盤にPower Appsを検討する
Microsoft Power Platformを活用したい場合は、Dataverseをデータ基盤として検討できます。MicrosoftはAccessデータの移行方法を案内しており、移行後もAccessのデスクトップ画面からデータを扱う選択肢があります。[4]
一方、Power Appsで利用する画面は別に設計します。データを移しただけで、既存フォーム・帳票・VBAがそのまま新しいアプリになるわけではありません。移行できるデータ型、権限、利用者のライセンス、運用体制を確認し、必要な機能を実現できるか検証します。
Webアプリや業務SaaSへ移行する
ブラウザ利用、社外の利用者との連携、複数端末への対応が必要なら、Webアプリの構築が候補になります。画面に加え、ログイン、権限、帳票、外部連携、障害対応などを設計します。Accessに組み込まれた業務ルールを洗い出す作業も必要です。
既存の業務SaaSを使う場合は、標準機能に業務を合わせられるかを確認します。特に、例外的な処理、過去データの取込み、帳票の再現、将来のデータ出力を確認しましょう。独自機能を再現する費用と、業務を変える負担の両方を比較します。
表2 代表的な4つの移行方法
| 方法 | 向く要件 | 残せる資産と主な改修 | 運用上の確認 |
|---|---|---|---|
| Accessの環境更新 | 既存操作を継続したい | 画面・帳票・処理を活用し互換性を修正 | PC環境と配布・更新 |
| SQL Server等へDB移行 | 画面を残しデータ管理を見直したい | Accessを活用し接続・クエリ等を調整 | DB管理、通信、Access配布 |
| Dataverse＋Power Apps | Power Platformで業務を拡張したい | データを移し新しい画面・処理を設計 | 権限、ライセンス、環境管理 |
| Webアプリ／SaaS | ブラウザ利用や業務刷新が必要 | データ・業務ルールを引き継ぎ画面等を再構築 | 認証、保守、業務適合性 |
移行範囲を決めるための現状調査からご相談いただけます。Accessを継続する方法も含め、業務に合った進め方を整理します。
4. 移行できる資産と、作り替え・調整が必要な資産
移行のしやすさは、資産の種類と移行先によって変わります。データを移せることと、今までと同じ業務ができることは別々に確認しましょう。まず「残す・移す・作り替える」の一覧を作ると、調査や見積もりの抜けを減らせます。
テーブル・データ型・クエリの互換性
テーブルは、データを入れる箱だけでなく、項目の型や関連付けも含めて確認します。主キーは行を一意に識別する項目です。主キーの重複や欠落、未入力を表すNull、日付や小数の扱いなどを調べ、移行後の検索・集計・更新に影響しないか確かめます。
クエリは、参照先や使用する関数によって調整が必要です。Access側で継続実行するのか、サーバー側へ処理を移すのかを決めます。画面の入力値を参照する処理や、独自のVBA関数を呼ぶ処理は、依存関係まで確認してください。
フォーム・帳票・VBA・外部連携の引継ぎ
フォームの見た目が単純でも、ボタンの裏に入力チェック、計算、メール送信、Excel出力などが組み込まれていることがあります。画面数だけを数えると、こうした処理を見落とします。通常操作に加え、取消し、締め処理、訂正などの例外操作も調べましょう。
Accessを残す場合も、データの保存先が変われば、接続や更新方法の調整が必要になることがあります。また、別アプリへ移す場合は、帳票の改ページやプリンター依存、外部ファイルの保存先まで再現するかを決めます。利用者が手作業で補っている工程も確認対象です。
SSMAで自動変換される範囲と対象外
SQL Server Migration Assistant for Access（SSMA）は、AccessのデータベースをSQL Serverなどへ移行するためのMicrosoftのツールです。Microsoftの変換対象表では、テーブルなどに加え、多くのSELECTクエリをビューへ変換できるとされています。[2]
ただし、更新クエリ、パラメーターを使うSELECTクエリ、クロス集計クエリなどは、そのままの変換対象になりません。フォーム、レポート、マクロ、モジュールも変換されません。対象外だから業務を廃止するという意味ではなく、継続利用・修正・再実装の方法を判断します。[2]
表3 SQL Serverへ移す場合の資産の扱い
| 資産 | SSMAによる扱い | 業務としての確認 |
|---|---|---|
| テーブル・データ | 定義変換とデータ移行の対象 | 型、主キー、件数、内容の整合 |
| クエリ | 変換できる種類に制約がある | Accessで継続するか、移植するか |
| フォーム | 変換対象外 | 継続利用時の接続・更新動作 |
| レポート | 変換対象外 | 集計値、レイアウト、印刷結果 |
| VBA・マクロ | モジュール・マクロは変換対象外 | 外部連携、例外処理、再実装範囲 |
ツールの変換完了は、移行作業の途中です。スキーマと呼ばれるデータ構造の変換、サーバーへの作成、データ移行、その後の動作確認を区別し、警告や未変換の項目を確認します。[1][2]
5. 費用・期間は何で変わる？見積もり前の確認項目
Accessマイグレーションの費用・期間は、移行範囲と既存資産の状態によって変わります。ファイル容量や画面数だけでは判断できません。同じ画面数でも、外部連携や例外処理が多いシステムでは、調査・修正・検証の作業が増えます。
機能数だけでなく依存関係・例外処理を調べる
見積もりを依頼する前に、開発原本の有無、実際に使っている機能、外部システムとのつながりを整理しましょう。正確な仕様書がなくても、業務の流れ、画面の一覧、使用している帳票、困っている操作をまとめると調査を進めやすくなります。
表4 見積もり前に整理する項目
| 確認項目 | 調べる内容 | 費用・期間への影響 |
|---|---|---|
| 資産 | 開発原本、仕様書、使用中の機能 | 不明な箇所を調査する作業量 |
| 依存関係 | VBA、外部部品、Excel・CSV・API連携 | 修正・置換と連携テストの範囲 |
| 移行範囲 | 残す画面、移すデータ、廃止する機能 | 再利用と新規開発の割合 |
| テスト | 締め処理、帳票、同時更新、例外操作 | 準備するデータと確認作業量 |
| 切替条件 | 停止時間、差分反映、切戻し、教育 | リハーサルと本番対応の負担 |
移行開発費とライセンス・運用費を分ける
初期費用には、調査、設計、改修、データ移行、テスト、教育などが含まれます。一方、運用開始後には、サーバーやクラウドの利用料、ライセンス、バックアップ、監視、保守などの費用が発生します。比較するときは、対象期間と含まれる作業をそろえてください。
例えば、画面を再利用できても、接続変更やクエリ調整が必要なら改修費は発生します。SaaSも、月額料金だけでなく、データ整備や業務変更の作業を含めて評価します。移行すれば必ず費用が下がるとは限りません。
停止可能時間・テスト範囲・移行後の保守を決める
業務を止められる時間が短い場合は、事前移行や差分反映の設計が必要になることがあります。差分反映とは、試験・事前移行の後に増えたデータや変更されたデータを、本番切替時に反映することです。削除されたデータの扱いも決めておきます。
また、月末や年度末にしか使わない機能も検証対象です。利用部門の確認時間や、運用担当者への引継ぎを計画に含めましょう。開発作業の日数だけでなく、業務として受け入れられるまでの期間を見積もる必要があります。
6. Accessマイグレーションの進め方と失敗を防ぐポイント
移行は、小さな範囲で確かめながら進めると、問題を早く発見できます。ここでは業務上の作業を5段階で整理します。各段階で確認する対象と、次へ進める条件を決めておくことがポイントです。
棚卸し・要件整理と移行方針の決定
第1段階は、現行資産と業務要件の調査です。ファイルや機能を一覧化し、利用者・拠点、困っていること、将来必要な機能を整理します。本番とは別に検証用コピーを用意し、移行元・移行先のバックアップも準備します。[3]
第2段階では、移行範囲と方針を決めます。データの保存先、残す画面、作り替える処理、認証・権限、バックアップ、切替手順を設計します。使わなくなった機能を整理する場合は、利用部門に確認し、残す履歴や参照方法も決めておきます。
小規模検証・試験移行と業務結果の照合
第3段階では、代表的なデータと機能で試験移行します。単純な画面だけでなく、複雑な帳票や外部連携を含めると、手間のかかる部分を早く把握できます。問題を修正した後は、修正箇所に関係する操作も再確認します。
第4段階は、実際の業務手順に沿った検証です。データ件数が一致しても、別の顧客に紐づいていたり、金額が丸められていたりすれば正常な移行とはいえません。件数に加え、主キー、重要項目、金額集計、主要帳票、登録・訂正・取消しの結果を照合します。
許容できる差がある場合は、その理由と許容範囲を事前に定義します。処理速度も、同じデータ量・操作・通信条件で比較しましょう。誰が業務上の合格を判断するかを決め、結果を記録します。
本番切替・切戻し・運用引継ぎ
第5段階は、本番切替と運用引継ぎです。切替直前の更新を止め、最終データを反映し、照合してから新環境での入力を開始します。旧環境を参照用として残す場合も、どちらが正しい更新先なのかを利用者へ周知します。
切戻しは、問題が起きたときに旧環境へ戻すことです。旧ファイルのバックアップがあるだけでは十分ではありません。新環境で入力が始まった後に戻すと、その間の更新が旧環境に含まれていないためです。
そこで、切戻しの判断者・期限・条件とともに、切替後の追加・変更・削除データをどう回収し、照合して反映するかを決めます。旧・新の両方を無計画に更新する運用は避けてください。切戻し手順もリハーサルで確認します。
最後に、操作方法、配布・更新手順、バックアップからの復元方法、障害時の連絡先を引き継ぎます。移行完了の判断には、データと機能の確認に加えて、保守を続けられる体制が整っていることも含めましょう。
よくある質問（FAQ）
いいえ。画面や帳票をAccessに残し、データをSQL Serverなどへ移す方法もあります。環境更新で継続できる場合もあるため、まず移行したい理由と、変更が必要な範囲を整理してください。
本記事では、マイグレーションを移行全体の呼び方とし、アップサイジングを主にAccessのデータ基盤をSQL Serverなどへ移す選択肢として説明しています。関係各所との打合せでは、画面や帳票の改修まで含まれるかを確認しましょう。
SSMAでは、フォーム、レポート、マクロ、モジュールは変換されません。Accessで使い続けるか、移行先で再実装するかを評価します。他の変換ツールを使う場合も、対象範囲と、手作業・テストが必要な範囲を確認してください。[2]
必ず速くなるとは限りません。データの読込み方、処理を行う場所、クエリ、通信条件などによって変わります。現在の遅さの原因を調べ、実際の操作とデータ量で効果を確かめることが必要です。
既存資産と依存関係、移行範囲、テスト、停止条件を確認して見積もります。比較するときは、初期の移行費用に加え、ライセンス・運用費と利用部門の確認作業も含めてください。画面数やファイル容量だけでは判断できません。
まとめ 自社に必要な移行範囲を先に決める
Accessマイグレーションでは、実行環境、データ、画面や処理を分けて考えると、必要な作業を整理できます。現在の操作を残す方法も、Power AppsやWebアプリで作り替える方法も、業務要件に応じた選択肢です。
まずは、開発原本、使っている機能、外部連携、困っている操作を一覧にしてみてください。その情報をもとに移行方法を絞り、試験移行・業務結果の照合・切戻し・保守まで含めて計画を立てましょう。
今のAccessをどこまで残せるか、整理しませんか？
Accessの画面や帳票を残すか、データ基盤を移すか、アプリを作り替えるかは、現在の構成と業務要件で変わります。既存システムの調査をもとに、改修・SQL Serverへの移行などの進め方をご相談いただけます。仕様書や原本の有無も含め、現状をお知らせください。対応範囲は確認のうえご案内します。
参考情報
[1] Microsoft Learn｜Migrate Access databases to SQL Server and Azure SQL
[2] Microsoft Learn｜Convert Access database objects
[3] Microsoft Learn｜Prepare Access databases for migration
[4] Microsoft Learn｜Migrate Microsoft Access data to Microsoft Dataverse
[5] Microsoft Learn｜64-bit Visual Basic for Applications overview
[6] Microsoft ｜Microsoft Access 製品ページ