If you still have Microsoft Access databases in the old .mdb format, you are running on borrowed time. The Jet 4.0 engine that powers .mdb files is deprecated, unsupported on Windows 11, and riddled with known security vulnerabilities. Converting to .accdb is no longer optional — it is a business requirement.
This guide walks you through everything involved in converting .mdb to .accdb: the manual process, what breaks during conversion, a step-by-step checklist, testing procedures, and what to do when you have dozens or hundreds of files to migrate.
The .mdb format was introduced with Access 97 and uses the Microsoft Jet 4.0 database engine. Microsoft replaced it with the ACE engine and the .accdb format starting in Access 2007 — nearly two decades ago. Here is why continuing to use .mdb is a serious risk:
Microsoft stopped developing the Jet 4.0 engine years ago. It receives no patches, no performance improvements, and no compatibility updates. When something breaks, you are on your own. The Microsoft.Jet.OLEDB.4.0 provider is not included in 64-bit versions of Windows, which means any modern machine running 64-bit Office cannot use Jet-based connection strings at all.
Windows 11 removed or restricted several components that .mdb files depend on. The Jet OLEDB provider is missing, legacy ActiveX controls like the Calendar Control (mscal.ocx) are gone, and older ODBC drivers may not be present. Many businesses discovered this the hard way after upgrading — databases that worked fine on Windows 10 suddenly threw errors or refused to open entirely.
The .mdb format has no support for database-level encryption using modern standards. Jet 4.0 used weak RC4 encryption that is trivially crackable. The .accdb format supports AES-256 encryption through the ACE engine. Additionally, .mdb files support the legacy Workgroup Security model (.mdw files), which was removed in Access 2010 because it was fundamentally insecure. If your database contains any sensitive data — customer records, financial information, employee data — the .mdb format is a liability.
The .accdb format also brings multi-valued fields, Attachment data types, improved memo field handling (large text), better SharePoint integration, and the Navigation Pane. You gain access to modern Access features that are simply unavailable in the .mdb format.
The basic conversion process is straightforward:
Access will create a new .accdb file with your tables, queries, forms, reports, macros, and VBA modules copied over. The original .mdb file remains untouched.
If only it were that simple. The Save As operation converts the file container, but it does not fix the code, references, and configurations inside. That is where the real work begins.
A successful Save As does not mean a successful migration. Here are the most common issues that surface after converting .mdb to .accdb:
Your VBA project likely references specific library versions that change between the Jet and ACE environments. The most common breakage:
Microsoft DAO 3.6 Object Library needs to become Microsoft Office 16.0 Access Database Engine Object LibraryMicrosoft ActiveX Data Objects 2.5 needs to become Microsoft ActiveX Data Objects 6.1 LibraryIf your database is split into a front-end (.mdb) and back-end (.mdb), the linked tables in the front-end contain hardcoded connection strings pointing to the old .mdb back-end. After converting, these links still reference the old file path and use the Jet provider:
' Old linked table connection (broken after conversion):
;DATABASE=C:\Data\Backend.mdb
' Needs to be updated to:
;DATABASE=C:\Data\Backend.accdbYou must convert the back-end first, then re-link every table in the front-end to point at the new .accdb back-end. If you have multiple front-ends sharing a single back-end, every one of them needs updating.
Older .mdb databases often mix DAO and ADO data access code. In the Jet world, DAO used DBEngine.Workspaces(0) and ADO used Microsoft.Jet.OLEDB.4.0. After conversion:
Microsoft.Jet.OLEDB.4.0 must change to Microsoft.ACE.OLEDB.12.0CurrentDb.Execute with Jet-specific SQL (like DISTINCTROW or Jet-specific wildcard characters), test thoroughlyForms built in Access 97 or 2003 frequently use ActiveX controls that do not exist on modern Windows:
| Old ActiveX Control | Status | Replacement |
|---|---|---|
| Calendar Control (mscal.ocx) | Removed | Built-in Date Picker |
| Common Dialog (comdlg32.ocx) | Removed | Application.FileDialog |
| Rich Text Box (richtx32.ocx) | Removed | Rich Text memo field |
| Spreadsheet Control | Removed | Subform with datasheet view |
| Web Browser Control | Deprecated | Updated Web Browser or custom form |
When Access encounters a form with a missing ActiveX control, it either refuses to open the form, shows a blank space where the control was, or throws a runtime error. Each control requires a different replacement strategy.
If your VBA code calls Windows API functions and you are running 64-bit Office, every Declare statement needs the PtrSafe keyword. Without it, the VBA project will not compile at all:
' Before (fails on 64-bit Office):
Declare Function GetTickCount Lib "kernel32" () As Long
' After (works on 64-bit Office):
Declare PtrSafe Function GetTickCount Lib "kernel32" () As LongFollow this checklist in order to convert .mdb to .accdb without losing functionality:
Jet.OLEDB.4.0 and replace with ACE.OLEDB.12.0. Search for .mdb in connection strings and update to .accdb.Declare Function and Declare Sub and add PtrSafe to each.Converting the file is half the job. Testing is the other half. Do not skip any of these steps:
Immediately after conversion, run Database Tools > Compact and Repair Database. This rebuilds internal indexes, reclaims space, and can surface corruption issues that the conversion masked.
Open each form in Form View and Design View. Open each report in Print Preview and Design View. You are looking for missing controls, layout shifts, and runtime errors. Pay special attention to forms that use subforms — the parent-child linking may reference old field names or connection strings.
Execute every Select, Update, Append, Delete, and Crosstab query. Jet SQL and ACE SQL are mostly compatible, but edge cases exist. Watch for queries using Jet-specific syntax like PARAMETERS with type names that changed, or queries referencing linked tables that were not properly re-linked.
Run the main entry points of your VBA code. Test form events (OnOpen, OnLoad, button clicks). If your database has scheduled tasks or automation, trigger them manually. Check that data reads, writes, updates, and deletes all work correctly.
Open each linked table and verify the data is present and correct. Sort by primary key and spot-check row counts against the original. If tables link to external data sources (SQL Server, Excel, SharePoint), verify those connections still work.
The manual process above works for a single database. But many businesses do not have a single database — they have dozens or hundreds of .mdb files accumulated over years. Departments create their own databases, vendors ship custom Access applications, and legacy systems multiply.
Bulk conversion introduces problems that do not exist at small scale:
At this scale, manual conversion becomes a project that takes weeks or months — and ties up staff who have other work to do.
Upload your .mdb files and LegacyLift converts them to .accdb with all the fixes applied: VBA references updated, connection strings rewritten, Jet provider calls replaced with ACE, PtrSafe keywords added, ActiveX controls flagged with specific replacement instructions, and linked table paths updated. You get back a converted file and a detailed compatibility report covering everything that changed and anything that needs manual attention.
For bulk conversions, LegacyLift maps dependencies between databases, determines the correct conversion order, and processes the entire batch — not file by file, but as a system.
Converting .mdb to .accdb is necessary — Jet 4.0 is deprecated, Windows 11 does not fully support it, and the security model is obsolete. The Save As operation is the easy part. The real work is fixing VBA references, updating connection strings from Jet to ACE, re-linking tables, replacing missing ActiveX controls, and adding PtrSafe declarations for 64-bit compatibility.
For a single simple database, the manual checklist above will get you there in an hour or two. For complex databases with extensive VBA code, or for bulk conversions involving dozens of files, the manual approach becomes impractical. That is exactly the problem LegacyLift was built to solve.
If you have a complex migration or a large batch of files, our done-for-you service includes a free consultation to scope the project before any work begins. Your files are transferred securely and deleted after delivery.