How a 1990s desktop database quietly evolved into today’s low-code and AI orchestration platforms
Thanks to my good friend, Fabrice, who shared an article called “Why Microsoft Access is dying (and what is replacing it).” Fabrice knows I was a big fan of Access back in the day. But the article made me think about how much things have progressed, while staying grounded in the same patterns.
Between 1997 and 2000, I was at Marconi. I built an Access database that documented an entire nationwide SDH telecommunications network. It tracked circuits running over STM links, switches, fiber routes, and network capacity allocations. Engineers would use it to track circuits in the live network. Network designers could query it for spare slots and available capacity.
The whole thing ran on a shared drive with dozens of people hammering it. No enterprise architecture committee. No six-month requirements phase. Just me, two telecom consultants who knew what needed tracking, and shipping something that worked.
I did it again for a medical supplier: purchase orders linked to inventory, expiry date tracking, automatic reorder flags. Then again for myself as a teacher: timetables that didn’t double-book instructors, sales call logs, class evaluations feeding into custom progress reports. One button, done.
I could go from Excel chaos to a working system in a weekend. Normalize the schema Friday night, build the forms Saturday, wire up the automation Sunday. Monday morning, engineers were using it.
That’s what “citizen developer” meant before it became consultant-speak. Domain experts building their own tools because we understood the problem better than any IT department could.
The same principle applies to Gen-AI today. Subject matter experts who understand the actual work are essential for shaping AI systems that solve real problems. But domain knowledge alone isn’t enough; you also need data literacy, security awareness, and architectural thinking. You can’t outsource domain knowledge to a prompt engineer or a data scientist who’s never tracked a circuit or managed a classroom. But you also can’t ignore the technical guardrails that prevent fragile, unmaintainable systems. The expertise has to come first. The tools and technical rigor follow.
What Made Access Revolutionary
When Access shipped in 1992, it solved a problem most people don’t remember: businesses needed custom software, but IT departments moved at geological speeds and cost a fortune. Spreadsheets couldn’t handle relationships. Desktop databases like dBASE required actual programming.
Access gave us four things in one package:
| What you needed | What Access gave you |
|---|---|
| Data storage | Tables with relationships |
| Business logic | Queries and VBA |
| User interface | Forms you could drag-drop |
| Reporting | Print-ready outputs |
That delivery speed mattered. Domain experts could solve their own problems without waiting for IT budgets or vendor implementations.
The 80/20 Pattern Emerges
Access didn’t just empower domain experts. It created an entire consulting ecosystem. Hundreds of companies built businesses helping organizations bridge the gap between “I built something that works” and “I need this to scale securely.”
A pattern I observed repeatedly: domain experts could solve 80% of their problems themselves. A plumber tracking jobs, estate agents managing property leads, consultants organizing client records. They’d build the core system over weekends, just like I did. Access consultants got called for the other 20%: VBA optimization, SQL Server migrations, multi-user architecture.
These weren’t traditional programmers. Many Access consultants were business analysts or power users who learned VBA and database design because they understood both the domain and the technology.
I’m seeing a similar trajectory with AI tools today. Power Platform, n8n, and LangChain let domain experts build much of what they need. But when you hit RAG complexity, governance requirements, or enterprise integration, you need someone who understands both the domain and the architecture.
That’s not a failure of the tools. It’s a pattern repeating. The Access consulting industry thrived for years. The AI consulting industry is just getting started.
Why Access Hit the Wall
Access had problems. That 2GB file limit hit me every year at Marconi. Corrupted databases, manual splits, repair rituals. Multi-user editing over a flaky LAN was Russian roulette. Windows-only meant no mobile, no web, no future.
VBA gave me incredible power but zero governance. My scripts lived in my head. When I left? Good luck to whoever inherited it.
The real killer was being trapped on Windows desktops. By the mid-2000s, people needed to check inventory from warehouse floors, log tickets from tablets, access data from browsers. Access couldn’t follow.
And then regulations caught up. GDPR, PDPA, sector-specific compliance. Suddenly everyone cared about audit trails, row-level security, data lineage. Access had none of that baked in. You could hack it together with VBA, but that just proved the architecture was wrong for the era.
How Modern Platforms Address Access’s Limitations
What happened next wasn’t death. It was evolution driven by cloud, mobile, and compliance requirements.
Microsoft didn’t kill Access. They built Power Platform to solve the problems Access couldn’t and then created migration paths:
| Access component | Where it went | What improved |
|---|---|---|
| Tables | Dataverse, SQL databases | No size limits, proper transactions |
| Forms | Power Apps, Retool | Mobile, web, actual security |
| VBA logic | Power Automate, n8n, Zapier | Thousands of integrations |
| Reports | Power BI, Looker | Real-time dashboards, ML |
Microsoft even built migration wizards that scan your old .accdb files and generate Power Apps skeletons. Whether Power Platform was intentionally designed as “Access 2.0” or simply evolved to solve the same problems that Access addressed, the functional lineage is clear.
Outside the Microsoft ecosystem, you see similar patterns: Airtable is Access redesigned for teams who expect Slack-level UX. Notion is Access if it grew up in the age of collaborative documents.
Where AI Layers On Top (In Workflow Automation)
Here’s where it gets interesting for me now, building AI systems in the workflow automation space.
Access logic was deterministic. Queries filtered data, VBA scripted workflows. In the AI orchestration systems I’m building, particularly for workflow automation and RAG applications, the AI doesn’t replace that logic. It layers on top of it.
You still need the structured foundation: SQL enforcing transactional integrity, Power Apps validating inputs, n8n routing data between systems. That’s the skeleton.
Now? The system pulls the same structured data, but feeds it to an LLM: “Here’s the fault description, historical context from the vector store, and similar past incidents. Classify severity, draft a root cause analysis, and recommend next steps.”
The deterministic layer ensures reliability. The AI layer adds judgment and context. This hybrid approach is particularly effective in workflow automation and knowledge management systems—though other AI domains like computer vision or recommendation engines might take entirely different architectural approaches.
I see this hybrid pattern in my SOP automation work. Structured workflows in n8n handle the data pipes. Postgres with pgvector stores the knowledge. LLMs interpret and generate. It’s reminiscent of Access architecture. Deterministic foundations with intelligent processing on top. Now just scaled to handle meaning, not just tables.
But there’s a fundamental difference worth noting: Access logic was entirely deterministic and predictable. AI introduces probabilistic behavior that requires different testing, validation, and governance approaches. The architecture may echo Access, but the challenges are distinctly different.
The Governance Lesson We’re Still Learning
Access failed at governance because I was builder, deployer, and owner all at once. My VBA lived on my hard drive. Documentation lived in my head. When I moved on, the systems became mysteries.
Modern AI governance frameworks (AIGP, ISO standards, NIST) address shadow IT problems that Access exemplified; though these frameworks emerged from broader enterprise software governance concerns spanning SaaS sprawl, financial spreadsheet models, and regulatory compliance. Access was one symptom of a larger governance gap:
Separate who builds from who deploys from who oversees
Classify systems by risk and impact
Audit everything, including prompts and model decisions
Track the full lifecycle with proper observability
Shadow Access databases became shadow AI agents. Same fundamental problem, higher stakes given AI’s opacity and potential for bias.
Modern platforms try to fix this. Dataverse logs data lineage. Power Platform gates enforce approval workflows. n8n execution logs show every node run. We’re finally building the governance that Access-era tools never had.
Why This Matters Now
I’m writing this for both nostalgia and to understand how patterns from Access help interpret what we’re building today.
Power Apps isn’t just a form builder. It’s Access forms for the cloud era. Dataverse isn’t just a database. It’s Access tables that scale. n8n isn’t just workflow automation. It’s VBA if VBA could talk to the entire internet.
And AI orchestration in workflow contexts? That’s Access logic extended into language and knowledge; with the added complexity of probabilistic behavior.
When I teach people about AI implementation, the ones who adapt fastest are often those who’ve built systems before, even simple ones. They understand data modeling. They know when you need deterministic rules versus probabilistic judgment. They’ve learned the hard way that undocumented automation becomes unmaintainable.
Access helped many non-programmers learn to think in systems; understanding data structures, relationships, automation, and templates. While Excel arguably reached more people and taught similar concepts, Access gave its users deeper exposure to formal database design. That kind of systems literacy is valuable for AI work now.
Microsoft’s migration tools suggest continuity. Your 1999 database can become a 2026 AI-powered app. Not because Access was perfect, but because some of the underlying patterns remain relevant.
The 80/20 pattern I observed with Access seems to be repeating. Domain experts build the foundation. Consultants add the rigor and scale. Together, they ship systems that actually work.
