Microsoft Access Migration & Modernization

An Access application that runs a real business process is a success story that outgrew its tool. Someone built it — a scheduling system, a quoting tool, a compliance register, an inventory tracker — because they needed it and IT didn’t have the bandwidth. It worked. So it grew. Now a department depends on it, the person who wrote it has moved on or is about to, and the whole thing lives in a single file on a network share that nobody is allowed to look at wrong. That isn’t a failure of Access. It’s Access being asked to be something it was never meant to be.

Where Microsoft Access fits — and where it stops

First, the thing most migration pitches get wrong: Microsoft Access is not end of life. It still ships with Microsoft 365, it’s still supported on Windows, and for its intended job — a single power user or a handful of people building a small data tool — it’s genuinely good at it. This isn’t a Visual FoxPro situation where the platform is dead and there’s nowhere to go.

The problem is fit, not support. Access was designed for the small end, and a business-critical app has crossed to the large end. The ceilings it runs into are architectural, and no version upgrade removes them:

Ceiling	What Access allows	What a real app needs
Database file size	Hard 2 GB limit per file	Grows with the business
Concurrency	File-share model; corrupts under real multi-user load	Dozens to thousands of concurrent users
Security	No true authentication or row-level access control	Real identity, roles, and permissions
Web / mobile	Access web apps retired by Microsoft in 2018	Browser and mobile access as standard
Maintainability	VBA, usually understood by one person	A codebase a team can safely change

None of these are bugs. They’re the boundary of what Access was built for. An application that has crossed that boundary is running on borrowed time — not because the software is unsupported, but because the business now depends on it doing things it was never designed to do safely.

What outgrowing Access actually means

The risk of a load-bearing Access app is concrete, and it shows up in a few predictable ways.

• Corruption is a when, not an if. A shared .accdb file accessed by several people over a network is the classic Access failure mode — a dropped connection mid-write, and the file is damaged. There’s a repair tool, but when the file that corrupts is the one running the business, “usually recoverable” isn’t a risk profile a company should accept.
• The 2 GB wall is fixed. Once the data crosses 2 GB, Access simply stops — and there’s no setting that raises it. Teams that hit this end up archiving live data just to keep the app running, which is its own kind of risk.
• There’s no real security. Access has no genuine authentication or row-level access control. Anyone who can open the file can, in practice, see and change everything in it. In a regulated data path, an unencrypted Access file with no audit trail is a finding waiting to be written.
• It’s a key-person dependency. The forms, the macros, and especially the VBA were usually written by one person, undocumented, over years. When they leave, the app becomes a black box the business is afraid to touch — and afraid to lose.

The migration options

There’s no single right move; there’s a right move for your application, and it turns on how much real business logic lives in the VBA and how many people depend on it.

• Split to SQL Server first, keep the Access front end for now. Move the tables into SQL Server and point the existing Access forms at them over linked tables. This removes the 2 GB and corruption risk immediately and is genuinely low-risk. It’s a stabilizing step, not the destination — the interface is still Access and still VBA — but it buys time and safety while you plan the real rebuild.
• Rebuild as a proper application — a web app for most cases — moving the data into a supported database and re-expressing the forms, reports, and VBA logic as maintainable code. The most common honest answer when the app is genuinely business-critical, because the value is in the behavior and the data, not the Access implementation.
• Replace with off-the-shelf software where the Access app does something a packaged product now does well, and migrate the historical data into it. The cleanest exit when the logic isn’t actually a differentiator.

The decision rarely turns on the data alone — moving tables to SQL Server is the well-understood part. It turns on the business logic bound up in the VBA and queries: the rules, the calculations, the workflows that took years to get right and that no one wrote down. That undocumented logic is what makes an Access migration a modernization project rather than a copy job.

Modernizing an Access app slice by slice

We treat the application the same way we treat any legacy system: not a single risky rewrite, but a sequence of small, reversible steps.

A strangler facade lets the legacy Access application and the modern path run side by side. We break the app into slices — a form, a report, a table and the logic bound to it — and before any slice carries live work, we prove it behaves identically to the legacy: same results, same state, reconciled record by record against the original Access data. AI-accelerated discovery reads the forms, the queries, and the VBA end to end and captures what the application actually does — including the undocumented logic the original author never wrote down, which on a mature Access app is most of the risk — under senior-engineer review. Work shifts only on green, rollback stays a flag away, and the Access file is retired only once nothing depends on it.

When the app doesn’t need a full rebuild

We won’t pretend every Access database is an urgent crisis, and we’ll say so. A small tool used by one or two people, with no compliance exposure and a file that isn’t near 2 GB, can reasonably keep running — and the split-to-SQL-Server step alone may be all it ever needs. Where a packaged product already does what the app does, buying beats rebuilding, and we’ll point you there rather than quote a build. The full rebuild earns its place when the Access app has become genuinely multi-user, when its data sits in a regulated path, when corruption would stop the business, or when the only person who understands it is leaving. Matching the effort to the actual value is part of the assessment, not an afterthought.

Where to start

The first step is small and bounded: understand what the application is really worth before committing to a path. A discovery call scopes how much business logic lives in the VBA, how the data is structured, how many people and systems depend on it, where the compliance exposure sits, and whether the right move is to split, rebuild, or replace — on evidence, not a sales pitch. Reach the team at sales@modernlift.ai.