Office Scripts vs. VBA: Which should you use in Excel?

Before I really knew Python, and before Office Scripts came along, I used VBA to format data and send emails. It let me take a process I was tired of repeating and make Excel do the work.

And my use of it was modest. I’ve seen colleagues build amazing tools in VBA, including derivatives pricing tools and far more elaborate applications than most people picture when they hear the word “macro.”

So when somebody asks whether Office Scripts makes VBA obsolete, I think the useful place to start is the work itself. What needs to happen, where does it need to happen, and what would make it easier to support?

VBA grew up with the desktop

VBA stands for Visual Basic for Applications. It comes from the era of desktop Office, local files, and shared network drives. For a business user, being able to record actions, inspect the code, and turn a workbook into a small application was revolutionary.

The appeal is still easy to understand: you already know the business process, you already work in Excel, and now you can teach it to repeat that process. Microsoft’s introduction to the Visual Basic Editor describes that same progression from recording to creating and editing macros.

VBA can reach deeply into desktop Excel. It can support custom functions, forms, workbook events, and connections to other desktop applications. Those capabilities are also dependencies: code that relies on Windows-specific components will not automatically work on a Mac. And Excel for the web cannot run VBA macros.

The maintenance follows the files

When VBA code lives inside a workbook, fixing your copy does not update all the copies people saved last month. Someone needs to own the code, distribute changes, and test it against the desktop environment people actually use. A managed add-in or centrally maintained workbook can improve that arrangement. “VBA always has to be updated by hand on every machine” would be too sweeping.

Keeping a process on approved local systems can also be useful when the data is not meant to move into a cloud service. But local does not automatically mean secure. The permissions, source of the code, and way it is maintained still matter.

There is a large body of VBA examples and accumulated experience to draw on. I think about it the way I think about long-lived tools such as COBOL in business systems or Fortran in numerical computing: useful code does not become worthless because a newer language appears. I expect VBA to remain part of the Excel landscape for a long time. That is my expectation, not a promise about Microsoft’s roadmap.

Why macro attachments raise security flags

A macro-enabled workbook can carry executable code. That makes it more than a container for numbers. A malicious macro can misuse the permissions available to Excel, including access to files or other resources on the computer.

This is why an unexpected spreadsheet attachment that asks you to enable macros deserves scrutiny. Microsoft blocks macros from internet-sourced files by default in affected Office versions on Windows because attackers have used them to deliver malware and ransomware. The warning is a protection, not just an annoying obstacle to opening a report.

Office Scripts grew up with the cloud

Office Scripts became generally available in Excel for the web in 2021. Its starting point is a different workplace: shared files, browser access, and processes that connect Microsoft 365 services.

Office Scripts is an automation feature that uses TypeScript. TypeScript builds on JavaScript and adds type checking. Office Scripts then gives you an Excel-specific set of commands, such as working with a workbook, table, or range. Microsoft’s scripting fundamentals explains that relationship.

That JavaScript connection is useful, but a random JavaScript tutorial will not teach you the ExcelScript API. My experience is that you have fewer directly relevant examples to choose from than with VBA. Start with Microsoft’s Office Scripts examples, then use broader TypeScript resources to understand the language.

You can record actions or write a script that formats a report, adds formulas, checks required columns, or organizes worksheets. Office Scripts also runs in supported Excel versions on Windows and Mac. You can run a script yourself without Power Automate; add a flow when you need scheduling or steps across services.

A more controlled environment, with sharing boundaries

Office Scripts does not have VBA’s general access to the host desktop. That narrower reach removes some of the risks and some of the capabilities. Microsoft’s VBA and Office Scripts comparison is a useful reference for those tradeoffs.

I think of the organizational sharing model as a walled garden. Sharing a script with coworkers can be convenient, and a script stored in SharePoint can be owned by the team. Linking a script to a workbook is not the same as embedding VBA inside the file. See Microsoft’s script storage and ownership guidance.

The boundary becomes noticeable when you teach, consult, or work across organizations: built-in script sharing outside an organization is not allowed. You can still share the source code, as I do in tutorials, so someone can review it and create their own script. That is different from giving them access to your managed script.

The controlled environment does not make every script harmless. A script can still change or delete workbook data. Some Excel-run scripts can also make external web requests within documented limits. Review the code, permissions, and destinations, just as you would for any business automation.

Power Automate handles the wider workflow

Office Scripts handles workbook actions. Power Automate handles the trigger and the steps between services. Pair them and you can run work in the cloud without leaving your laptop open. For example:

1. An email arrives with an expected attachment.
2. A flow checks the sender and file type, then saves a supported Excel attachment to an approved OneDrive or SharePoint location.
3. An Office Script checks the workbook’s structure and formats its report table.
4. The flow sends a notification or routes the result for review.

The email and file handling belongs in the flow; it is not the Office Script reaching into desktop Outlook. A PDF or arbitrary attachment would need its own extraction step. Microsoft’s Office Scripts overview explains the connection to scheduled and email-triggered flows.

This is where low-code tools become useful: you can assemble much of the process visually and use a small script where you need more control over Excel. Check licensing, platform limits, and administrator access first. Using Office Scripts through Power Automate requires a business Microsoft 365 license, and connectors can bring additional requirements.

A cloud schedule also needs an owner, working connections, and a way to handle failures. I would test the flow with Excel closed, confirm the actual output, and make a failed run visible to whoever maintains it. A schedule is a useful trigger, not a guarantee that every report will arrive correctly and on time.

The Power Query catch

Power Query is often my first choice when the central job is importing, combining, and cleaning data. VBA or Office Scripts can help with the workbook actions around that process. But a manual refresh and a cloud-triggered script are not interchangeable.

So a script containing “Refresh All” is not a general solution for scheduling Excel Power Query refreshes. Test your exact source and check a changed value or source timestamp, rather than relying only on the flow’s success indicator. See Microsoft’s Power Automate refresh limitations.

Depending on the source, the better design may be a service with supported scheduled refresh, or a flow that retrieves the data and passes it into a workbook for a script to process. Work out that data path before investing in a VBA-to-Office-Scripts conversion.

How I would choose

My default for a new cloud-oriented workflow would be to investigate Office Scripts first. For an established desktop application, I would begin by understanding the VBA. The deciding question is what improves the work and its maintenance.

Where Copilot fits

Copilot can be a useful coding partner: ask it to explain unfamiliar code, draft a small routine, identify dependencies, or suggest test cases. Microsoft’s Copilot guidance includes coding assistance and reminds users to review generated output. The available experience varies by account and product.

For a migration, I would start with a prompt like this:

Use approved tools and anonymized examples, then test the proposed code in a copy. A procedure that manipulates cells may translate reasonably well. A procedure built around desktop Outlook, UserForms, or workbook events needs a different design, not just new syntax.

There is still a reason to use deterministic tools. Once we agree on the rules, I want the automation to apply those same rules each time. AI can help us build and improve that code. It does not remove the need for explicit logic, known inputs, and checks on the output.

Deterministic does not mean infallible. Bugs, changing source data, and broken connections still exist. It means we can inspect the steps, test the behavior, and understand what changed. I explore this further in how to validate AI-generated Excel reports with Office Scripts.

Keep learning

• Understand function main() in Office Scripts for a closer look at a script’s starting point.
• Share your Office Scripts for my walkthrough of practical distribution options.
• Get started with Power Automate for Excel for a hands-on introduction.
• Microsoft’s Office Scripts and VBA comparison for platform and feature differences.
• Microsoft’s Power Automate troubleshooting guide for refresh behavior and other execution differences.

Technical details checked October 7, 2026. Microsoft 365 capabilities and licensing can change; use the linked Microsoft documentation when planning a rollout.