Migrating a Shared Access Database: Multi-User .mdb to .accdb

A standalone Access database used by one person is relatively straightforward to migrate. A shared Access database used by five or ten people — with multiple concurrent users, linked tables, and a front-end everyone runs from their own workstation — is a different project entirely.

The migration steps are similar, but the ordering matters more, the testing requirements are higher, and the cutover needs to be coordinated so nobody loses work or opens the wrong file after you switch.

This guide covers the full process for a shared multi-user .mdb to .accdb migration.

First: Understand Your Current Architecture

Before you migrate anything, document what you have. Shared Access databases come in a few configurations:

Single File (Unsplit)

All users open the same .mdb file from a shared network location. The file contains both the data tables and the forms/queries/reports. Everyone accesses the same file simultaneously.

This is the most fragile architecture. If the file is left open when Access crashes, it can corrupt. If two users make conflicting edits, Access has to reconcile. It works at small scale but has limits. If this is your situation, the migration is also a good time to split the database (see below).

Split Database (Front-End / Back-End)

The more common architecture for shared databases: a back-end .mdb file on the network holds all the data tables, and each user has their own copy of a front-end .mdb that contains the forms, queries, reports, and VBA code. The front-end links to the back-end tables via linked table connections.

This is the right architecture for shared databases. The migration is cleaner because you can convert back-end and front-end separately.

Step 1: Audit the Existing Database

Before converting anything, document what's in the database:

• List all tables, queries, forms, reports, macros, and VBA modules
• Identify linked tables — what do they link to, and where are those files?
• Check VBA code for Declare statements (PtrSafe issues on 64-bit Access)
• Check forms for ActiveX controls
• Note any ODBC connections or external data sources
• Confirm who uses the database and when — plan the cutover window around usage

For a complete VBA audit checklist, see the Access VBA Audit Before Migration guide.

Step 2: Split the Database (If Not Already Split)

If your database is still a single unsplit .mdb file, split it before converting anything:

1. Open the .mdb file in Access
2. Go to Database Tools → Access Database → Database Splitter
3. Choose a location for the new back-end file (the shared network location)
4. Access creates a back-end .mdb with all tables and a front-end .mdb with everything else
5. The front-end's tables are automatically converted to linked tables pointing to the back-end

Test that the split database works correctly for all users before proceeding to format conversion. Don't combine splitting and format conversion in the same step — if something breaks, you won't know which change caused it.

Step 3: Convert the Back-End

The back-end should be converted first, before any users are active. Schedule this during off-hours or after notifying all users to close the database.

1. Confirm no users have the database open (check for absence of backend_be.ldb)
2. Make a full backup of the back-end .mdb
3. Open the back-end in Access: File → Open
4. Go to Database Tools → Access Database (the "Access Database" button converts to .accdb)
5. Save the new .accdb with a clear name like database_be.accdb
6. Do NOT delete the original .mdb yet — keep it as a fallback

After conversion, verify the back-end:

• Open in Access — confirm all tables are present with correct record counts
• Run Compact and Repair on the new .accdb
• Check table relationships are intact

Step 4: Update Linked Tables in the Front-End

The front-end still points to the old .mdb back-end. Update it to point to the new .accdb:

1. Open the front-end .mdb in Access
2. Go to External Data → Linked Table Manager
3. Select all linked tables from the old back-end
4. Check "Always prompt for new location" and click OK
5. Navigate to the new .accdb back-end location and select it
6. All linked tables should update to point to the .accdb

Test that all queries, forms, and reports that use linked tables return correct data.

Step 5: Convert the Front-End

1. Back up the front-end .mdb
2. Open it in Access
3. Go to Database Tools → Access Database
4. Save as a new .accdb front-end file

After conversion, check for VBA compile errors:

• Open the VBA editor (Alt+F11)
• Go to Debug → Compile [DatabaseName]
• Fix any PtrSafe errors in Declare statements (see VBA Audit guide)
• Check Tools → References for any MISSING entries — uncheck them and find replacements

Step 6: Test with All User Roles and Workstations

This is the most important step and the one most often shortcut. Test on the actual machines users will be using:

• Open the new .accdb front-end on each type of workstation (different Office versions, 32-bit vs 64-bit)
• Test every form — verify all controls work, data saves correctly
• Run every query — verify results match the old database
• Print/preview every report
• Run all VBA macros and event handlers
• Test with multiple users open simultaneously — confirm no locking issues
• Test data entry and confirm records appear for other users after refresh

Do this testing with the old .mdb back-end still available. If anything fails, you can roll back by relinking the front-end to the original .mdb.

Step 7: Cutover

When testing is complete:

1. Notify all users of the migration window
2. During the window, ensure all users have closed the database
3. Distribute the new .accdb front-end to all users (replace their local copy of the front-end, or update the shared location if they're running from the network)
4. Verify each user can open the new front-end and access data
5. Move the old .mdb back-end to a read-only archive location (don't delete it)
6. Update any shortcuts or documentation pointing to the old files

Common Problems and How to Handle Them

Users see "File not found" for linked tables after cutover

The front-end is still looking for the old .mdb back-end. Re-run the Linked Table Manager on the affected user's front-end and repoint to the .accdb.

Forms with ActiveX controls fail to load

Some 32-bit ActiveX controls don't work on 64-bit Access. Check the specific control — many have 64-bit versions available, or can be replaced with built-in Access alternatives. See the ActiveX Forms Replacement guide.

Queries return different results after conversion

ACE SQL is stricter than Jet SQL about reserved words and certain syntax patterns. Check field names against the list of ACE reserved words and bracket any that conflict. See the Jet SQL Migration Guide.

Performance is slower on the new .accdb

Run Compact and Repair on the .accdb back-end. Check whether any indexes were lost during conversion and recreate them. Review Access Performance: .accdb vs .mdb for tuning options.

Part of the Complete Guide to Access Database Migration.

← Back to all posts