Case Study
They built a business on Access. I gave it version control, safe deploys, and a future.
A client ran their entire operation on the same Microsoft Access database for three decades. It worked. But nobody could safely change it, nobody fully understood what it did, and the only way to work on it was to sit at one specific computer. I changed all of that without disrupting their daily work.
Before
One .accdb file, one Windows machine, no version control, no documentation of the VBA or business rules
After
212 files in Git, every Access form, VBA module, and business rule documented, safe deployment pipeline
How
Built remotely from a Mac via SSH, used AI to analyze 30 years of Access VBA, zero disruption to daily operations
The situation
This client's Microsoft Access database isn't a side tool. It IS the business. Invoices, payments, tax calculations, regulatory filings, every core operation runs through it. It's been in continuous use for over 30 years, and it handles all of it reliably. The business logic is written in VBA (Visual Basic for Applications), the programming language built into Access. Forms, reports, queries, macros, all wired together inside a single .accdb file.
But reliability created a different problem: the system became untouchable. All the knowledge about how the business works lived inside this one file, on one computer. There was no record of what had been changed or when. No way to undo a mistake. No way to test something before it went live. If someone made a bad edit, it could break calculations the entire business depends on.
And the only person who could work on it had to physically sit at that one Windows machine.
Every change to VBA code or Access forms was made directly in the live .accdb, with no way to undo mistakes
No version control: 30 years of modifications to the Access database with zero change history
Business rules buried in VBA event handlers and SQL queries with no documentation
Only one person could work on the Access database, and only from one physical Windows machine
Nobody had a complete picture of what the VBA code actually did across 82 forms, 62 reports, and 5 modules
One bad edit to a VBA module could break invoicing, tax calculations, or regulatory filings
This isn't a Microsoft Access database you can take offline to figure out. People use it every day to run the business. Any work on it had to happen around them, not through them.
What I built, and why it mattered
Made the system accessible remotely
The first problem was physical. The Access database lived on one Windows computer, and the only way to work on it was to be sitting in front of it. That meant nobody else could contribute, and work could only happen on-site.
I set up secure remote access (SSH and SMB file sharing) between my Mac and that Windows machine. Nothing exotic, but it meant that for the first time, someone could work on the Access database from anywhere without installing special software.
Made every change visible and reversible
Microsoft Access databases are single binary files (.accdb). Think of it like a Word document: you can open it and edit it, but there's no track changes, no version history, no way to see what's different from yesterday. You can't put an Access database in Git and get meaningful diffs.
I wrote a VBA export module that cracks open that binary and extracts every piece into individual, readable files: VBA modules as .bas files, Access forms and reports as text exports, SQL queries as .sql files, table schemas and relationships as JSON. 212 separate files from one opaque .accdb. Each one can be read, compared, and tracked in Git over time.
For the first time in 30 years, someone could answer the question: 'what changed, and when?'
Made changes safe
Before, making a change to the Access VBA code meant editing the live system directly. If something broke, you might not notice until a calculation was wrong or a report came out garbled. There was no safety net.
I built a deployment pipeline that works like a packaging system. Changes are prepared and reviewed on my machine first. Then they're bundled into an immutable deploy package with a JSON manifest listing exactly what's being modified. The system backs up every Access object it's about to touch before making any changes. It tries diff-patching first for surgical edits, and falls back to full module replacement if the patch doesn't apply cleanly.
Inside Access itself, there's now a simple admin form with a button that says 'deploy.' One click. VBA modules, forms, reports, queries imported cleanly. The whole process is logged so you can see exactly what happened.
Mapped every business rule in the system
This was the real unlock. Once the VBA code was extracted and readable, I used AI to analyze all of it at once: every Access form, every VBA module, every SQL query, every report. Five parallel research passes, each focused on a different layer of the system.
What looked like overwhelming complexity turned out to be 8 core business rules driving everything. Tax calculations with state-specific rounding. Account routing that splits by region. Role-based workflows. Payment validation. Transaction lifecycle rules. 82 forms, 62 reports, 20 queries, 36 tables, 5 VBA modules, all mapped and documented.
30 years of accumulated business knowledge, finally written down somewhere other than inside the Access database itself.
Designed a path forward
With every rule documented, I designed a migration path from Microsoft Access to a modern web application. The key principle: don't break what works.
The plan adds a modern web interface alongside the existing Access database. Access stays running, and its users keep working exactly as they do today. The new system reads from Access (via ODBC) and writes back to it. Nothing gets replaced until the client is ready. If the new system has a problem, the old one is still there, untouched.
This isn't a risky "rip and replace." It's a gradual Access database migration where the client is in control of the pace.
What came out of it
Extracted from a single .accdb into version-controlled source
Every VBA module, Access form, report, SQL query, table schema, and relationship, all tracked in Git with full change history.
Of Access VBA business logic, fully documented
8 core business rules identified across 82 forms, 62 reports, and 5 VBA modules. The client no longer depends on one person's memory to understand their own system.
To the people who use the Access database every day
Nobody's workflow changed. Nobody had to learn anything new. The Access database kept running the entire time this work was happening.
Where live-editing VBA in production was the only option
Every change to Access forms, VBA modules, and queries is now reviewed before it goes live, backed up automatically, and fully reversible.
What made this work
Respect what's already working
The instinct with a 30-year-old Access database is to say 'tear it down and start over.' That's the wrong call. This Microsoft Access application has been running a business reliably for three decades. The VBA code encodes real knowledge about how the business works. My approach was to build alongside it, not replace it. Extract, understand, add safety, then plan the transition on the client's terms.
AI as a research partner
AI didn't design the Access deployment pipeline or the migration architecture. I did. What AI did was read every line of VBA, every Access form event handler, every SQL query, and help me build a complete map of the business logic. That analysis would have taken weeks to do manually. The combination of my judgment about what matters and AI's ability to process an entire Access codebase at once is what made the project feasible.
The most valuable output was understanding
The Access deployment pipeline is useful. The Git version history is useful. But the most valuable thing I delivered was the business rule documentation. Knowing exactly what every VBA module, Access form, and SQL query does, not approximately, not from memory, but documented and verified. That's what makes everything else possible: safe changes to the Access database, confident migration planning, and the ability to bring in other developers to help.
Don't disrupt to prove value
It would have been easy to push for a big, visible rewrite. That's what a lot of consultants would recommend, because it justifies a bigger engagement. But that's not what the client needed. They needed safety, visibility, and a plan. The existing users never even knew this work was happening, and that's the point.
Does this sound familiar?
You have a Microsoft Access database that runs your business, but you're afraid to touch it
Your Access VBA developer is no longer around, and nobody knows how to make changes
You've been told the only option is a full rewrite, and that feels risky
You want to migrate from Access to a modern web application, but you can't afford to disrupt daily operations
You need to understand what your Access database actually does before you can decide what's next