I’ve been in the trenches of Office automation for a long time. Between 1999 and 2004, my professional world revolved around VBA and complex “corporate identity” (huisstijl) implementations. Back then, we were doing things with Word and Excel that felt like magic.
By 2001, I was already integrating these workflows with the earliest versions of SharePoint. Back then, “integration” simply meant using SharePoint as a central hub for file storage and versioning—there were no automated workflows or complex logic. We used VBA to bridge the gap between the desktop and these early document libraries.
Fast forward to 2026, and I see something surprising: the world has moved to the cloud, but many organizations are still clinging to those same VBA macros. In this series, I’m documenting my journey of moving away from the “VBA safety net” and building a modern automation stack using Power Apps and Office.js.
Why Am I Doing This Now?
Having spent over two decades seeing how document requirements evolve, I’ve realized that the “old way” is no longer just old—it’s becoming a bottleneck.
We live in a world of hybrid work, zero-trust security, and cross-platform needs. Yet, I still see mission-critical templates that only work on a Windows desktop via a .docm file. It’s a gap that needs to be bridged.
However, I’ll be honest: I don’t have the full picture yet. While I know the requirements and the “old” logic inside out, transitioning to the modern stack (Power Apps, Office.js, and Power Automate) comes with its own set of hurdles. This blog series isn’t a polished manual; it’s a “build-in-public” log of my transition, the problems I find, and the solutions I’m testing.
The Challenge: High Standards vs. Modern Limits
Back in the early 2000s, “huisstijl” was about pixel-perfect precision. VBA gave us deep, almost surgical access to every corner of the Word object model to ensure that precision.
The challenge today is: Can we achieve that same level of professional automation using modern web-based tools?
- Office.js is the future, but it doesn’t have 1:1 parity with everything VBA could do. I’m currently discovering where those limits lie.
- Power Apps provides a beautiful, modern UI, but getting it to talk seamlessly to a specific Word document requires a completely different architectural mindset than the old UserForms.
- Security is much tighter now. We’ve moved from “just enable macros” to sandboxed environments and API permissions.
The Roadmap: Building in Public
I want to take you along as I figure this out. I’ll be sharing the “aha!” moments, but more importantly, I’ll be sharing the roadblocks I encounter.
Over the coming posts, we will explore:
- The Architecture: How do we replace a VBA UserForm with a Power App “Cockpit”?
- The Learning Curve: Shifting from the VBA object model to the JavaScript API.
- The Integration: Leveraging the modern SharePoint and Power Automate ecosystem (which has come a long way since 2001!).
- The Reality Check: Identifying what is actually possible and where we still need to find creative workarounds.
Join the Conversation
If you’ve been building Office solutions since the late 90s like I have, you probably feel the same tension between “the way we’ve always done it” and the “modern way.”
I’m currently in the middle of the “proof of concept” phase, and it’s been a reality check. In my next post, I’ll dive into the specific architecture I’m testing and the first major hurdle I ran into: deciding between a Word Add-in approach or a Power App-first workflow.
Are you still holding onto your macros for dear life, or are you ready to see how deep the rabbit hole goes? Let’s figure out the future of Word automation together.
Pingback: The Architectural Crossroads: Task Panes vs. Standalone Apps (Part 2) - KbWorks - SharePoint and Teams Specialist