How to Convert .mdb to .accdb: Step-by-Step Guide

You have a .mdb file. You need it to work on modern Windows with a modern version of Access. Here is the complete process, from opening the file for the first time on a new machine to handing it back to users as a fully functioning .accdb. This guide is practical — no theory, no detours, just the steps in order.

What You'll Need

• Microsoft Access 2010 or later (any version can open .mdb and save as .accdb)
• The original .mdb file
• Enough free disk space for both the .mdb and the new .accdb (plan for 2x the .mdb size)
• Administrator access on the machine (for re-registering ActiveX controls if needed)

Before You Convert: The Non-Negotiable First Step

Step 1: Open the .mdb and Check for Errors

Open the .mdb in Access. You may see a security warning bar — click "Enable Content" for now. If the database opens to a main menu form, navigate around and note what's there. If it opens to the Navigation Pane, you're looking at tables, queries, forms, and reports directly.

Check for immediate errors on open. If VBA event handlers fire on form load (startup forms are common in .mdb databases), note any error messages. These are pre-existing issues in the .mdb — fix them before converting so you're not debugging migrated code and pre-existing bugs at the same time.

Step 2: Fix VBA Compile Errors

Press Alt+F11 to open the VBA editor. Go to Debug → Compile (the menu name matches whatever module is open). The compiler will flag any syntax errors, missing object references, or type mismatches.

If you get "Compile error: Can't find project or library," go to Tools → References and look for any reference marked "(MISSING)." Either install the missing library or uncheck it if the code doesn't actually use it.

If you get "Compile error: The code in this project must be updated for use on 64-bit systems," you have Declare statements without PtrSafe. Add PtrSafe after every Declare keyword. See the detailed Access VBA Audit guide for the full fix.

Fix all compile errors before moving to the next step. The compilation must succeed cleanly.

Step 3: Check for Reserved Word Issues in Queries

Before converting, do a quick scan for reserved word violations in your saved queries. In the VBA Immediate Window (Ctrl+G), run:

Dim db As DAO.Database, qd As DAO.QueryDef
Set db = CurrentDb
For Each qd In db.QueryDefs
    If Left(qd.Name, 1) <> "~" Then Debug.Print qd.Name & ": " & Left(qd.SQL, 200)
Next qd

Scan the output for field names like Name, Date, Status, Level, Order, Group, Month, Year, Type, or Value used without square brackets. Bracket them now. See the Jet SQL Migration guide for the full reserved word list.

Step 4: Note Your ActiveX Controls

Open each form in Design View (right-click the form name in the Navigation Pane → Design View). Look for any controls that appear as a grey box with an X or show "Unregistered ActiveX Control" in the property sheet. List them — you'll need to replace or re-register them after conversion.

Common ones to watch for:

• Calendar Control (grey box where a calendar picker should be) — needs replacement with built-in Date Picker
• ListView or TreeView — needs MSCOMCTL.OCX re-registration
• Common Dialog — needs replacement with VBA FileDialog

See the ActiveX Controls guide for replacement instructions.

Step 5: Record Pre-Conversion Table Counts

In the Immediate Window, get a row count for every table:

Dim db As DAO.Database, tbl As DAO.TableDef
Set db = CurrentDb
For Each tbl In db.TableDefs
    If Left(tbl.Name, 4) <> "MSys" Then
        Debug.Print tbl.Name & ": " & DCount("*", "[" & tbl.Name & "]")
    End If
Next tbl

Copy this output somewhere. You'll compare it against the .accdb counts after conversion.

Step 6: Run the Conversion

Access will convert the database and open the new .accdb. Watch for any error messages during conversion. Common messages:

• "Some data may not have been converted" — check the Conversion Errors table that Access creates
• Workgroup security warning — expected if your .mdb used workgroup security; see the Security guide

Step 7: Compact and Repair the .accdb

Immediately after conversion, run Database Tools → Compact and Repair Database. This reduces file size, defragments internal pages, and runs a consistency check. If Compact and Repair reports errors, do not proceed — investigate the errors before putting users on the database.

Step 8: Compare Table Row Counts

With the .accdb open, run the same row count snippet from Step 5 in the Immediate Window. Compare the output to the counts you saved from the .mdb. Every table should match exactly. Any discrepancy needs investigation.

Step 9: Fix ActiveX Controls

Now go through the list of broken ActiveX controls you noted in Step 4 and apply the replacements. The most common fix:

• Calendar Control: delete the old control, add a text box, set Format to Short Date, set Show Date Picker to "For dates"
• MSCOMCTL.OCX controls: run regsvr32 "C:\Windows\SysWOW64\MSCOMCTL.OCX" as Administrator
• Common Dialog: replace code with Application.FileDialog

Step 10: Configure Trusted Locations

Add the folder containing the .accdb to Trust Center Trusted Locations:

1. File → Options → Trust Center → Trust Center Settings
2. Trusted Locations → Add new location
3. Browse to the .accdb folder
4. Click OK

The security warning bar should no longer appear when opening this database.

Step 11: Test Everything

Open every form in normal view. Click every button. Run every report. Trigger every scheduled process. Create a test record, edit it, delete it. If any form has data entry, enter data. If any report filters by date or user, test those filters.

Log every test: what you tested, what happened, what you fixed. This log is your evidence that the migration is complete and correct.

Step 12: Deploy to Users

Copy the .accdb to the production location. Configure Trusted Locations on each user's machine (or deploy via Group Policy). Update any desktop shortcuts or batch files pointing to the old .mdb path.

Tell users what changed. If controls look different (new date pickers instead of calendar popups, for example), a one-page note saves a lot of help desk calls.

Keep the .mdb backup available for 30 days. Only retire it after you've confirmed the .accdb is working correctly with all users and no data issues have surfaced.

For the complete reference on any step above, see the Complete Guide to Access Database Migration. For the full post-migration testing checklist, see the Migration Validation Checklist.

← Back to all posts