In this fifth part of the “Excel Will Never Be Obsolete” series, we move from discussing VBA itself to the deeper architectural underpinnings of Excel: the Component Object Model—commonly known as COM. Understanding the future of Excel requires looking beyond individual languages or features like VBA, Power Query, or Office Scripts. It requires recognizing the architecture they are built on, and asking: what, exactly, would need to change for VBA to truly become obsolete?
The Architecture: Desktop Excel and the COM Model
Desktop Excel—still the dominant version in most enterprises—is built on COM. This model, which dates back over 30 years, defines Excel’s objects: workbooks, worksheets, ranges, charts, and everything else VBA can manipulate. VBA’s entire purpose is to give users a way to programmatically control these COM objects. That’s not a matter of preference—it’s an architectural fact.
Now consider Excel on the web. This version is not built on COM. It runs on a completely different foundation—web server technology. And to manipulate it, we don’t use VBA. We use JavaScript (or more precisely, TypeScript in the form of Office Scripts). Why? Because web technologies require a completely different programming model.
This architectural divergence is not just theoretical. It determines what’s possible and practical in enterprise workflows. While Office Scripts may be growing, they are only relevant in the web-based version of Excel—currently used in a minority of serious enterprise scenarios.
The Reality: Desktop Excel Still Dominates
Let’s make some realistic estimates:
- Desktop COM-based Excel: 70%
- Excel for the web: 15%
- Excel for Mac: 15%
This is not a statistical survey, but rather an informed, practical assessment based on what’s used in enterprise workflows. Despite marketing narratives about “everything moving to the cloud,” the real story is more nuanced. Yes, Excel is increasingly being stored on cloud platforms like OneDrive or SharePoint. But that’s not the same as Excel running in the cloud in Enterprise-level solutions.
Enterprise Excel models that automate processes, integrate with databases, or handle reconciliation and reporting at scale still depend on the desktop Excel COM model. These models are coded in VBA. And they aren’t going anywhere anytime soon, because there is currently no viable replacement architecture that offers the same flexibility, power, and speed. Particularly on the cloud.
Could Microsoft Kill COM?
It’s possible. Microsoft has a history of radical reinvention: .NET was a major shift; Azure redefined cloud development; SaaS platforms are now central to their strategy.
If Microsoft were to rebuild Excel from the ground up on a new architecture—abandoning COM entirely—then yes, VBA would no longer function. That would be the true obsolescence of VBA. But it wouldn’t be VBA that’s obsolete. It would be COM that’s obsolete. VBA would simply be left behind with it.
However, even if such a transition happens, history suggests that Microsoft would provide a replacement scripting or automation language. That’s because the function VBA serves—programmatic manipulation of application objects—is essential. That function cannot become obsolete, only the means by which it is delivered might change.
What About Power Query?
There’s an important nuance here. Power Query is an incredible tool—but it’s not part of the COM model and cannot (as far as we know) be manipulated via VBA. Some might use this as evidence that VBA is limited. But that misunderstands the roles of the two tools.
Power Query is primarily an extract-transform-load (ETL) tool for retrieving data. It’s a read-only librarian. VBA, on the other hand, is a full programming language capable of reading from and writing to databases, automating UI workflows, and building end-to-end business applications. You can implement a client-server architecture with VBA and ADO. You cannot do that with Power Query alone.
So, if you’re building an enterprise budgeting model or a reconciliation tool or a multi-user reporting engine, which tool gives you more control, faster turnaround, and greater creative freedom? The answer is clear: VBA and ADO.
The Real Test: M Code vs. VBA
Here’s a thought experiment.
Take two groups of equally intelligent learners. One group is trained in M code (the scripting language behind Power Query), DAX, and other Power BI tools. The other group is trained in VBA and ADO. Then give both groups the same task: build a robust, scalable budgeting model that interacts with a central data source and allows for collaborative input and reporting.
Which group will succeed?
Which will deliver faster?
Which will find fewer limitations?
Which will actually be able to implement the business requirements without hacking around artificial constraints?
The answer is obvious to anyone who has worked in enterprise Excel: VBA wins hands down.
Conclusion: This Isn’t About VBA
This conversation isn’t truly about VBA at all. It’s about the future of Excel’s underlying architecture. Unless and until Microsoft abandons the COM model altogether, VBA remains not just relevant—it remains irreplaceable for enterprise-scale work.
Even if COM is replaced someday, the need for programmable control will persist. And something else—whether it’s a new scripting language, a visual tool, or a low-code environment—will take VBA’s place. But the function will live on.
So, don’t fall for the hype. Excel isn’t “moving to the cloud” in the way some imagine. And VBA isn’t obsolete—it’s embedded in the dominant version of Excel that powers real business processes every single day.
Add comment