Upgrading Microsoft Access 2016 to Access 2024: 32-bit vs 64-bit, API Declarations and Running Both Versions During the Switch

Moving an operational Microsoft Access 2016 database application to MS Access 2024 requires verifying file format compatibility, updating 32-bit Windows API declarations with PtrSafe and LongPtr attributes, and aligning external database drivers. Because Microsoft 365 and modern standalone Office installations default to 64-bit architecture, applications that ran reliably for years on 32-bit MS Access 2016 often fail to compile on 64-bit MS Access 2024 until conditional compilation handles pointer precision and legacy ActiveX dependencies. Organizations can safely manage this transition by establishing an isolated test environment, compiling code under MS Access 2024, maintaining separate front-end builds when necessary, and staging cutovers without forcing disruptive desktop rollouts.

Why Is the Upgrade from Access 2016 to Access 2024 Happening Now?

Many mission-critical business systems run quietly inside Microsoft Access 2016. Because these databases handle core day-to-day operations—such as inventory tracking, order dispatching, labor costing, and project scheduling—teams naturally avoid modifying software that continues to work.

However, several infrastructure milestones make upgrading unavoidable:

• Operating System and Office Lifecycle Milestones: Microsoft ended mainstream support for Office 2016 in 2020, and extended support concluded in October 2025. Running unsupported desktop client software exposes networks to security risks and audit findings. Related milestones, such as the Windows Server 2016 End of Support, add further urgency for teams running shared infrastructure.
• Standard Hardware Refresh Cycles: When organizations purchase new desktop PCs, those machines ship with current operating systems and current Office suites—either standalone Office 2024 or Microsoft 365 Apps. IT departments face growing pressure to standardize desktop builds rather than maintaining legacy software images for a handful of internal databases.
• Cloud Service and Security Requirements: Microsoft no longer supports Office 2016 for connecting to Microsoft 365 services. Maintaining operational continuity requires bringing the client runtime up to date.

For an overview of overall database maintenance and architecture strategies, review our comprehensive guide to Microsoft Access database management.

What Usually Carries Over Without Breaking?

The transition from MS Access 2016 to MS Access 2024 does not require a complete application rewrite. Microsoft has maintained backward compatibility for core database objects:

• Tables and Relational Schemas: Table definitions, field data types, validation rules, composite indexes, and referential integrity constraints generally carry over unchanged in MS Access 2024.
• Standard Queries: Standard SQL queries—including SELECT, UPDATE, INSERT, DELETE, and multi-table inner/outer joins—execute normally through the database engine.
• MS Access Forms and Controls: Native MS Access forms, text boxes, combo boxes, list boxes, tab controls, subforms, and navigation menus retain their layouts, conditional formatting, and standard event triggers.
• Reporting Layouts: Report groupings, running sums, pagination logic, and print routines transfer cleanly into the new version.
• Core Business Logic (Pure VBA): Algorithmic VBA code that manipulates recordsets, runs string calculations, and processes business logic continues to execute without modification, provided it does not interact with external operating system pointers or unsupported third-party libraries.

What Breaks: 32-Bit vs. 64-Bit Office Architecture

The primary obstacle during an upgrade from MS Access 2016 to MS Access 2024 is the shift in Office bitness. When Office 2016 was originally deployed, Microsoft recommended the 32-bit edition for general compatibility with existing add-ins. Today, Microsoft 365 and Office 2024 install as 64-bit by default.

When a 64-bit version of MS Access opens a database file created in a 32-bit environment, the Visual Basic for Applications engine (VBA7) enforces strict memory pointer rules. If your codebase calls external Windows API functions or utilizes legacy libraries, the application will throw immediate compile errors.

Windows API Declare Statements, PtrSafe, and LongPtr

In 32-bit Windows, memory addresses and window handles (HWND, HDC) are 32 bits wide and stored in standard Long integers. In 64-bit Windows, memory addresses are 64 bits wide. Passing a 32-bit Long to an operating system function expecting a 64-bit address can cause memory corruption, data truncation, or immediate application crashes.

To ensure safety, 64-bit MS Access requires the PtrSafe keyword in every Declare statement. Furthermore, any parameter or return value that represents a memory address, pointer, or window handle must be typed as LongPtr. The LongPtr data type is dynamic: it resolves to a 32-bit integer in 32-bit Office and a 64-bit integer in 64-bit Office.

Code Example: Converting API Declarations with Conditional Compilation

To allow a single front-end source file to run across both 32-bit legacy workstations and 64-bit MS Access 2024 environments, wrap your API declarations in #If VBA7 conditional compilation blocks:

' =========================================================================
' EXAMPLE: Windows API declaration for GetTickCount and FindWindow
' =========================================================================

#If VBA7 Then
    ' Code runs in VBA 7 (Office 2010 through Office 2024, both 32-bit and 64-bit)
    ' PtrSafe is required for 64-bit compilation.
    ' Handles and pointers use LongPtr; numeric counters remain Long.
    Private Declare PtrSafe Function GetTickCount Lib "kernel32" () As Long
    Private Declare PtrSafe Function FindWindow Lib "user32" Alias "FindWindowA" ( _
        ByVal lpClassName As String, _
        ByVal lpWindowName As String) As LongPtr
#Else
    ' Legacy fallback for VBA 6 (Office 2007 and earlier)
    Private Declare Function GetTickCount Lib "kernel32" () As Long
    Private Declare Function FindWindow Lib "user32" Alias "FindWindowA" ( _
        ByVal lpClassName As String, _
        ByVal lpWindowName As String) As Long
#End If

Compiled Binary Incompatibility (.ACCDE Files)

An .accde file compiled in 32-bit MS Access will not open in 64-bit MS Access, and an .accde compiled in 64-bit MS Access will not open in 32-bit MS Access. Because .accde files strip the editable VBA source code and retain only precompiled machine code, each architecture requires its own compiled binary.

If your organization operates a mixed fleet during rollout—where some users remain on 32-bit MS Access 2016 while others migrate to 64-bit MS Access 2024—you must maintain two separate compiled .accde distributions generated from the same underlying .accdb source file.

ActiveX Controls and Third-Party Add-Ins

Many applications built during the Access 2000–2016 era rely on common 32-bit ActiveX controls (.ocx files).

The standard Windows Common Controls (such as TreeView, ListView, and ProgressBar) have 64-bit versions installed alongside 64-bit Office. However, legacy controls such as the Microsoft Date and Time Picker (MSCOMCT2.OCX) and the Microsoft Common Dialog Control do not have 64-bit editions.

• 64-bit MS Access cannot load 32-bit in-process ActiveX DLLs or OCX components.
• If your application relies on MSCOMCT2.OCX, forms will fail to open or will throw missing control errors under 64-bit MS Access.
• Remediate these controls by switching to native MS Access controls (such as the built-in calendar picker available for date fields) or replacing obsolete controls with standard MS Access subforms and clean VBA code.

ODBC Drivers, DSN-Less Connections, and ACE Providers

If your MS Access application connects to external SQL databases (such as Microsoft SQL Server or PostgreSQL), the ODBC drivers installed on the client machine must match the bitness of MS Access:

• 64-bit MS Access requires a 64-bit ODBC driver, while 32-bit MS Access requires a 32-bit driver.
• System or User DSNs are not strictly required. In production environments, Help4Access recommends using DSN-less connection strings embedded directly in your VBA connection routines or linked table definitions. DSN-less connections avoid the need to manually configure administrative DSNs on every user workstation.
• Be aware that newer drivers, such as ODBC Driver 18 for SQL Server, enforce connection encryption by default (Encrypt=yes). If your target database server does not have a trusted TLS certificate installed, connection attempts can fail until the connection string is configured to trust the server certificate (TrustServerCertificate=yes) or proper certificates are deployed.
• External tools reading MS Access tables (such as automated Python scripts, reporting tools, or Microsoft Excel workbooks using the ACE OLEDB provider) must match the bitness of the calling tool itself, not the bitness of MS Access. A 64-bit reporting utility requires the 64-bit ACE OLEDB provider, even if MS Access on that machine is 32-bit.

File Format Checks: .MDB vs. .ACCDB

Before upgrading your runtime environment, audit your database file formats:

If your system still runs on .mdb files:

1. Identify Access 97 Files Early: MS Access 2024 cannot open Access 97 .mdb files directly. You must open and save them in an intermediate version (such as Access 2003 or Access 2010) before opening them in MS Access 2024.
2. Review User-Level Security (ULS): User-level security remains functional within Access 2000–2003 .mdb files running under modern versions. However, user-level security does not exist in the .accdb format. When converting an .mdb to .accdb, security must be established through Windows NTFS folder permissions or by migrating tables to SQL Server with database-level user authentication.
3. Check for Jet Replication: If your application uses legacy Jet database replication to synchronize branch offices, note that replication is not supported in .accdb.
4. Always back up the original database file before attempting any conversion.

Running Access 2016 and Access 2024 Side by Side

During an enterprise migration, organizations rarely switch every workstation on the same day. However, installing multiple Click-to-Run versions of Microsoft Office on the same Windows installation is generally blocked by Microsoft’s setup engine.

To validate your application and manage a controlled transition, consider these two practical paths:

1. Dedicated Test PCs: Set up a dedicated physical test workstation equipped with the new 64-bit Office 2024 or Microsoft 365 build. Lead operators and developers can thoroughly test compiled forms, complex queries, and reports in an isolated environment while daily business operations continue unaffected on existing MS Access 2016 computers.
2. Microsoft 365 Access Runtime: For staff who only need to run the application—and do not design forms, build queries, or edit VBA code—Microsoft provides the free Microsoft Access Runtime. Because it is also a Click-to-Run installer, it can be deployed to dedicated workstations that have no other Office versions installed, allowing staff to run compiled .accde files without licensing overhead.

A Low-Risk Upgrade Sequence

To prevent unplanned downtime and ensure business continuity, Help4Access recommends executing the upgrade using this structured eight-step sequence:

[ 1. Inventory & Dependencies ] ──▶ [ 2. Backup & Sandbox Copy ] ──▶ [ 3. Compile in Access 2024 ]
                                                                             │
[ 6. Pilot Group Testing ]     ◀── [ 5. DSN-Less & Reference Check ] ◀── [ 4. Fix PtrSafe & API Calls ]
            │
            ▼
[ 7. Planned Dual-Build Cutover ] ──▶ [ 8. Post-Cutover Rollback Window ]

1. Comprehensive Inventory: Document every front-end and back-end database, active user counts, mapped network paths, external data connections (QuickBooks, ERP, SQL Server), and scheduled batch scripts. If the application contains server-side email automation, review our guide on Replacing Outlook Automation in Microsoft Access Before You Migrate.
2. Create a Full Sandbox Copy: Copy the production front-end and back-end databases into an isolated testing directory. Never perform initial compilation checks or code refactoring against live production data.
3. Compile Code in MS Access 2024: Open the sandbox front end on a test workstation running 64-bit MS Access 2024. In the VBA Editor, select Debug > Compile [Project Name]. The compiler will highlight every syntax error, missing library reference, or missing PtrSafe keyword.
4. Update API Declarations and Variables: Update all external Declare statements with PtrSafe and LongPtr, utilizing #If VBA7 blocks to maintain backward compatibility across 32-bit and 64-bit environments.
5. Verify References, Controls, and Connections: Navigate to Tools > References in the VBA Editor. Identify and replace any libraries marked “MISSING:”. Replace obsolete ActiveX controls (such as MSCOMCT2.OCX) with native MS Access alternatives, and verify DSN-less connection strings against SQL Server endpoints.
6. Conduct Structured User Testing: Have experienced department operators perform typical daily tasks in the sandbox environment: enter sample records, run complex billing summaries, export data to Excel, and generate PDF invoices.
7. Execute the Cutover with Architecture-Specific Builds: Schedule the production cutover outside of standard operating hours. Compile the 64-bit .accde in 64-bit MS Access 2024, and compile the 32-bit .accde in the MS Access version still used on legacy workstations. Distribute the 64-bit .accde to modernized workstations and the 32-bit .accde to remaining legacy machines.
8. Maintain a Rollback Window: Keep the archived MS Access 2016 environment and an untouched pre-cutover database snapshot available for a defined rollback window (typically 5 to 10 business days) in case unforeseen edge cases arise.

For additional strategies on safeguarding critical database operations during transitions, see our technical article on Microsoft Access risk mitigation and system stability.

When the Upgrade Is a Good Moment to Do More

Upgrading the runtime environment provides a natural inflection point to evaluate your database’s long-term health. While resolving 64-bit compatibility, teams often address secondary architectural improvements:

• Splitting Monolithic Databases: If your database still stores forms and tables inside a single file, split it into a front-end (_fe.accdb) and back-end (_be.accdb). Distributing individual front-end copies to user workstations improves stability and reduces corruption risks.
• Migrating Tables to SQL Server or Azure SQL: When the back-end file is approaching the 2 GB limit, when many people edit at the same time, or when you need stronger security and managed backups, migrating data to SQL Server provides enterprise-grade reliability. Review our architectural options in migrating Microsoft Access to the cloud.
• Establishing Standard Version Control and Runbooks: Documenting your table relationships, primary keys, core VBA routines, and cutover procedures in a formalized technical runbook ensures your internal IT team can support the system independently.

How Help4Access Helps

Help4Access has specialized exclusively in Microsoft Access database stabilization, migration, and modernization since 2006. As a Microsoft Solutions Partner with close to 800 accounts supported, our senior database architects help organizations upgrade legacy MS Access estates with minimal disruption.

We work alongside your internal IT and operations leadership to conduct a technical code audit, remediate 32-bit and 64-bit API declarations, replace deprecated ActiveX controls, and establish a staged cutover runbook. Your team keeps ownership and control of your systems and data. We hand over full documentation.

Frequently Asked Questions

Will my Access 2016 database open in Access 2024?

Yes. MS Access 2024 natively opens standard .accdb database files created in Access 2016, 2013, or 2010. Tables, standard queries, forms, and reports will generally display and function without conversion. However, if the database contains custom VBA code calling 32-bit Windows API routines or third-party ActiveX controls, it will require code remediation before running under 64-bit MS Access 2024.

Do I need 64-bit Office for Access 2024?

Not necessarily. 32-bit Office 2024 is still supported. If the application depends on 32-bit ActiveX controls or add-ins, staying on 32-bit can be the faster, lower-risk path. 64-bit is the better long-term direction when the code and controls can be updated.

What does “PtrSafe” mean and why is my code failing to compile?

The PtrSafe keyword signals to the 64-bit VBA7 compiler that a Windows API Declare statement has been reviewed and updated to handle 64-bit memory addresses safely. If an application containing legacy API declarations is opened in 64-bit MS Access without PtrSafe, the compiler blocks execution to prevent memory corruption. Adding PtrSafe and updating pointers to LongPtr resolves the compile error.

Can I install Access 2016 and Access 2024 on the same computer?

Generally, no. Microsoft’s Click-to-Run installation technology prevents two different versions of the primary Office suite from coexisting on the same Windows operating system installation. To test both versions side by side, organizations typically use a separate dedicated test PC or the free Microsoft Access Runtime on computers with no other Office version installed.

Should I convert my .MDB file to .ACCDB?

Usually, yes, after testing. The .accdb format supports modern encryption, calculated fields, attachment storage, and modern Office integration. However, verify two important caveats before converting: Access 97 .mdb files must first be converted in an intermediate version before opening in MS Access 2024, and legacy User-Level Security (.mdw workgroups) does not exist in .accdb and must be replaced with folder-level or database-level permissions.

Is this upgrade a good time to move my data to SQL Server?

Upgrading the runtime is an ideal milestone to evaluate moving back-end tables to Microsoft SQL Server or Azure SQL Database when the file is approaching the 2 GB limit, when many people edit at the same time, or when you need stronger security and managed backups. The existing MS Access forms and reports remain the user interface, while SQL Server handles data storage, transactions, and automated recovery.

Schedule a technical consultation with Help4Access