Convert 32-Bit Access Database to 64-Bit

What Actually Needs to Change When Moving Access from 32-Bit to 64-Bit?

The amount of work depends on how the database was built. A data-only ACCDB may need almost no changes, while a mature business application with years of VBA, controls, integrations, and compiled components can require a full compatibility audit.

How to Convert an Access Database from 32-Bit to 64-Bit

A reliable conversion is more than opening the file in 64-bit Access and checking whether the startup form appears. The complete application should be compiled, tested, and validated in the target environment.

1. Preserve the original. Create a backup and work from a controlled copy of the database and any supporting files.
2. Identify the target environment. Confirm the Access/Microsoft 365 version, 32-bit or 64-bit Office, Windows version, drivers, and external applications the database depends on.
3. Open and compile the source application in 64-bit Access. Use VBA compilation to expose incompatible Declare statements, missing references, and other code-level problems.
4. Update Windows API declarations. Add PtrSafe where required and change pointer/handle parameters or return values to LongPtr when they must hold 64-bit quantities.
5. Review user-defined types and variables. Structures that contain pointers, handles, or true 64-bit integers may also need 64-bit-safe data types.
6. Audit ActiveX, COM, DLL, and add-in dependencies. Replace unsupported 32-bit components or redesign the affected feature where no safe 64-bit equivalent exists.
7. Verify database and integration drivers. Check ODBC/OLE DB connections, SQL Server drivers, linked tables, external data sources, and any vendor-specific middleware.
8. Rebuild compiled Access files. Recreate ACCDE, MDE, or ADE deliverables from the source database using the required bitness.
9. Test the full workflow. Test forms, reports, queries, VBA automation, exports/imports, printing, scanning, email, APIs, linked data, and any business-critical integrations.
10. Deploy in stages. Move the updated application into production only after user acceptance testing and a rollback plan are in place.

VBA Example: Updating a Windows API Declaration

One of the most common 32-bit to 64-bit Access problems is legacy VBA that calls the Windows API. Microsoft requires Declare statements running in 64-bit Office to use PtrSafe, but simply adding PtrSafe is not enough if a parameter or return value stores a pointer or handle.

Legacy 32-bit declaration

Declare Function GetActiveWindow Lib “user32” () As Long

64-bit-compatible declaration

Declare PtrSafe Function GetActiveWindow Lib “user32” () As LongPtr

LongPtr is designed for pointer and handle values. In VBA7 it resolves appropriately for the Office bitness, which makes it useful when the same source code must run under both 32-bit and 64-bit Office.

Important: PtrSafe Does Not Automatically Make Code 64-Bit Safe

A common mistake is to add PtrSafe to every Declare statement and stop there. PtrSafe tells VBA that the declaration targets a 64-bit-capable environment; it does not resize parameters or return values automatically.

If a declaration passes or returns a pointer, handle, or other 64-bit quantity, the relevant data type must also be updated. Incorrectly leaving those values as Long can truncate a 64-bit value and lead to unexpected behavior or application failure.

Can One Access Database Support Both 32-Bit and 64-Bit Office?

Often, yes. Many Access applications can be written so the same source ACCDB works in both environments. LongPtr is especially useful because it maps to the appropriate pointer-sized type for the Office bitness.

Conditional compilation can also be used when different code is genuinely required. However, the entire dependency chain still matters: ActiveX controls, DLLs, ODBC drivers, COM components, and other integrations must also support the environments you plan to deploy.

ACCDB vs. ACCDE, MDE, and ADE: What Changes?

An ACCDB source database is different from a compiled Access file. A source ACCDB may be able to run under both 32-bit and 64-bit Access after its code and dependencies are made compatible.

Compiled Access files are bitness-sensitive. A 32-bit ACCDE, MDE, or ADE cannot simply be used as the finished 64-bit deliverable. The source database should be corrected and then recompiled using the target Access bitness.

Does Moving to 64-Bit Access Make the Database Faster?

Not automatically. The main advantages of 64-bit Office are compatibility with 64-bit components and access to a larger memory address space. Database speed still depends on query design, indexing, network performance, linked-table design, data volume, VBA efficiency, and the backend.

For that reason, a 32-bit to 64-bit conversion should be presented primarily as a compatibility and modernization project—not as a guaranteed performance upgrade.

When a 64-Bit Conversion Becomes a Larger Modernization Project

Some applications reveal broader technical debt during the conversion. If critical controls are obsolete, the database depends on unsupported drivers, or the backend no longer meets security and scalability needs, it may make sense to combine the 64-bit upgrade with other modernization work.

• Replace unsupported ActiveX or COM components.
• Update old ODBC/OLE DB drivers and connection methods.
• Refactor unstable VBA and Windows API code.
• Move shared data to SQL Server or Azure while retaining Access as the front end.
• Improve deployment so each user runs a controlled local front end.