Extending the Life of and Migrating VB6 / Access Business Apps — A Decision Table for Keep, Wrap, or Replace

“Part of our core system is still running on VB6,” or “the ledger we built in Access actually props up an entire department’s operations” — in consulting with small and mid-sized businesses, these two situations still come up with remarkably high frequency. What they share is that the person who originally built the thing has usually already left the company, and nobody can explain precisely why it still works. And yet it keeps running without breaking, so it inevitably slides down the priority list.

On this blog we’ve already covered individual technical topics such as what COM / ActiveX / OCX are, the keep/wrap/replace decision table for ActiveX / OCX, and the constraints and future of VBA. This article narrows the focus to the two biggest legacy assets still widely found in Japanese small and mid-sized businesses today — VB6 applications and Microsoft Access business apps — and puts together a practical guide for deciding whether to leave them as-is, extend their life by wrapping only part of them, or replace them. The decision framework follows the same “keep / wrap / replace” three-way choice used in the ActiveX / OCX article, but because the subject is different, the substance of the risks differs too, so this article focuses on the issues specific to VB6 and Access.

1. The bottom line, up front

• Support for the VB6 IDE and development environment itself officially ended in April 2008. There is no longer an official way to do new development or modifications.¹
• On the other hand, the VB6 runtime (msvbvm60.dll and friends) continues to work for as long as the Windows version it ships with is supported. The assumption that “an existing VB6 app will keep running, more or less, on supported Windows” still holds today, but it is entirely subordinate to Windows’ own support lifecycle.¹
• VB6 is 32-bit only; there is no native 64-bit compilation. On 64-bit OSes it runs inside WOW64, the 32-bit compatibility layer.¹ The moment you need to interoperate with a 64-bit-only DLL, SDK, or COM component, a single process can no longer do the whole job.
• The “Access Database Engine” (ACE), which reads and writes Access’s .mdb / .accdb files, has the same 32-bit/64-bit constraint. Only one bitness can be installed on a given machine, and it has to match the bitness of Office.² Since Office 2019 / Microsoft 365, the default installation has switched to 64-bit, so Access apps and ActiveX controls that were built on the old assumption of 32-bit can suddenly stop working the moment a machine is replaced.³⁴
• Having multiple people open a shared .accdb from a network folder at the same time is still common in the field today, but it remains a risk factor for corruption and performance degradation. Writes over the network can lead to data corruption if the connection becomes unstable.⁵ Once the size of the ledger or the number of simultaneous users grows, it’s time to consider upsizing to something like SQL Server.
• The decision axis is the same as it was for ActiveX / OCX: is this asset merely a screen, or is it a boundary that also holds business logic and data? If it’s stable and self-contained, leave it. If you only want to modernize part of it, wrap it. If UI or runtime constraints are actively holding the business back, replace it.

2. Where VB6 stands today — the runtime is alive, but development has no backing

Let’s start with the facts. Microsoft stated on April 8, 2008, that “the Visual Basic 6.0 IDE (and the Visual Studio 6.0 IDE) is out of support,” making clear that there is no longer an official way to build or maintain VB6 applications and strongly recommending migration to modern technology.¹

At the same time, that same announcement also states that the VB6 runtime remains supported for as long as the Windows version it ships with is supported. Existing VB6 apps are expected to “just work” on supported Windows versions, but the scope of support is limited to addressing serious regressions and critical security issues.¹ In other words, you can count on the minimal expectation of “it shouldn’t break when installed on a newer Windows,” but there is no support in the sense of “someone will add features or investigate individual problems when you run into trouble.”

Another point that matters in practice is that the VB6 runtime is a 32-bit-only file, and on 64-bit OSes it is only supported inside WOW64, the 32-bit emulation environment.¹ This means “a VB6 app can only ever live on as a 32-bit process going forward.” The moment you want to use a 64-bit-only measurement-device SDK or a new cryptography library, you fundamentally cannot load it into the VB6 process directly. In practice, the only way over this wall is to “split it out into a separate process and interoperate” — and the concrete setup described in “A COM bridge that calls a 64-bit DLL from a 32-bit app” applies as-is. When bridging from a VB6 app, the idea is the same: confine the 64-bit functionality to an out-of-process COM server or helper EXE, and have the VB6 side simply call into it.

Most VB6 apps carry ActiveX / OCX controls as screen components. The keep/wrap/replace decision for those components themselves is covered in detail in “How should you handle ActiveX / OCX today?,” so refer there for the individual controls embedded inside a VB6 app. This article focuses on the higher-level decision of how to treat the VB6 application as a whole.

3. Where Access stands today — file formats, ACE bitness, and the reality of shared folders

3.1 .mdb / .accdb and ACE bitness

Access data is stored in .mdb (the legacy format) or .accdb (2007 and later) files, and the runtime component that reads and writes them is the Access Database Engine (ACE, the successor to Jet). A bitness-mismatch problem comes up constantly in the field. The legacy Jet OLE DB provider is only available in a 32-bit build, and while ACE is available in both 32-bit and 64-bit builds, only one bitness can be installed on a given machine, and it must match the bitness of Office on that machine.² Visual Studio has the same issue: because Visual Studio 2022 and later run as a 64-bit process, cases are documented where data tools that rely on the 32-bit Access provider can no longer connect.⁶

Making things worse is a change in Office’s default. Office 2010 through 2016 installed the 32-bit build by default, but starting with Office 2019 and Microsoft 365, the default installation switched to the 64-bit build.³ On top of that, a 64-bit Office process cannot load 32-bit binaries, so existing 32-bit ActiveX controls and COM add-ins simply do not work under 64-bit Office.⁴ In other words, the common incident of “we’ve used the same Access app for years without issue, and then it suddenly stopped working after a PC replacement” is usually caused by Office’s default bitness switching, combined with ACE and any embedded controls failing to keep up with that switch. The troubleshooting procedure for this class of problem is laid out in “Why ActiveX stops working under Office 2024/Microsoft 365, and how to check for it.”

3.2 The risk of multi-user access on shared folders

Another classic Access app configuration is having multiple people open a single .accdb stored in a shared folder at the same time. At small scale this can run trouble-free for years, but it’s an inherently precarious setup. Writes over a network are documented as potentially causing write failures or file corruption if the connection becomes unstable,⁵ and there are long-documented cases of Access reporting disk/network errors when access to a file server becomes delayed or times out.⁷ The seed of corruption here — simultaneous access to a shared file — structurally resembles the contention patterns covered in this blog’s “The basics of exclusive control for file-based integration.” Access has built-in exclusive control via a lock file (.laccdb), but the more “connections prone to instability” you add — laptops over Wi-Fi, remote work over VPN, reconnecting after sleep — the higher the incident rate climbs.

The standard escape route once the number of simultaneous users grows, or processing gets heavier, is to move Access’s tables to SQL Server or Azure SQL and have Access reference them as linked tables. Using a tool such as SQL Server Migration Assistant (SSMA), you migrate the Access tables and then replace the original Access tables with links to the migrated tables — the screens (forms, reports, queries) stay exactly as they are, and only the data moves to a more robust backend.⁸ However, linked tables bring their own set of post-migration problems: aggregation processing can get slower (if a query depends on functions the server can’t execute, Access pulls the entire table down locally before processing it), and AutoNumber column behavior changes — situations that sometimes require replacing queries with pass-through queries or views.⁸ It has also long been recommended to split Access applications into a “back-end” database holding the tables and a “front-end” database holding the forms, queries, and macros.⁹ The critical point here is that splitting alone is not enough. The correct configuration is to keep only the back end (tables) in the shared folder, and to copy the front end onto each user’s own machine so each person runs it from their local copy. If you keep the front end as a single shared-folder file that everyone opens simultaneously, splitting has not actually removed the risk — you still have multiple people simultaneously reading and writing the screens, queries, and macros against a shared file, causing problems like worsening open-time delays and conflicts whenever the design changes. Whether you extend the life of a shared-folder setup or move toward SQL Server, the first checkpoint is whether both “sharing the back end” and “placing the front end locally on each machine” are already in place.

4. Decision table

Organizing VB6 and Access apps by usage pattern and risk factor produces the following decisions.

As a supplementary note, “wrap” in this table usually means modernizing only the data or only the boundary first, while keeping the screens and operational feel as they are, for now. Think of it not as rebuilding everything at once, but as a temporary landing point for tackling the highest-risk parts first.

To use the table, first narrow down the “target” row, then check whether your situation matches the “usage / risk factor” column. It’s important that, even for the same VB6 app, you’re free to split the decision by row or by feature — one screen might be kept, another feature wrapped. If you lump everything together as “it’s a VB6 app, so treat it all the same,” you end up dragging genuinely stable parts into the effort and ballooning the workload.

5. Applying the decision table by scenario

When you actually apply the decision table to real-world consulting cases, it tends to converge on roughly three patterns.

Scenario 1: An in-house-only VB6 inventory management app, with small change requests. If the target machines are fixed at a handful and the app never touches the network, the decision table leans toward “Keep.” The practical work here is simply to steadily pile up the risk-mitigation measures from Section 7 (backups, documentation, fixing the runtime environment). Unless there’s a real motivation to migrate to .NET, the cost-benefit often doesn’t add up.

Scenario 2: An Access ledger shared across multiple departments, with a growing number of users. A very common consultation is an Access app that was used by two or three people a few years ago, but has grown to around ten simultaneous users due to department mergers or business expansion. Here, the decision table leans toward “Wrap.” First check whether the back end is shared and the front end is deployed locally on each machine (Section 3.2); if not, split and redeploy first. Then, if there are signs of corruption or performance degradation (longer open times, .laccdb files lingering with locks that never release, and so on), switch to migrating the tables to SQL Server and referencing them from Access as linked tables.⁸ Because the screens can stay almost entirely as-is, you can harden the data layer while keeping users’ retraining costs low.

Scenario 3: A core VB6 business app whose developer has left, with a demand to move it to the web. When the source exists but nobody can touch it, and there’s now a demand to access it from outside the company, the decision table leans toward “Replace.” That said, the more central the app is to the business, the riskier a full rewrite done in one shot becomes. Following the procedure in Section 9 — starting with an inventory of business logic and carving out low-impact, independent functionality first — and proceeding via staged migration is the realistic path.

6. Common anti-patterns

Before applying the decision table, it’s worth first sharing the failure patterns that come up repeatedly in VB6/Access life-extension and migration projects, and checking whether you’re currently falling into one of them.

The two most frequent offenders in this list are leaving a bitness mismatch in place and letting a shared folder’s user count grow unchecked. Both share the trait that they aren’t “it will break today” problems — they surface only when some inevitable trigger eventually arrives, such as a machine refresh or growth in the number of users.

7. Realistic risk mitigation if you decide to keep it

Deciding to keep something as-is is often the realistic call, and there’s nothing wrong with that in itself. But the longer you continue with “it’s working, so don’t touch it,” the more the risk accumulates that nobody will be able to explain the underlying assumptions. At minimum, you should handle the following:

• Run generational backups mechanically. Because Access’s .accdb is self-contained in a single file, simply taking daily generational backups can absorb a substantial number of incidents. For VB6 apps, preserve the entire source set (.vbp, .frm, .bas, .cls) along with the dependent OCXs, DLLs, and registration information.
• Document the runtime environment’s assumptions as a hedge against the absence of a successor. Record the supported OS, Office bitness, and the required runtimes/dependent DLLs/registration steps, at least in enough detail that someone can figure out “what to check when it stops working on a new PC.”
• Deliberately pin the runtime environment. Since automatic updates to Windows or Office can change bitness or default settings and trigger incidents (Section 3.1), give the target machines a separate update policy and only roll out updates after they’ve been verified.
• Prepare a smoke test for a clean environment. Before deploying to a new machine, have a procedure ready to confirm that installation, registration, launch, and the main operations work on a fresh environment — this reduces the time lost to “it should work, but it doesn’t” every time you deploy.
• Consolidate call sites into one place. Rather than scattering VB6 COM calls or Access linked-table references throughout the whole app, narrowing the entry points as much as possible makes it clear where to start when you eventually wrap or replace things.

As a VB6-specific note, also consider preserving the development machine itself. The IDE installation media and license, developer editions of any external controls (OCX) needed for the build, and notes on the build procedure are assets that scatter even more easily than the runtime environment. Even if no changes are planned for now, keeping a single environment (such as a virtual machine snapshot) where the build can be reproduced greatly widens your options the moment a small fix becomes necessary.

If you want to maintain and modify existing Windows software without breaking it, that falls under Existing Windows Software Modification and Maintenance.

8. Realistic options when wrapping

“Wrapping” is the approach of confining the old asset inside a narrow boundary while presenting a new interface to everything around it. For VB6 and Access, this generally converges into the following three patterns.

(a) Call a VB6 COM component from .NET via COM interop. If a class module written in VB6 is exposed as an ActiveX DLL (or an EXE, if out-of-process), it can be called from .NET via COM interop. Because the VB6 side stays 32-bit, calling it from a 64-bit .NET app runs into the same bitness wall discussed in Section 2. Whether you align the caller to 32-bit or confine it to a 32-bit process as an out-of-process COM server can be worked out by simply flipping the setup described in “A COM bridge that calls a 64-bit DLL from a 32-bit app.” For the basics of COM itself, see “What are COM / ActiveX / OCX?”

(b) Migrate Access’s VBA logic to .NET / the web in stages. Some Access apps have business logic packed densely behind their forms, while others are mostly just data entry and list views — often both patterns exist within the same app. A realistic approach is to first inventory the VBA modules, carve out the pure calculation and validation logic that doesn’t depend on other systems into a .NET class library, and shift Access to calling it via COM or an intermediate web API. The constraints of VBA itself, and how far you should let it remain in VBA, are laid out in detail in “What is VBA? Constraints, its future, and when to replace it.”

(c) Replace only the UI first, keeping the data and logic intact. If the main complaint centers on an Access form that’s outdated, slow, or unusable from outside the company, one option is to leave the data layer (tables moved to SQL Server) and logic as they are, and replace only the UI with modern web or desktop technology. Combined with converting to linked tables as in Section 3.2, this makes possible a transitional dual-run setup where “the data lives in SQL Server, and both the old UI (Access) and the new UI look at the same data.” However, if Access’s VBA tightly couples the UI and logic together, this separation work itself cannot proceed until the inventory described in (b) has been done first.

Organizing these three options:

If you want to discuss boundary organization or migration direction first, that falls under Legacy Asset Reuse and Migration Support; for a design review before implementation, it’s Technical Consulting and Design Review.

9. How to proceed when replacing

You choose replacement when UI or bitness constraints are directly holding back the pace of the business, or when the absence of a developer makes maintenance itself unsustainable. Rather than launching straight into a full rewrite, following this order reduces incidents:

1. Verify data migration first. Migrations like Access → SQL Server involve differences that only surface after the fact — differences in when AutoNumber values are assigned, dependencies on functions that only exist on the Access side, missing unique indexes, and so on.⁸ Complete round-trip testing of the migration and the business scenarios against a copy of production data before moving on to the production cutover.
2. Inventory the business logic. Go through VB6’s forms/modules and Access’s VBA/macros/queries feature by feature, and distinguish “merely a screen” from “a boundary that also holds specifications.” This distinction is made the same way as for ActiveX / OCX, but for VB6 and Access, the business knowledge accumulated over years of operation is itself an asset, which makes discovery inherently more time-consuming.
3. Proceed via staged migration (the strangler pattern). Rather than replacing all functionality at once, carve out the lowest-risk, most independent functionality into the new system first, and run the old and new apps in parallel for a set period. Making it clear, feature by feature, which of the old or new data is authoritative, and deciding in advance the conditions for ending the parallel-run period, are the minimum requirements for keeping this approach from collapsing.
4. Replacing UI components or screen layout first makes things easier later. If a VB6 app uses ActiveX / OCX as UI components, replacing just those components with modern controls first makes it easier to estimate the later full replacement. For individual decisions, see “How should you handle ActiveX / OCX today?”
5. Prepare a way to observe things during the parallel-run period. While the old and new apps are running in parallel, prepare logs or a reconciliation mechanism that lets you compare which process produced which results. If you proceed with the cutover without any means of observation, you risk not noticing an incident — “the numbers stopped matching after switching to the new system” — until months later.

For a service covering everything from inventorying the specifications of old Windows apps to staged replacement, see Windows App Replacement (Japanese page).

10. Checklist for getting started on migration

Doing an inventory in the following order before applying the decision table (Section 4) considerably shortens the time it takes to settle on a direction.

1. Enumerate the targets. List VB6’s .exe / .dll / .ocx and Access’s .mdb / .accdb files by name, version, and location.
2. Confirm usage patterns. Check the number of users, whether there’s simultaneous access, whether it’s run from a shared folder, and whether usage is daily or monthly.
3. Confirm the runtime environment’s assumptions. Identify the supported Windows version, Office bitness, and whether the required runtimes, dependent DLLs, and COM registrations are present (Sections 2–3).
4. Confirm where the data lives and how large it is. For Access, capture file size, table count, record count, and growth rate — this becomes the basis for deciding whether to move to SQL Server.
5. Estimate the complexity of the business logic. Get a rough sense of the inventory effort from the line count of VBA modules, the number of macros, the number of forms, and the number of forms/class modules on the VB6 side.
6. Confirm whether backups and recovery procedures exist. Any target without backups in place, or that has never actually had a recovery attempted, needs that addressed before anything else, ahead of the decision itself.
7. Apply the results so far to the decision table. Once the targets and usage patterns are organized, check them against the table in Section 4 and provisionally decide, feature by feature, whether it leans toward keep, wrap, or replace.

Skipping this procedure tends to lead to a situation later where the effort has ballooned without anyone being able to explain what actually made it difficult.

11. Summary

The first thing to look at when deciding how to handle VB6/Access is not “how old is it,” but the following three points:

• Do you correctly understand that VB6 is a 32-bit-only runtime environment that has lost its IDE backing (Section 2)?
• Have you accounted for the fact that Access’s ACE and ActiveX are bound to Office’s bitness, and that shared-folder operation grows riskier for corruption as simultaneous access increases (Section 3)?
• Can you tell whether the asset in question is merely a screen, or a boundary that also holds business logic and data (the decision table in Section 4)?

Once these three points are sorted out, the path forward follows naturally: if you “keep” it, pin the runtime environment and don’t neglect backups and documentation (Section 7); if you “wrap” it, protect the data and logic via a 32/64-bit bridge or a staged move to .NET/the web (Section 8); if you “replace” it, verify the data migration and inventory the business logic first (Section 9). VB6 and Access are not assets to be thrown away indiscriminately just because they’re old — they are physical repositories of years of accumulated business knowledge. But you cannot indefinitely avoid the homework required to keep living alongside them: pinning the runtime environment, organizing boundaries, and verifying migrations. We recommend starting with the inventory in the Section 10 checklist.

Related Articles

• What Is VBA? Constraints, Its Future, and When to Replace It — Realistic Migration Patterns
• How Should You Handle ActiveX / OCX Today? — A Keep, Wrap, or Replace Decision Table
• What Are COM / ActiveX / OCX? — Explaining the Differences and How They Relate
• Why ActiveX Stops Working Under Office 2024/Microsoft 365, and How to Check for It
• A COM Bridge That Calls a 64-bit DLL from a 32-bit App
• The Basics of Exclusive Control for File-Based Integration — Best Practices for File Locking and Atomic Claims

Related Consulting Areas

Komura Software LLC handles inventorying and organizing migration direction for existing assets including VB6 and Access, life-extension design including 32-bit/64-bit bridges, and planning and implementing staged replacements.

• Legacy Asset Reuse and Migration Support
• Windows App Replacement (Japanese page)
• Existing Windows Software Modification and Maintenance
• Technical Consulting and Design Review
• Contact Us

References

</content>

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.