データだけ移してフロントは作り直す｜Access移行の現実解

結論：テーブルだけ先に移し、フロントは後で判断する

Access移行の相談を受けると、「画面ごと全部移したい」というご要望が最初に出ることが多いです。ただ、Microsoftの公式ツールSSMA（SQL Server Migration Assistant）は、テーブルとデータは移行できますが、フォーム・レポート・マクロ・モジュールは変換対象外です（SSMA for Access — Microsoft Learn）。フロントエンドをWebシステムやkintoneなど別プラットフォームへ移す場合は画面の再実装が必要ですが、テーブルだけSQL Serverに移してリンクテーブルで接続し、Accessのフォームをそのまま使い続ける方法もあります。

であれば、最初からフロントは「作り直すもの」と割り切って、データ（テーブル）だけを先に移行する。これが当社の経験上、現実的に動く移行パターンの一つです。「データ移行だけ先行する」という選択は妥協ではなく、リスクを区切るための判断です。この記事では、なぜ丸ごと移植が難しいのか、データだけ移すときの実務上の注意点、そしてフロント作り直しへの判断基準を整理します。

フォームとVBAを丸ごと移植できない理由

AccessのフォームはAccess固有のオブジェクト定義として保存されており、Microsoftの公式ツールSSMAでも変換対象外です。マクロも同様です。VBAはExcelやWordでも動作する言語ですが、AccessのVBAコードはDoCmd・Form・ReportといったAccess固有のオブジェクトモデルに依存しており、SQL Server上ではそのまま実行できません。

帳票（レポート）も、AccessのレポートデザイナーはAccess固有の機能です。ExcelやPDFへのエクスポートはAccessから行いますが、帳票のレイアウト定義はSSMAで移行できないため、別の帳票ツールやシステムで再設計・再実装が必要です。実務では帳票の洗い出しに思った以上の時間がかかります（業務フロー調査の記事も参考にしてください）。

「移植ではなく再実装」と言い換えると、費用と工期の見積もりが現実に近づきます。フォームが10画面あれば、それぞれ要件定義・設計・実装・テストが必要です。フロントの再実装はデータ移行より時間とコストがかかる、というのが当社の実務的な感覚です。

データ移行の実務：型変換と整合確認

テーブルとデータを移す作業そのものは、SSMAを使えば技術的な敷居は下がります。ただ、データ型の変換は自動でも、変換後の動作が正しいかどうかは人が確認する必要があります。

SSMAの主な型変換マッピング例を以下に示します（全マッピングはProject Settings (Type Mapping) — Microsoft Learnを参照）。

日付型は当社の経験上、修正が出やすい箇所です。リンクテーブルをAccess SQLで操作するクエリはそのまま動く場合がありますが、パススルークエリやADOでT-SQLを直接実行している箇所では、日付リテラルの記法をAccessの#2024/04/01#形式からSQL Serverの文字列形式に変更する必要があります。Microsoftの移行ガイドも「SQL Serverの日付クエリでは時刻部分も考慮が必要」と明記しています（Access データベースを SQL Server に移行する — Microsoft Support）。

移行前に整えておく3つのこと

データ移行の作業精度は、移行前のAccess側の状態に左右されます。Microsoftの公式移行ガイドが事前作業として案内している項目を中心に整理します。

1. 全テーブルに主キーを設定する。主キーがないテーブルはSSMAで移行できても、移行後にAccessフロントエンドからデータを更新・削除しようとすると問題が出ます。特に、長年使ってきたAccessファイルでは主キー未設定のテーブルが残っていることがあります。
2. 添付ファイル型（Attachment型）を事前に解消する。SSMAはこの型を変換できません。画像や文書ファイルをAccess内の添付ファイル型で保管している場合、ファイルシステムや別のストレージへの移行方針を先に決める必要があります。
3. 件数と合計値で照合基準を決める。移行後に「データが正しく移ったか」を確認するため、主要テーブルの件数と、金額や数量などの集計値を移行前に記録しておきます。移行後に同じ集計を実行して突き合わせる、というのが当社の確認手順です。

バックアップは絶対条件です。移行作業を始める前に、元のaccdbファイルのコピーを別の場所に保管してください。

フロントの作り直しをいつ判断するか

データを移した後、フロントエンドをどうするかは別の判断です。大きく3つの方向があります。

一つ目は、フロントは当面Accessのまま使い続ける。テーブルだけSQL Serverに移してリンクテーブルで接続するアップサイジング構成です。既存の画面を概ね維持できますが、リンクテーブル化による動作の変化があるため、フォームやクエリの動作確認と一部修正は必要です（詳しくはSQL Server移行の構成解説をご覧ください）。バックエンドのデータ容量問題と同時接続時の拡張性は改善しますが、Accessフロント固有の制約や接続管理は残ります。Access 2021を使用している場合は2026年10月13日のサポート終了に備え、Access 2024やMicrosoft 365版への更新またはフロント刷新を別途検討してください。

二つ目は、データ移行と並行して、優先度の高い業務から順にフロントを作り直す段階移行。一度に全部作り直すより現場への影響を分散できます（段階移行の設計パターンも参考にしてください）。

三つ目は、データ移行後に全面的にフロントを刷新する。新システムの要件定義をデータ移行とは別工程で進め、データが揃った状態で新システムの開発に入る形です。

どの方向が合うかは、使っているフォームの数・帳票の複雑さ・現場の習熟度によって変わります。当社の経験上、Accessフォームが少なく帳票が単純な場合は段階移行が取り組みやすく、帳票が複雑で業務ロジックが込み入っている場合はフロント刷新の工期と費用を先に見積もることをお勧めします（移行費用の相場も参考にしてください）。

現状のAccessファイルがデータ移行に向いた構成かどうか、まず現状を確認したい場合は無料の解析可否チェックをご利用ください。ファイルの送信は不要です。

データ移行だけ先行するメリットと限界

データを先に移しておくことで、フロントの作り直しに着手するタイミングを選べます。全面移行を一度にやろうとすると、現行システムを止めずに移行を進める期間が長くなりがちです。データだけ先に移行すれば、フロントの作り直しを進める間もデータはSQL Server上の信頼できる状態で管理できます。

ただし、限界もあります。データを移行しただけではフロントは変わりません。Accessのフォームを使い続ける間は、AccessのサポートやVBAの将来性に関する課題は残ります。「データをSQL Serverに移したから安心」という状態にはなりません。あくまでリスクを分割し、次の工程を準備する時間を作るための手段です。

段階を踏む分、移行全体の費用は一括移行より高くなることもあります。ただ、失敗リスクと現場への影響を小さくできるという点で、当社ではデータ移行を先行させることを検討に値する選択肢として案内しています。

よくある質問

Q. VBAのコードはSQL Serverに移行できますか。

AccessのVBAコードはDoCmd・Form・ReportといったAccess固有のオブジェクトモデルに依存しているため、SQL Server上でそのまま実行できません。SQL Serverにも「ストアドプロシージャ」という形でサーバー側にロジックを置く仕組みがありますが、AccessのVBAをそのままSQL Serverのストアドプロシージャに変換する公式の手段はありません。フォームやレポートと同様に、ロジックの再実装が必要です。

Q. データ移行だけなら費用はどのくらいですか。

テーブル数・データ量・事前の整備状況によって変わります。主キー未設定のテーブルが多い・添付ファイル型が含まれる・照合基準の設計から必要、といった状態だと作業量が増えます。当社では現状確認を経てから見積もりをお出ししています（費用相場の詳細もご参照ください）。

Q. Accessのメモ型はSQL Serverのどの型になりますか。

SSMAのデフォルトマッピングではnvarchar(max)に変換されます。Access 97形式（.mdb）のメモ型はvarchar(max)にマッピングされます。長文テキストの保存自体は問題なく移行できますが、SQL Serverではnvarchar(max)列へのインデックス作成に制限があります。全文検索が必要な場合は別途設計が必要です。

Q. 移行後に件数が合わない場合はどうすれば良いですか。

まず、移行前後の件数の差分を特定してください。SSMAのログに移行成功・失敗の件数が記録されます。当社の経験上、件数が合わない場合の原因としてはNULL制約違反・主キー重複・文字数超過・型の値域不一致などが挙がります。照合用のクエリを移行前後で用意し、差分が出た行を特定してから個別に原因を調べる手順を取っています。