By Hiran de Silva
Paul Barnhurst recently raised the question—again—about whether VBA is obsolete, pointing to newer technologies like Office Scripts, Python, and Power Query. While that conversation continues to attract attention on social media, it also continues to miss a crucial and foundational technical truth: VBA cannot be obsolete as long as Excel on the desktop is built on the Component Object Model (COM).
Let me explain why.
COM Objects and the Purpose of VBA
Excel’s architecture on the desktop is built on COM—the Component Object Model. This means that everything in Excel (cells, charts, ranges, worksheets, workbooks) is represented internally as a COM object. And VBA is not just one of many tools—it is the native language designed to manipulate these COM objects directly.
Other technologies may offer workarounds, external connectors, or additional layers. But they are exactly that: external or layered. VBA, in contrast, is embedded and direct. It operates within the COM environment, not alongside it or on top of it.
If Microsoft were ever to abandon the COM architecture altogether, replacing Excel with an entirely new foundational model—perhaps one that is natively cloud-based—it would not mean the end of VBA’s purpose. It would simply mean the beginning of a new equivalent technology designed to manipulate that new model. Until then, VBA’s role remains fundamental and irreplaceable.
The Cloud Confusion
One reason why these misunderstandings persist is a lack of distinction between personal spreadsheet usage and enterprise-level spreadsheet processes.
Yes, there is a trend towards cloud-based workbooks for individual users, especially for sharing simple sheets via OneDrive or collaborating on Google Sheets. But that’s a completely different use case from enterprise-level spreadsheet systems that coordinate financial consolidation, reconciliations, or dynamic budget modeling across departments.
Currently, enterprise spreadsheets still require desktop Excel because the cloud version does not support the COM object model. It’s not a question of nostalgia or reluctance to change—it’s a matter of architecture.
A Submarine Analogy
To illustrate the absurdity of conflating these different paradigms, let’s borrow a metaphor.
Imagine someone claiming that because more people are enjoying snorkeling while on vacation—marveling at fish and coral reefs—therefore there is a growing trend that air travel will soon go submarine. After all, the underwater world is more exciting than just looking at clouds, right?
But anyone who understands the basic physics of air travel versus underwater navigation would instantly realize how absurd that is. Airplanes and submarines travel through completely different mediums, with completely different engineering requirements. One cannot simply replace the other because of a trend in leisure preferences.
This is exactly what’s happening in many Excel conversations online. Because some users enjoy Office Scripts or Python for their simple, individual needs, they extrapolate that the entire enterprise will soon abandon VBA and COM. But they misunderstand what Excel is at the enterprise level, how it works, and where it lives.
The Real Need: Client-Server Excel
What the enterprise actually needs is not “Excel on the cloud” in the way it’s often promoted—but a structured client-server architecture using desktop Excel as the client.
This is already possible, already scalable, and already working for those who understand how to use Excel as a front-end to a relational database system (using technologies like ADO and VBA). It’s just not being taught or talked about widely—especially not by social media influencers.
Conclusion
So no, VBA is not going anywhere. Not until the COM model disappears entirely—and that’s a much bigger leap than most people seem to realize. Until then, VBA remains the most powerful, direct, and embedded tool available for real-world enterprise Excel automation.
To ignore that is to propose building submarines to replace airplanes—because snorkeling is trendy.
Add comment