Your Access database works. It has worked for years — tracking inventory, managing client records, running payroll calculations. But now it's slow, it crashes when more than three people open it at once, and your IT director is asking hard questions about backups and disaster recovery. It's time to talk about migrating to SQL Server.
This guide covers the full process: when to upsize, how to prepare your database, the two tools Microsoft provides, what breaks during migration, and a decision framework for choosing between SQL Server and a full web app modernization.
Access is a single-file database. It's built for one person, maybe a small team of two or three. When you push it beyond that, you hit its architectural limits — not bugs, but fundamental design constraints the Jet/ACE engine was never built to overcome.
These are the signals that point to SQL Server:
Error 3343 or files becoming corrupted, you've outgrown the single-file model.If your database is small, single-user, and works fine today, you may not need this migration at all. The goal isn't to modernize for its own sake — it's to fix a real problem.
Before diving into the SQL Server migration steps, it's worth acknowledging that SQL Server is not your only option. Depending on how your team works and where Access is limiting you, a web app modernization may be a better fit.
| Consideration | Upsize to SQL Server | Modernize to Web App |
|---|---|---|
| Keep Access front-end (forms, reports) | Yes — linked tables | No — replaced entirely |
| Browser access (no Windows required) | No | Yes |
| Concurrent users | Hundreds (SQL Server) | Unlimited |
| VBA macros and custom forms preserved | Yes | Rebuilt as web features |
| Mobile access | No | Yes |
| Migration complexity | Moderate | High |
| Time to complete | Days to weeks | Weeks to months |
If you need to keep your Access forms and reports running without rewriting everything, SQL Server upsizing is the lower-risk path. If your team is ready to leave Windows-desktop Access behind entirely and work from any browser, AccessLeap handles the web app modernization path.
This guide focuses on the SQL Server migration path.
If your database is still in the legacy .mdb format (the pre-Access 2007 format), convert it to .accdb before you start the SQL Server migration. This matters for two reasons:
.accdb file gives it a cleaner schema to analyze..mdb files has known quirks around data type handling that can cause silent precision loss during migration.If your .mdb file won't open in modern Access — or you're on Windows 11 and the file format is causing compatibility errors — LegacyLeaps can convert it to .accdb before you start the SQL Server migration. Run the free scan to see exactly what's inside the file.
Once you have a working .accdb, compact and repair it (Database Tools → Compact and Repair Database) and take a full backup before proceeding.
LegacyLeaps converts legacy Access databases to .accdb format — preserving all your tables, relationships, queries, and VBA code. Scan for free before you commit.
Run the Free ScanAccess has a built-in Upsizing Wizard under Database Tools → SQL Server. It's the faster option for simple databases — typically 30–60 minutes for a small database — but it has significant limitations:
Use the Upsizing Wizard only for small databases (under 50MB, fewer than 30 tables) with simple queries and no stored procedures.
SSMA for Access is a free Microsoft tool that provides a full migration assessment before touching your data. Download it from the Microsoft website (search "SSMA for Access"). It:
For anything beyond a toy database, use SSMA.
Install SSMA for Access on a Windows machine with Access and SQL Server connectivity. Launch it, create a new project, and select your target SQL Server version (2019, 2022, or Azure SQL).
Click Add Databases and select your .accdb file. SSMA reads the schema without modifying the file.
Enter your SQL Server connection details. If you're migrating to a new server, create an empty target database first. SSMA will populate it.
Before migrating anything, run the conversion assessment. SSMA will flag:
OLE Object → VARBINARY(MAX))Fix what you can in Access before proceeding. Add primary keys to any tables that don't have them — this is the most common blocker.
Right-click your database in the Access Metadata Explorer and select Convert Schema. SSMA translates your tables, queries, and relationships to SQL Server DDL. Review the output tree — orange warning icons indicate items needing manual review.
Right-click the converted schema in the SQL Server Metadata Explorer and select Synchronize with Database. This creates the tables, indexes, and constraints on SQL Server without moving any data yet.
Right-click your Access database and select Migrate Data. SSMA transfers row data table by table and reports success counts and errors per table. Check the Data Migration Report for any rows that failed to migrate.
This is what keeps your Access forms and reports working after migration. In SSMA, select Create Linked Tables. This replaces your local Access tables with ODBC links to the SQL Server tables — your forms, queries, and VBA code continue running against the same data, now backed by SQL Server.
Alternatively, in Access: External Data → ODBC Database, select your SQL Server, and link each table.
Access queries use Jet SQL, which differs from T-SQL in several ways. The most common issues:
DateDiff(), DateAdd(), Format(). T-SQL uses DATEDIFF(), DATEADD(), FORMAT() — same names, different argument order in DATEDIFF/DATEADD.&, T-SQL uses + or CONCAT().IIF(condition, true, false). T-SQL uses CASE WHEN condition THEN true ELSE false END.* and ?. T-SQL LIKE uses % and _.SSMA handles most of these automatically, but complex nested queries may require manual rewriting.
Access AutoNumber fields become SQL Server IDENTITY columns. This usually works fine, but if you have code that inserts explicit values into AutoNumber fields, you'll need to use SET IDENTITY_INSERT ON for those operations.
SQL Server linked tables require a primary key for Access to send updates back to the server. Any table without a primary key becomes read-only after migration. Fix this in Access before migrating by adding a primary key to each affected table.
Access OLE Object fields (used for embedded images, Word documents, Excel files) migrate as VARBINARY(MAX) in SQL Server. The data transfers, but if your forms display these embedded objects, you may see rendering issues. Consider extracting and storing these as files referenced by path instead.
After migration, before decommissioning your original Access file:
Keep the original .accdb file in a backup location for at least 30 days. Don't delete it until you're confident the linked version is running cleanly.
SQL Server upsizing is the right call when you want to keep your existing Access forms and reports intact. But it doesn't solve everything:
If those limitations matter to your business — if you have remote users, want a browser-based interface, or are planning to retire the Windows desktop dependency — the better answer is modernizing to a web application rather than upsizing.
AccessLeap converts Access databases to modern web applications — preserving your data, relationships, and business logic while replacing the Access front-end with a browser-based interface that works on any device. It's the path for teams that have outgrown both Access and the SQL Server + linked tables approach.
If your Access database is still in .mdb format or won't open cleanly, start with a free LegacyLeaps scan. We'll show you exactly what's in your file before you decide on a migration strategy.
Download Free ScannerYou can, but it's safer to convert the .mdb to .accdb first. The Upsizing Wizard and SSMA both work with either format, but an .accdb file gives SQL Server a cleaner schema and avoids legacy Jet engine quirks that can cause silent data loss. See our guide on converting .mdb to .accdb if you need to start there.
SSMA for Access is a free Microsoft tool that automates schema conversion, data migration, and query translation from Access to SQL Server or Azure SQL. It handles Jet SQL to T-SQL conversion, data type mapping, and linked table setup. It's more thorough than the built-in Upsizing Wizard and produces detailed migration reports.
Yes — if you use linked tables. After upsizing, Access keeps the front-end (forms, reports, VBA) and links to SQL Server tables via ODBC. Your forms and reports continue working without modification. The only things that change are the data storage and the queries running against the back end.
A small database (under 100MB, 10–20 tables) typically migrates in an afternoon using SSMA. Larger databases with complex queries or many forms may take 1–2 days for migration and another 1–2 days for testing. Budget extra time for query rewrites — Jet SQL and T-SQL are not identical.
SQL Server makes sense when you want to keep the Access front-end but need better performance, concurrency, or security at the data layer. Modernizing to a web app makes sense when users need browser access, the Access UI is limiting your workflow, or you want to eliminate the Windows-desktop dependency entirely. AccessLeap handles the web app modernization path.
Practical fixes for legacy Excel and Access problems. No spam.