Every organization running legacy Access databases eventually faces this question: do we migrate to SQL Server, or just upgrade from .mdb to .accdb and call it done?
The answer depends entirely on your situation. SQL Server is the right choice for some workloads. For others, it's massively over-engineered — a $50,000 project to solve a $500 problem. Getting this decision wrong wastes months of engineering time and real money.
This guide gives you an honest framework for making the call, based on what we've seen from organizations that have done both migrations.
When people say "migrate Access to SQL Server," they usually mean one of two things:
These are very different projects with very different costs. Most guides treat them as the same thing. They're not.
There's also a third option that's often ignored:
Run through these criteria in order. Stop when you hit a clear answer.
How many people use this database simultaneously at peak?
This single criterion eliminates 80% of the "should we move to SQL Server?" decisions for small and mid-size organizations. Most departmental Access databases have 2–8 real concurrent users, which makes .accdb more than sufficient.
Current size and growth trajectory:
Check current size: right-click the .mdb or .accdb file in Windows Explorer → Properties. Growth rate: check LastWriteTime on the file over 90 days and estimate monthly growth.
Does this database store regulated data?
If yes, you almost certainly need SQL Server (or another enterprise database). .accdb's encryption and audit logging don't meet enterprise compliance standards. Access also lacks row-level security and activity logging that compliance frameworks require.
Are users actually complaining about speed? Are queries taking more than a few seconds on tables with tens of thousands of rows?
If yes: first check whether the problem is Access or whether it's a query design issue. A poorly indexed .accdb query can be fixed without SQL Server. A well-indexed .accdb query on 500K rows runs fast.
If you've indexed correctly and performance is still unacceptable: SQL Server will help. If you haven't indexed: fix that first and re-evaluate.
If your .mdb database broke after a Windows or Office upgrade, you may just need a format upgrade — not SQL Server. LegacyLeaps scans your database and shows exactly what's needed.
Run the Free ScanBefore deciding on SQL Server, understand what a simple format upgrade gets you:
For most small business and departmental databases, .accdb addresses the actual problem (compatibility failure after OS/Office upgrade) without the cost and complexity of a SQL Server migration.
If your criteria point to SQL Server, here's what you're taking on.
Microsoft's SQL Server Migration Assistant (SSMA) for Access is free and handles the mechanical parts:
SSMA works reasonably well for straightforward databases. Run it, review the conversion report, fix what it flags, verify the data loaded correctly.
This is where the real work is:
Many organizations choose a middle path: keep the Access application running, but move the data tables to SQL Server and connect them via linked tables. This is called "upsizing" or a split architecture.
Advantages:
Disadvantages:
For organizations where the main driver is concurrency or database size — and the Access application itself works well — upsizing is often the right call. It's dramatically cheaper than a full migration.
| Migration Path | Typical Scope | Rough Cost (IT time) | Downtime Risk |
|---|---|---|---|
| .mdb → .accdb (format upgrade) | 1–2 days | Low (hours) | Low |
| Upsizing (Access + SQL Server back-end) | 1–4 weeks | Medium ($5K–$20K) | Medium |
| Full SQL Server migration (new front-end) | 3–12 months | High ($30K–$200K+) | High |
These ranges vary widely by database complexity, VBA volume, and whether you build a new front-end. Simple databases can be upsized in a day. Complex ones with hundreds of forms and thousands of lines of VBA can take months.
Before you decide anything, you need to know what's actually in your database. Run an audit:
With that data in hand, the decision matrix above gives you a clear path forward.
LegacyLeaps is the right tool when your Access database problem is a format compatibility issue — specifically, when your .mdb won't open properly on modern Windows or Office because of the Jet engine dependency.
LegacyLeaps migrates .mdb to .accdb, preserving:
If your problem is concurrency, compliance, or database size — those are SQL Server problems, and we'll tell you that honestly. The free scan shows you what's in your database so you can make an informed decision about which path you actually need.
Run the free scan and see a complete report on your database: tables, VBA modules, forms, external links, and risk factors. No conversion, no changes — just information.
Download Free ScannerYes. Microsoft provides the SQL Server Migration Assistant (SSMA) for Access, which automates schema and data migration. However, VBA code, Access-specific queries, and front-end forms do not migrate automatically and require manual work.
Migrate to SQL Server when you have more than 10–15 concurrent users, databases approaching the 2GB .accdb size limit, compliance requirements needing enterprise-grade auditing, or when Access performance is causing business disruption despite proper indexing. For smaller workloads, upgrading .mdb to .accdb is faster, cheaper, and sufficient.
No. SSMA migrates tables, indexes, queries, and data. VBA code, macros, forms, and reports must be rebuilt or adapted. Many organizations keep the Access front-end running against a SQL Server back-end via linked tables — this avoids rebuilding VBA and forms entirely.
For most small businesses and departmental databases with under 10 concurrent users and databases under 1GB, upgrading from .mdb to .accdb is sufficient and dramatically simpler. The .accdb format resolves the Jet engine dependency, supports modern Windows and Office, and adds AES encryption. SQL Server is warranted for larger, multi-user, or compliance-sensitive workloads.
A simple upsize (Access front-end + SQL Server back-end) for a small database takes 1–4 weeks. A full migration with new front-end development takes 3–12 months depending on VBA complexity and whether forms need to be rebuilt. Format-only upgrade (.mdb to .accdb) takes 1–2 days.
Download LegacyLeaps and scan your files for free. See exactly what needs to be converted before you spend a penny.
Download Free ScannerThe step-by-step checklist for auditing, converting, and validating legacy .xls and .mdb files — without losing a single macro.
Practical fixes for legacy Excel and Access problems. No spam.