From .mdb to .accdb or SQL Server — Choosing the Right Migration Path

April 19, 2026 · 9 min read

Your .mdb database needs to move. It's either broken in your current Windows environment, at risk from the next upgrade, or simply hitting the scalability limits of the Jet engine. The question isn't whether to migrate — it's where.

Three paths are available: convert to .accdb (staying in the Access ecosystem), migrate the data to SQL Server (keeping or replacing Access as the front-end), or use the hybrid approach (Access front-end with SQL Server back-end). Each one is the right answer for a different type of database.

This guide gives you the decision criteria to pick the right path for your specific situation, without overselling either the complexity of SQL Server or the limitations of .accdb.

Understanding What You Have: The Pre-Decision Inventory

Before choosing a migration path, you need to understand your database's profile:

Run LegacyLeaps's free scan to get the application complexity picture: VBA module count, form count, linked table dependencies, ActiveX controls. That tells you how expensive a SQL Server migration would be relative to a simple .accdb conversion.

Path 1: Migrate to .accdb

Best For

Databases that work fine, just need a modern format

The .mdb to .accdb migration is the lowest-risk, lowest-cost path. Your application stays intact. Your forms, reports, and VBA code continue working. You fix Windows compatibility. You get the ACE engine instead of Jet, which provides better 64-bit support and improved security features.

What you don't get: SQL Server's enterprise security model, unlimited scale, row-level locking, or full T-SQL. For most Access databases, that's fine. The 80% of Access databases that serve small teams doing departmental work don't need SQL Server — they need to stop failing after Windows upgrades.

Migration effort: Low. LegacyLeaps automates the conversion, VBA updates, and linked table refresh. Most databases convert in hours.

Ongoing cost: No additional licensing. Access is already licensed as part of Microsoft 365.

Path 2: Full SQL Server Migration

Best For

Databases that have outgrown Access's design limits

Moving fully to SQL Server means replacing Access entirely as both the data engine and (usually) the application layer. This is the right answer for databases that have genuinely outgrown what the ACE engine can provide.

What SQL Server gives you: row-level locking for high concurrency, no file size limits, enterprise backup and recovery, full T-SQL for complex queries, integrated Windows authentication, and compatibility with Power BI and other enterprise reporting tools.

What it costs: SQL Server Standard is approximately $3,900 per 2-core pack (or Server+CAL licensing). But the real cost is development. Your Access forms, reports, and VBA code don't move to SQL Server — you need to rebuild the application layer in something that can connect to SQL Server: a new Access front-end (hybrid, see below), Power Apps, .NET, or a web application. Budget 40-200 development hours depending on complexity.

Migration effort: High. Use Microsoft's SQL Server Migration Assistant (SSMA for Access) to automate the data migration. Plan manually for the application layer rebuild.

Ongoing cost: SQL Server licensing + developer time for the application rebuild.

Path 3: Hybrid — Access Front-End with SQL Server Back-End

Best For

Databases that need SQL Server scale but can't afford to rebuild the app

The hybrid approach is the pragmatic middle path. Your .mdb or .accdb becomes a shell — it still contains your forms, reports, and VBA code. But all the data tables move to SQL Server. Access connects to them via ODBC linked tables.

This is actually how Microsoft recommends Access for multi-user production use. Access handles the application tier. SQL Server handles the data tier. You get SQL Server's concurrency handling and backup infrastructure without rebuilding your application.

What hybrid migration involves

  1. Move to .accdb first — convert your .mdb to .accdb using LegacyLeaps. This fixes Windows compatibility and updates VBA code.
  2. Upsize tables to SQL Server — use Access's built-in Upsizing Wizard (Database Tools → SQL Server) or SSMA to move all data tables to SQL Server.
  3. Re-link tables — delete the local tables from your .accdb and re-link them to SQL Server via ODBC. Your forms continue working because linked tables behave identically to local tables from Access's perspective.
  4. Update Jet SQL for T-SQL compatibility — some queries that work in ACE/Jet use syntax that SQL Server doesn't support. Review and update these queries.
  5. Test forms and VBA — most forms work without changes. VBA that uses DAO recordsets directly may need updates for ODBC-linked table compatibility.

Migration effort: Medium. LegacyLeaps handles steps 1 and some of step 4. The table migration and re-linking (steps 2-3) typically takes 1-3 days for a moderately complex database. Step 5 depends on application complexity.

Ongoing cost: SQL Server licensing. Access licensing is already included in Microsoft 365.

The Decision Matrix

Factor Choose .accdb Choose Hybrid Choose Full SQL Server
Concurrent users 1-15 10-50 50+
Database size Under 1GB Under 10GB Any size
Application complexity High (preserve) High (preserve) Low (rebuild)
SQL Server already in use No Yes Yes
Migration budget (developer hours) 4-20h 20-60h 60-200h+
Primary driver Windows compatibility Scalability + compatibility Enterprise features / rebuilding
LegacyLeaps's role Full migration Step 1 (.mdb→.accdb) Minimal

The Path Most Teams Get Wrong

The most common mistake is choosing the full SQL Server path for a database that's a perfect candidate for .accdb migration.

The reasoning usually goes: "We should do this right. SQL Server is the enterprise solution. Access is for small things." So the team spends 80 development hours rebuilding an Access application in .NET or Power Apps — an application that worked perfectly fine, just needed a format conversion to run on modern Windows.

The .accdb path isn't a compromise. For most Access databases — the ones serving departments, small teams, and internal business processes — it's exactly the right answer. It's faster, cheaper, and it preserves the institutional knowledge embedded in 15 years of VBA and form design.

The SQL Server path is right for the databases that have genuinely outgrown Access. Those exist, and for them, the migration investment is worth it. But they're the minority, not the majority.

Not sure which path fits your database?

Run LegacyLeaps's free scan. It shows you the database size, VBA complexity, form count, and table dependencies — the exact information you need to make the right migration decision.

Try the Free Scan

Where LegacyLeaps Fits In Each Path

Path 1 (.accdb migration): LegacyLeaps handles the full migration — format conversion, VBA 64-bit compatibility updates, linked table refresh, ActiveX audit, and data integrity verification.

Path 3 (Hybrid): LegacyLeaps handles the first step — .mdb to .accdb conversion with VBA updates. You then upsize tables to SQL Server using Access's Upsizing Wizard or SSMA, then re-link. LegacyLeaps's pre-migration scan helps you understand the full application complexity before you commit to the hybrid approach.

Path 2 (Full SQL Server): Use SSMA for the data migration. LegacyLeaps is less relevant here since you're rebuilding the application layer anyway.

Related Reading

Not sure which migration path fits your database?

Schedule a free consultation. We'll assess your database — VBA complexity, form count, table dependencies, and performance requirements — and recommend the right migration path for your organization.

Get a Free Consultation

Related Articles

Get tips like this in your inbox

Practical fixes for legacy Excel and Access problems. No spam.

← Back to all posts