Microsoft Access VBA: What It Does, and Where It Becomes a Maintenance Liability

VBA (Visual Basic for Applications) is what turns a basic Access database into something that actually automates a business process. It's also, more often than any other single factor, what makes an old Access database too risky to keep touching. Both things are true at once — here's how to think about it.

This is one of five deep-dives into keeping Access running well (and knowing when it's time to move on) — part of our Microsoft Access Modernization: The Complete Guide. See the others: Access performance tuning, Access VBA, Access forms, reports & queries, Access security, auditing & backups, and Microsoft Access and HIPAA.

What does VBA actually do in an Access database?

It's the programming layer underneath Access's forms, reports, and macros — the code that runs validation when a form is saved, automates a multi-step process with one button click, generates a custom report on demand, or connects Access to another system (email, a file export, another database). Anything an Access database does that goes beyond basic data entry and simple queries is almost certainly running on VBA under the hood.

Why does VBA become a maintenance liability over time?

Three compounding reasons. First, undocumented complexity: VBA modules accumulate over years, often written by whoever was available at the time rather than a trained developer, with little to no documentation of what each routine does or why. Second, the "nobody dares touch it" problem: once the original author leaves, the code becomes a black box — it clearly works, but nobody currently on staff fully understands it, so even a small necessary change becomes a high-risk guessing game. Third, brittleness: VBA code written informally over time tends to lack proper error handling, so a small unexpected input (a blank field, an unusual character, a network hiccup) can cause the whole automated process to fail in a way that's hard to diagnose without deep familiarity with the code.

How risky is VBA, really, if it's "just working"?

The risk isn't that it stops working today — it's the accumulating cost of every day it keeps running unreviewed. Every VBA routine represents business logic your company depends on, sitting somewhere nobody can confidently modify, extend, or even fully explain. That's fine right up until you need to change a business process, add a new requirement, or the one person who understood it leaves — at which point what looked like a stable, working system turns out to be a single point of failure. It's also worth naming the security angle directly: VBA macros are also Access's largest malware attack surface if a file is ever shared or opened outside a trusted network, since macro-enabled files are a known vector for exploitation.

Should I try to document existing VBA rather than replace it?

It's worth doing regardless of your long-term plan — documenting what the existing code does, even roughly, immediately reduces the "nobody understands this" risk and makes any future decision (keep, tune, or migrate) better informed. But be honest about the limits: documentation reduces risk, it doesn't remove Access's underlying platform ceilings. If the VBA is encoding genuinely complex, valuable business logic, a proper code review (even without an immediate migration) is worth doing on its own, both to reduce risk and to make sure that logic is preserved accurately whenever a migration eventually happens.

What happens to our VBA logic during a migration?

It gets reviewed and reimplemented as proper application logic in the new system — not copy-pasted, but rebuilt with the same business rules, this time with real error handling, documentation, and testing. This is deliberately treated as one of the highest-value, highest-care steps in any migration we run, because that VBA code represents years of accumulated business knowledge that's easy to get subtly wrong if it's rushed. See our fuller breakdown of what a modernization project actually involves.

Is there a way to reduce VBA risk without a full migration?

Yes, short of a full rebuild: get the existing logic documented, add basic error handling to the routines that fail most often or most visibly, and make sure more than one person on your team has at least a working understanding of the critical macros. None of this removes Access's structural limits, but it meaningfully reduces the "one person leaves and nobody can touch this again" risk while you decide on a longer-term plan.

Not sure whether tuning is enough or it's time to migrate? Our instant estimator gives you a ballpark either way, or request an assessment and we'll give you an honest read.