What Is VBA? - Its Constraints, Its Future, When to Replace It, and Realistic Migration Patterns

In VBA consultations, these topics often come up tangled together.

• What is VBA in the first place?
• Macros are said to be dangerous - should we stop using them?
• Will it stop working in the future?
• Should we move everything to Office Scripts or Power Automate?
• Should our existing .xlsm and Access assets be kept or thrown away?
• Is it acceptable to run Excel in nightly batches or on a server?

This is not a topic that one answer settles cleanly. What you should look at first is not new versus old, but where it runs, who uses it, whether Excel / Access itself is the UI, and whether execution is unattended.

flowchart TB
    accTitle: The first axis to look at when judging VBA
    accDescr: A diagram showing that when deciding whether to keep VBA or replace it, the first things to look at are where it runs, who uses it, whether Excel or Access itself is the UI, and whether execution is unattended, rather than whether the technology is new or old.
    a0["New or old"] -.-> a1["Not the first axis to look at"]
    b0["The first axis to look at"] --> b1["Where does it run"]
    b0 --> b2["Who uses it"]
    b1 --> b3["Is Excel / Access itself the UI"]
    b2 --> b4["Is execution unattended"]

Figure 1: The axis for judging VBA is not old versus new but where it runs, who uses it, what the UI is, and whether execution is unattended.

In this article, we go in this order: what VBA is, where its constraints lie, whether it will become unusable, where replacement makes sense, and how to migrate in stages realistically. The content is based on Microsoft’s official information verifiable as of March 2026.¹²³⁴⁵

1. The Conclusion First

Lining up the conclusions in advance:

• VBA is an event-driven language for extending Office desktop applications. It is a technology premised on running inside Excel, Word, PowerPoint, Access, and so on.¹
• At least as of March 2026, no clear official Microsoft announcement that “VBA itself will be terminated soon” can be confirmed. What is happening now is less a “sudden full abolition” and more a change in which where it can be used and under what preconditions has become clearer.¹²³⁴
• Specifically, Excel for the web cannot create, run, or edit VBA. Also, macros in files from the internet are blocked by default.²³
• The real question today is therefore not “do we throw away all our VBA,” but which areas to keep in VBA and which to move out.
• In particular, processing that needs unattended execution, server-side execution, multi-user operation, browser support, central distribution, or strict auditing should not be carried by VBA alone. Microsoft itself does not recommend or support server-side automation of Office.⁶
• There is no single replacement destination. The realistic split: if Excel stays, offload processing to .NET DLLs or separate processes; for business flows on Microsoft 365, Office Scripts + Power Automate; for cross-platform extensions, Office Add-ins; and if Excel is no longer really the UI, move out to a Windows app or web app.⁴⁵⁶

In short, the practical view is that VBA is not a “technology about to drop dead” but a “technology whose right place is now well defined.”

flowchart TB
    accTitle: How to read the change that is happening now
    accDescr: A diagram showing that what is happening now is not a sudden full abolition but a clarification of where VBA can be used and under what preconditions, so the question is no longer whether to throw away all VBA but which areas to keep in VBA and which to move out.
    c1["Sudden full abolition"] -.-> c2["Not confirmed in official information"]
    d1["Clearer places and preconditions for use"] --> d2["The question changes"]
    d2 --> d3["Which areas stay in VBA"]
    d2 --> d4["Which areas move out"]

Figure 2: The question is not whether to throw everything away, but how to divide what stays and what moves out.

Knowledge map for this article

VBA is an event-driven language that runs inside the Office desktop apps. It cannot be authored, run, or edited in Excel for the web, and macros in files that came from the internet are blocked by default. That block can be worked around case by case through mechanisms such as Trusted Locations, Trusted Sites, and the Trusted Publishers store together with a code signing certificate. VBA is a poor fit for server-side automation of Office, and Microsoft recommends generating files directly in the Open XML format for unattended report generation. Old Declare statements sometimes do not run under 64-bit Office, and executing external .vbs files or depending on VBScript.RegExp can be affected by the phased deprecation of VBScript. There is no single replacement destination. The realistic approach is to split by responsibility, moving heavy business logic to a .NET DLL, cross-platform extensions to Office Add-ins, and workflows on M365 to Office Scripts and Power Automate.

flowchart LR
    accTitle: VBA constraints and where to move the work
    accDescr: Diagram showing that VBA is an extension language closed inside the Office desktop apps, its incompatibility with Excel for the web, the default macro block and the ways around it through Trusted Locations, Trusted Sites, and Trusted Publishers, the discouragement of server-side automation and the Open XML alternative, the constraints of bitness and VBScript dependencies, and the replacement destinations per responsibility in Office Scripts, Office Add-ins, and .NET
    vba["VBA (Visual Basic for Applications)"]
    excel_for_the_web["Excel for the web"]
    macro_block_policy["Internet Macros Blocked by Default"]
    zone_identifier["Zone.Identifier (Mark of the Web)"]
    trusted_location["Trusted Location"]
    trusted_site_zone["Trusted Sites / Local Intranet Zone"]
    trusted_publisher_store["Trusted Publisher Store"]
    code_signing_cert["Code signing certificate"]
    server_side_office_automation["Server-Side Office Automation"]
    open_xml_format["Open XML Format"]
    unattended_report_generation["Unattended Report Generation"]
    bitness_match_requirement["Bitness Match Requirement"]
    vba_64bit_migration["VBA 64-bit Migration (PtrSafe/LongPtr)"]
    com["COM (Component Object Model)"]
    activex["ActiveX"]
    ocx["OCX"]
    cross_platform_office_extension["Cross-Platform Office Add-in"]
    office_addins["Office Add-ins"]
    m365_cloud_workflow["Cloud Workflow on Microsoft 365"]
    office_scripts["Office Scripts"]
    power_automate["Power Automate"]
    vbscript_regexp_dependency["VBScript.RegExp / External .vbs Dependency"]
    vbscript_deprecation["VBScript Deprecation"]
    dotnet[".NET (Core and Later)"]
    vba -->|"incompatible with"| excel_for_the_web
    macro_block_policy -.->|"prevents"| vba
    zone_identifier -->|"may cause"| macro_block_policy
    vba -->|"configured by"| trusted_location
    vba -->|"configured by"| trusted_site_zone
    vba -->|"configured by"| trusted_publisher_store
    trusted_publisher_store -->|"requires"| code_signing_cert
    vba -->|"not recommended for"| server_side_office_automation
    open_xml_format -->|"recommended for"| unattended_report_generation
    server_side_office_automation -->|"not recommended for"| unattended_report_generation
    vba -.->|"requires"| bitness_match_requirement
    vba -.->|"requires"| vba_64bit_migration
    vba -.->|"uses"| com
    vba -.->|"uses"| activex
    vba -.->|"uses"| ocx
    vba -->|"incompatible with"| cross_platform_office_extension
    office_addins -->|"recommended for"| cross_platform_office_extension
    vba -->|"not recommended for"| m365_cloud_workflow
    office_scripts -->|"recommended for"| m365_cloud_workflow
    power_automate -.->|"uses"| office_scripts
    vba -.->|"requires"| vbscript_regexp_dependency
    vbscript_regexp_dependency -.->|"incompatible with"| vbscript_deprecation
    dotnet -->|"recommended for"| vba

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (23 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. What Is VBA?

VBA stands for Visual Basic for Applications, a variant of Visual Basic that ships with Microsoft Office. Microsoft’s official documentation also describes it as an event-driven programming language for extending Office applications.¹⁷

The important point here: it is closer to reality to see VBA not as a general-purpose application development platform, but as an extension language embedded inside Office applications.

flowchart TB
    accTitle: The right way to see VBA
    accDescr: A diagram showing that it is closer to reality to see VBA not as a general-purpose application development platform but as an event-driven extension language embedded inside Office applications.
    v1["VBA"] --> j1{"How should it be seen"}
    j1 -.->|"far from reality"| a1["General-purpose app development platform"]
    j1 -->|"close to reality"| a2["Extension language embedded inside Office apps"]
    a2 --> a3["Event-driven language that runs inside Office"]

Figure 3: VBA is not a general-purpose development platform but an extension language embedded inside Office.

In Excel, for example, it operates close to objects like these.

• Workbook
• Worksheet
• Range
• Buttons and forms
• Events on workbook open, save, and cell change

In other words, VBA’s strength is being extremely close to the screens, reports, and workbook structures of Excel and Access. A user opens desktop Office, clicks a button, processes data in local files or shared folders, and prints a report right there. For that kind of “automation that completes at the user’s desk,” it still has real strengths.¹

Real code is about this short. This is the smallest possible form, assigned to a button on a sheet.

' Place this in an Excel standard module. Intended to be called from a button on a sheet
Option Explicit

Public Sub ClearMeisai()
    Dim ws As Worksheet
    Set ws = ThisWorkbook.Worksheets("Detail")

    If MsgBox("This will clear row 2 and below on the Detail sheet. Are you sure?", _
              vbOKCancel + vbQuestion, "Confirm") <> vbOK Then
        Exit Sub
    End If

    ws.Rows("2:" & ws.Rows.Count).ClearContents
End Sub

Drop a shape or a form control button on the sheet, right-click it, choose Assign Macro, and pick ClearMeisai; from then on every press runs this code. What to notice here is that Excel objects such as ThisWorkbook, Worksheets, and Rows show up directly, with no conversion layer and no API call in between. That proximity is what “a language that runs inside Office” concretely means. Seen from the other side, a replacement target that loses that proximity cannot be written with the same number of steps.

Put the other way around, VBA’s natural territory was never servers, browsers, mobile, or multi-tenant web systems in the first place.

flowchart TB
    accTitle: VBA territory
    accDescr: A diagram showing that VBA sits close to the screens, reports, and workbook structures of Excel and Access and is still strong for automation that completes at the user desk, while servers, browsers, mobile, and multi-tenant web systems were never its natural territory to begin with.
    s1["Sits directly next to Excel objects"] --> s2["Automation that completes at the user desk"]
    s2 --> s3["Still a strong area today"]
    t1["Server / browser / mobile / web systems"] -.-> t2["Never its natural territory to begin with"]

Figure 4: Proximity to Office is the strength, and anywhere that proximity is not needed was never in scope.

3. Why Is It Still Used?

The reason VBA persists in the field is not simply “it’s old and stayed by inertia.”

First, Excel and Access tend to absorb not just data but the business procedure itself.

• Report appearance
• Print settings
• Input validation
• The order of monthly processing
• Per-department exception rules
• Operating procedures the field has been used to for years

When moving these to another system, “code porting” alone does not suffice. Appearance, operation, exceptions, and workflow are fused together, so VBA assets carry far more specification than they appear to.

flowchart TB
    accTitle: What VBA assets are carrying
    accDescr: A diagram showing that Excel and Access tend to absorb the business procedure itself, including report appearance, print settings, input validation, processing order, exception rules, and operating procedures, and that because appearance, operation, exceptions, and workflow are fused together, migration is not finished by code porting alone.
    e1["Excel / Access assets"] --> e2["The business procedure itself is baked in"]
    e2 --> f1["Report appearance and print settings"]
    e2 --> f2["Input validation and processing order"]
    e2 --> f3["Exception rules and operating procedures"]
    f2 --> g1["Code porting alone is not enough"]

Figure 5: VBA assets carry not only code but the whole business procedure and the way it is operated.

Also, because VBA is close to the Office object model, it takes very few steps to operate the very Excel in front of the user and return results. This closeness matters when considering successor candidates too - simply rewriting into a newer technology does not necessarily finish the job.

In practice, this is the natural framing.

• If Excel will remain the UI, keeping some VBA has value
• If Excel only needs to be the input/output, the inner logic is easy to move out
• If Excel itself is no longer the proper UI, it becomes a candidate for a rebuild

flowchart TB
    accTitle: Think in terms of what role Excel plays as a UI
    accDescr: A diagram showing the practical framing that if Excel remains the UI it is worth keeping some VBA, if Excel only needs to handle input and output then the inner logic is easy to move out, and if Excel itself is no longer the proper UI it becomes a candidate for a rebuild.
    q1{"What role does Excel play"}
    q1 -->|"stays as the UI"| r1["Worth keeping some VBA"]
    q1 -->|"only input and output"| r2["Logic is easy to move out"]
    q1 -->|"no longer the real UI"| r3["Candidate for a rebuild"]

Figure 6: Whether Excel is the UI decides between keeping, moving out, and rebuilding.

4. VBA’s Main Constraints

4.1 It assumes the desktop

This is the biggest constraint. VBA is fundamentally a technology that runs inside desktop Office.

Per Microsoft’s official information, Excel for the web cannot create, run, or edit VBA; you can open and edit macro-enabled workbooks, but you cannot run the VBA.²⁸

That alone makes it a poor fit for requirements like these.

• Everything should complete in the browser
• The same extension should work across Mac / iPad / Web
• Administrators should distribute it centrally
• No dependency on the local Excel desktop app

Microsoft itself, in the VBA documentation, points readers to Office Add-ins when building extensions for multiple platforms.⁹⁵

flowchart TB
    accTitle: The constraint of assuming the desktop
    accDescr: A diagram showing that VBA runs inside desktop Office and cannot be created, run, or edited in Excel for the web, which makes it a poor fit for browser-only or cross-platform requirements, and that Office Add-ins are the documented path for extensions targeting multiple platforms.
    h1["VBA"] --> h2["Runs inside desktop Office"]
    h2 --> h3["Excel for the web cannot create, run, or edit it"]
    h3 --> h4["Poor fit for browser-only or central distribution needs"]
    h4 -.-> h5["For multiple platforms, look at Office Add-ins"]

Figure 7: The biggest constraint is that VBA assumes the desktop.

4.2 Heavy friction in security and distribution

A large part of why VBA gets misunderstood as “no longer usable” is actually security hardening.

Microsoft now blocks VBA macros in files from the internet by default. Opening an emailed or downloaded .xlsm no longer simply runs the macros the way it used to.³

As security, this is the right direction. But from the operations side, friction grows:

• Distribute via attachment and it does not run
• A template downloaded from an external site does not run
• The handling via OneDrive / SharePoint / network paths is hard to grasp
• “Please enable macros” guidance becomes an operational weak point

flowchart TB
    accTitle: The friction created by the default macro block
    accDescr: A diagram showing that VBA macros in files that came from the internet are blocked by default, so emailed and downloaded files no longer run the way they used to and friction grows in distribution and operations, even though the block itself is the right direction for security.
    m1["Files that came from the internet"] --> m2["VBA macros blocked by default"]
    m2 --> m3["Attachments and downloads do not just run"]
    m3 --> m4["More friction in distribution and operations"]
    m2 -.-> m5["The right direction for security"]

Figure 8: Much of the impression that VBA stopped working comes from the default macro block.

That said, “it does not run, so we are done” is not the end of it. In the same document, Microsoft also sets out the ways to let macros in trusted files run. Four of them come up constantly in practice.³

The caveats are just as clear.³

• A trusted location and a trusted site mean trusting everything placed there. They have to be limited to places where you can control who can write.
• Trusted Publishers is a Windows-wide setting, not something scoped to Office.
• Excel add-ins (.xla / .xlam) will not run when they carry the Mark of the Web, even if they are signed and the publisher is trusted. In that case you either remove the Mark of the Web or place the file in a trusted location.
• Opening a network share by IP address alone can fall outside both Trusted Sites and Local intranet, and get blocked for that reason.

Put differently, if you decide to keep VBA, then separately from the code you have to settle where files will live and how they will be trusted, as a distribution design. Continuing to email .xlsm files around without deciding that is the arrangement with the most friction.

In other words, VBA’s problems arise not only in “language features” but also in the design of distribution and trust.

flowchart TB
    accTitle: If you keep VBA, decide the distribution design too
    accDescr: A diagram showing that deciding to keep VBA requires settling, separately from the code, where files will live and how they will be trusted as a distribution design, and that continuing to email xlsm files around without deciding that is the arrangement with the most friction.
    p1["Deciding to keep VBA"] --> p2["The code question"]
    p1 --> p3["The distribution design question"]
    p3 --> p4["Where the files live"]
    p3 --> p5["How they become trusted"]
    p4 -.-> p6["Emailing .xlsm without deciding = the most friction"]

Figure 9: Once you decide to keep it, design where the files live and how they get trusted, separately from the code.

4.3 The 32-bit / 64-bit wall

Office comes in 32-bit and 64-bit editions, and the default is 64-bit in Office 2019 and Microsoft 365.⁷

As a result, older VBA code - especially code that calls Windows APIs via Declare - may not run as-is in 64-bit environments. Microsoft advises absorbing the 32-bit / 64-bit differences using PtrSafe, LongPtr, LongLong, and so on.⁷

The painful part is that beyond the code, these dependencies tend to become problems together:

• Old COM / ActiveX / OCX
• External DLLs that assume 32-bit
• Components that assume registry registration
• Drifted Office references

In other words, a VBA migration very often turns out to be less a language rewrite and more an untangling of Office bitness and external dependencies.

flowchart TB
    accTitle: The 32-bit / 64-bit wall
    accDescr: A diagram showing that because Office 2019 and Microsoft 365 default to 64-bit, older code calling Windows APIs through Declare needs PtrSafe and LongPtr, and old COM, ActiveX, external DLLs that assume 32-bit, and drifted references become problems at the same time, so migration is more about untangling external dependencies than rewriting the language.
    b1["Office 2019 / M365 default to 64-bit"] --> b2["Old Declare calls may not run as-is"]
    b2 --> b3["Absorb the difference with PtrSafe and LongPtr"]
    b2 -.-> b4["COM / ActiveX / OCX and 32-bit DLLs break at the same time"]
    b4 --> b5["Migration is really about bitness and dependencies"]

Figure 10: In a 64-bit migration, external dependencies usually bite before the code does.

4.4 Poor fit for unattended and server-side execution

This part is quite important. Microsoft explicitly states that it does not recommend or support server-side automation of Office applications. Office is designed for an interactive desktop with a user profile, and in unattended environments it can become unstable or deadlock.⁶

So configurations like these lean dangerous.

• Launching Excel from a Windows service
• Automating Office from ASP.NET or DCOM
• Endlessly running invisible Excel under Task Scheduler
• Delegating report generation wholesale to Excel on a server

It may “work occasionally.” But working and being a supportable configuration are not the same thing.

If you need unattended execution, the first suspect is not VBA - it is the configuration that drives the Excel application itself.

flowchart TB
    accTitle: Why it is a poor fit for unattended and server-side execution
    accDescr: A diagram showing that Office is designed for an interactive desktop with a user profile, that server-side automation is neither recommended nor supported, that unattended environments can go unstable or deadlock, and that the thing to suspect is the configuration driving Excel rather than VBA itself.
    u1["Launching Excel from a service or batch"] --> u2["Office is designed for an interactive desktop"]
    u2 --> u3["Unattended runs can go unstable or deadlock"]
    u3 --> u4["Server-side automation is neither recommended nor supported"]
    u4 -.-> u5["Suspect the configuration driving Excel, not VBA"]

Figure 11: Working occasionally and being supportable are different things, and unattended execution calls the configuration itself into question.

4.5 Easily disadvantaged in maintainability, testability, and diff management

VBA code easily ends up locked inside workbooks and Access files. As a result, problems like these arise readily.

• It becomes unclear which file is the authoritative copy
• Responsibilities scatter across forms, sheets, and standard modules
• References and ActiveX dependencies drift per environment
• Code review and diffing are difficult
• Unit tests are hard to write
• Excel cell addresses themselves harden into specification

This is a problem not of the VBA language alone, but of the structure of “holding business logic inside Office files.” For small automation it may not bite, but as things grow into business systems it suddenly does.

flowchart TB
    accTitle: The problem with holding logic inside Office files
    accDescr: A diagram showing that VBA code easily ends up locked inside workbooks and Access files, which makes the authoritative copy unclear, scatters responsibilities, and makes diffing and testing hard, and that these problems stay invisible in small automation but bite hard once the work grows into a business system.
    k1["Code locked inside Office files"] --> k2["Unclear source of truth, scattered responsibilities"]
    k1 --> k3["Diffing and testing are hard"]
    k2 --> k4["Not noticeable in small automation"]
    k3 --> k4
    k4 --> k5["Bites hard once it becomes a business system"]

Figure 12: The problem comes from holding business logic inside a file, not from the language.

4.6 If you depend on VBScript, separate caution is needed

In 2025, the Microsoft 365 Developer Blog announced that the phased deprecation of VBScript on Windows can also affect VBA projects. In particular, cases that execute external .vbs files and cases that depend on the VBScript.RegExp reference are within scope.¹⁰

At the same time, Microsoft is also responding by including a RegExp class in VBA by default in Office for Windows from Microsoft 365 Version 2508 (Build 19127.20154).¹⁰

Whether your own assets are affected can be determined by searching for three things. Either the Find command on the VBE Edit menu or a grep over text exported to .bas / .cls files will do.

The list of references can be checked under References on the VBE Tools menu.

Of these, RegExp is being taken care of as described above: from Microsoft 365 Version 2508 (Build 19127.20154) onward, Office for Windows includes the RegExp class in VBA by default.¹⁰ The heavy case is the third row, “executing an external .vbs,” where the processing itself has to be moved either into VBA or onto a different execution platform. Record these three items at the same time as you build the asset inventory (8.1) and you avoid doing the work twice.

What matters here: the deprecation of VBScript and the deprecation of VBA are not the same story. The accurate understanding is not that VBA itself is going away, but that some external dependencies hanging off VBA need to be revisited.

flowchart TB
    accTitle: How the VBScript deprecation relates to VBA
    accDescr: A diagram showing that the phased deprecation of VBScript on Windows affects cases that execute external vbs files and cases that depend on the VBScript RegExp reference, that RegExp is being covered by newer Office including the class in VBA by default, and that none of this amounts to the end of VBA as a whole.
    w1["Phased deprecation of VBScript"] --> w2["Depends on running an external .vbs"]
    w1 --> w3["Depends on VBScript.RegExp"]
    w2 --> w4["Consider moving to another execution platform"]
    w3 -.-> w5["New Office ships RegExp in VBA by default"]
    w1 -.-> w6["A different story from the end of VBA"]

Figure 13: What is affected is only the dependencies hanging off VBScript, not VBA itself.

5. Will VBA Become Unusable?

First, this is not a case of “everything stops working tomorrow.” But neither is it the era of “usable anywhere for anything.”

At minimum, reading Microsoft’s official information, the strongly visible direction today is this.

• VBA as an extension of desktop Office continues to exist¹
• On the web / cross-platform side, Office Scripts and Office Add-ins are used as appropriate⁴⁵⁹
• Macro distribution safety is treated more strictly than before³
• Peripheral components like VBScript dependencies may be affected in the future¹⁰

Furthermore, Microsoft states about Office Scripts that VBA is desktop-centric while Office Scripts is meant for secure, cross-platform, cloud-based solutions. At the same time, it explains that VBA currently covers a broader range of Excel features available in the desktop client.⁴

Putting these two side by side gives a very practical picture.

• For deep manipulation of desktop Excel, VBA’s coverage is still wider
• For browser / M365 / shared workflows, Office Scripts and Add-ins are the more natural fit
• Therefore, the answer is neither “just convert everything to Office Scripts” nor “keep VBA at the center forever”

It is natural to read VBA’s future as a clarification of boundaries rather than extinction.

flowchart TB
    accTitle: Clarified boundaries rather than extinction
    accDescr: A diagram showing that VBA still covers more ground for deep manipulation of desktop Excel while Office Scripts and Add-ins fit browser, M365, and shared workflows better, so the change is one of boundaries becoming clearer rather than everything moving to one side.
    z1{"Where will it be used"}
    z1 -->|"deep desktop Excel work"| z2["VBA still covers more ground"]
    z1 -->|"browser / M365 / shared workflows"| z3["Office Scripts or Add-ins fit better"]
    z2 --> z4["Boundaries become clearer"]
    z3 --> z4

Figure 14: Neither everything to Office Scripts nor VBA at the center forever - the boundaries are being drawn.

6. Cases to Replace / Cases Not to Replace

First, a rough but useful decision table.

The hybrid approach in the second row is used in this article to mean keeping Excel / Access as the entry point for screens and reports while moving only the business logic and I/O out into a separate execution unit. What sets it apart from a full replacement is that the screens and the workflow the user sees do not change. The concrete shape is covered in 7.1.

The important thing about this table is that the axis of decision is not “VBA is old.” What you should really look at is the execution environment, operations, distribution, dependencies, auditing, and extensibility.

flowchart TB
    accTitle: The axes for a replacement decision
    accDescr: A diagram showing that the axis for a replacement decision is not that VBA is old but the execution environment, operations, distribution, dependencies, auditing, and extensibility, and that the hybrid approach moves only logic and I/O out while leaving the screens and workflow the user sees unchanged.
    j0["VBA is old"] -.-> j1["Not a decision axis"]
    j2["The axes that really matter"] --> j3["Execution environment, operations, distribution"]
    j2 --> j4["Dependencies, auditing, extensibility"]
    j3 --> j5["Choose keep / hybrid / move out"]
    j4 --> j5

Figure 15: The axis is not age but execution environment, operations, distribution, dependencies, auditing, and extensibility.

7. Realistic Replacement Destinations

Before the specifics, here are the candidates on a single page. Once the decision table in chapter 6 has settled which way to lean, use this table to check what that direction demands of you.

The column most often overlooked is “Prerequisites and licensing.” Office Scripts in particular has clearly stated conditions, so 7.3 covers them separately.

7.1 Keep Excel, move only the internals to .NET or a separate process

The most realistic and least failure-prone option is this.

• Excel / Access remains the entry point for screens and reports
• Buttons and input forms also stay for now
• But business logic, HTTP, cryptography, CSV / JSON, heavy computation, and file processing move out
• VBA shrinks to “bridging” and “UI manipulation” only

The advantage of this configuration is that it is hard to break the user’s view and workflow. Rather than a full replacement, you can proceed by thinning out responsibilities first.

flowchart TB
    accTitle: The hybrid arrangement that keeps Excel and moves only the internals out
    accDescr: A diagram showing that the entry point for screens and reports stays in Excel or Access while business logic, HTTP, cryptography, heavy computation, and file processing move to .NET or a separate process, leaving VBA responsible only for bridging and UI work so that responsibilities thin out without breaking what the user sees.
    x1["Screens and reports stay in Excel / Access"] --> x2["VBA shrinks to bridging and UI work"]
    x2 --> x3["Heavy logic and I/O move to .NET or another process"]
    x3 -.-> x4["The user view and workflow stay intact"]

Figure 16: The least failure-prone shape is keeping the entry point and moving only the internals out.

Related article:

• Using a .NET 8 DLL from VBA with Full Typing - COM Exposure and dscom TLB

“Before rewriting everything, first offload just the heavy parts” is very much a practitioner’s move.

7.2 For unattended execution and report generation, lean toward direct file generation, not Office app automation

If you want to mass-generate Excel reports in nightly batches or services, the first suspect is not “is VBA too old” but the very fact that you are launching the Excel application.

Microsoft does not recommend server-side Office Automation. Instead, it recommends working with Office files directly, using formats such as Open XML.⁶

So if the requirements look like

• producing .xlsx
• emitting standardized reports in volume
• converting to PDF
• running in nightly batches

then the axis to choose along is not whether to drive Excel but whether to assemble Excel files.

flowchart TB
    accTitle: Unattended report generation belongs in direct file generation
    accDescr: A diagram showing that when reports need to be mass-generated in nightly batches or services, the thing to suspect first is the launching of the Excel application itself, that server-side Office Automation is not recommended, and that assembling Office files directly with formats such as Open XML is the recommended path.
    y1["Mass-generate reports unattended"] --> y2{"Which axis to think along"}
    y2 -.->|"not recommended"| y3["Drive the Excel application"]
    y2 -->|"recommended direction"| y4["Assemble the file directly with Open XML"]

Figure 17: For unattended requirements, choose assembling the file over driving Excel.

Related article:

• How to Build Excel Report Output - COM / Open XML / Templates

7.3 For business flows on Microsoft 365, Office Scripts + Power Automate

If the business already leans on OneDrive / SharePoint / Teams / Outlook / Forms, Office Scripts is a serious candidate.

Microsoft describes Office Scripts as meant for secure, cross-platform, cloud-based solutions. Combined with Power Automate, Excel processing can be automated with email, forms, or schedules as triggers.⁴¹¹

Before that, though, you have to check the usage conditions. These are the cost and environment prerequisites themselves, so they always catch up with you later.¹²¹³

In other words, Office Scripts is not “a free VBA replacement that comes in the box.” Compared with handing local .xlsm files around, it adds OneDrive / SharePoint and M365 licensing as prerequisites. Decide to “migrate to Office Scripts” without noticing that and you end up back in a license procurement discussion halfway through the migration.

flowchart TB
    accTitle: Prerequisites to check before moving to Office Scripts
    accDescr: A diagram showing that Office Scripts is not a free VBA replacement that comes in the box, that compared with handing local xlsm files around it adds OneDrive or SharePoint and M365 licensing as prerequisites, and that overlooking this sends the migration back into a license procurement discussion halfway through.
    o1["Handing local .xlsm files around"] --> o2["Considering a move to Office Scripts"]
    o2 --> o3["Adds OneDrive / SharePoint and M365 licensing"]
    o3 -->|"check first"| o4["Build the prerequisites into the plan"]
    o3 -.->|"if overlooked"| o5["Back to license procurement mid-migration"]

Figure 18: Office Scripts is not a free stand-in for VBA - check the prerequisites first.

On top of that, it is not all-powerful on the feature side either.

• Office Scripts does not support Excel-level events
• Execution is fundamentally manual start or invocation from Power Automate⁴
• Power Automate integration requires a Microsoft 365 business license¹¹
• The Run script action has limits such as 1,600 calls per user per day and 120 seconds of synchronous processing¹²

In other words, it is more accurate to see Office Scripts not as “a replacement for VBA” but as an automation building block on M365.

flowchart TB
    accTitle: How Office Scripts gets executed
    accDescr: A diagram showing that Office Scripts does not support Excel-level events, that execution is fundamentally a manual start or a call from Power Automate, and that with call count and synchronous processing limits in place it is more accurate to see it as an automation building block on M365 than as a replacement for VBA.
    a1["Office Scripts"] --> a2["Started manually"]
    a1 --> a3["Called from Power Automate"]
    a1 -.-> a4["No support for Excel-level events"]
    a2 --> a5["See it as an automation part on M365"]
    a3 --> a5

Figure 19: The execution model differs from event-driven VBA, so use it as an automation building block on M365.

7.4 If you want a cross-platform extension, Office Add-ins

If you want to extend Word, Excel, Outlook, and so on across Windows / Mac / iPad / browser, Office Add-ins are the first candidate.

Microsoft’s official documentation explains that Office Add-ins can be built with HTML / CSS / JavaScript, run on multiple platforms, and suit central distribution.⁵

This suits requirements like:

• Connecting Office to internal portals or core systems
• Surfacing the same UI and commands in Outlook / Excel / Word
• Administrator-driven distribution rather than per-PC macro distribution
• Moving away from the local .xlsm distribution model

It is a different playing field from VBA, so it feels quite unlike writing code inside Excel. In exchange, operations and distribution become far easier to keep tidy.

flowchart TB
    accTitle: What Office Add-ins are a good fit for
    accDescr: A diagram showing that Office Add-ins are built with HTML, CSS, and JavaScript, run across Windows, Mac, iPad, and the browser, suit central distribution, and therefore fit requirements that want to move away from per-PC macro distribution and the local xlsm distribution model.
    d1["Built with HTML / CSS / JavaScript"] --> d2["Runs on Windows / Mac / iPad / browser"]
    d2 --> d3["Central distribution by administrators"]
    d3 --> d4["Move away from the local .xlsm model"]

Figure 20: When cross-platform reach and central distribution are the requirements, this is Add-ins territory.

7.5 If Excel / Access itself is no longer really the UI, move out to a Windows app or web app

If you have reached this state, rebuilding as an application is more natural than prolonging the VBA.

• Screen transitions and permission controls have proliferated
• The center of gravity is the DB, audit logs, approval flows, and user management
• There is external device integration or long-running processing
• Excel cells and forms have come to stand in for the business specification
• The very fact that state management vanishes when the workbook closes has become painful

In this case, for a Windows-based business tool, a C# / .NET desktop app; if the user base or device range is broad, a web app gives the more straightforward structure.

8. How to Migrate in Stages

The most dangerous thing in replacing VBA is trying to push everything onto a single new technology from the start. In practice, going in the order below is generally the safer path.

8.1 First, build an asset inventory

What you want to enumerate first is not the code volume itself but the dependencies.

• Which .xlsm / .xlam / .accdb / .mdb files exist?
• Which are the entry points of real operations?
• What is in the references?
• What Declare statements, external DLLs, COM / ActiveX / OCX are there?
• What are the 32-bit / 64-bit assumptions?
• Which macros are used by whom, in which procedure?
• What are the outputs (Excel, CSV, PDF, printing, email sending, and so on)?

Replace things with this left vague and you get breakage like “the macro nobody supposedly touched turned out to be alive only at month-end.”

flowchart TB
    accTitle: What the asset inventory has to surface
    accDescr: A diagram showing that the first step of a staged migration is identifying dependencies rather than counting code, recording which files are the entry points of real operations, what the references, external DLLs, and bitness assumptions are, and which macros are used by whom in which procedure and with what output, because leaving this vague leads to breakage from a macro that was alive only at month-end.
    r1["Identify the files"] --> r2["Identify dependencies (references, DLLs, bitness)"]
    r2 --> r3["Identify usage (who, which procedure, what output)"]
    r3 -.-> r4["Leave it vague and a month-end-only macro breaks"]

Figure 21: The inventory is about dependencies and usage, not lines of code.

8.2 Split the code by responsibility

The next step is splitting not by file but by responsibility.

• Excel / Access UI manipulation
• Sheet input/output
• Report layout
• Business rules
• External API / file / DB I/O
• Batch processing
• Printing / distribution

With this breakdown, what to keep, what to thin out, and what to move out becomes much easier to see.

8.3 Decide a destination per responsibility

The split that is easy to recommend:

• UI and sheet manipulation: keep in VBA for now
• Business logic: move out to .NET DLLs, a separate process, or a service
• Unattended report generation: lean toward Open XML or direct generation
• M365 workflows: Office Scripts + Power Automate
• Cross-platform UI: Office Add-ins
• Areas that have become business systems: separate into Windows / web apps

The key point is not unifying on a single destination. The contents of VBA assets are almost always a mixture of multiple responsibilities.

flowchart TB
    accTitle: Decide a destination per responsibility
    accDescr: A diagram showing that splitting code by responsibility rather than by file makes it easy to see what to keep, what to thin out, and what to move out, so UI and sheet work stays in VBA for now, business logic goes to .NET, unattended report generation goes to Open XML, and M365 workflows go to Office Scripts.
    m1["Split the code by responsibility"] --> m2["See what to keep / thin out / move out"]
    m2 --> n1["UI and sheet work stay in VBA for now"]
    m2 --> n2["Business logic goes to .NET or another process"]
    n1 --> n3["Unattended report generation goes to Open XML"]
    n2 --> n4["M365 workflows go to Office Scripts"]

Figure 22: Split by responsibility rather than by file and the destinations naturally become several.

8.4 Pin down the interfaces first

Before starting the migration, at minimum decide:

• What are the inputs?
• What are the outputs?
• How are errors reported?
• Which sheets, named ranges, and file paths form the contract?
• At what point is the result considered final?

Proceed without deciding these and the cell addresses themselves become the API, and it breaks easily.

8.5 Compare via parallel operation

For reports and aggregation in particular, it is safer not to cut over abruptly.

• Produce output from the old VBA version and the new implementation in parallel
• Compare the emitted .xlsx / CSV / PDF
• Check differences in dates, rounding, formatting, and print ranges
• Also test the exception paths and empty-data paths

VBA replacement rarely breaks in the form of “does it run.” It breaks as numbers and formatting drifting silently.

flowchart TB
    accTitle: Compare in parallel operation before cutting over
    accDescr: A diagram showing that reports and aggregation should not be cut over abruptly but produced in parallel from the old VBA version and the new implementation, with dates, rounding, formatting, and print ranges compared and exception and empty-data paths tested first, because breakage shows up as numbers and formatting drifting silently.
    h1["Run the old VBA and the new build in parallel"] --> h2["Compare output (dates, rounding, formatting, print range)"]
    h2 --> h3["Test exception paths and empty data too"]
    h3 --> h4["Cut over once there is no difference"]
    h2 -.-> h5["Breakage shows up as numbers drifting quietly"]

Figure 23: Do not cut over abruptly - run old and new side by side and compare the output first.

9. Common Failures

9.1 Starting with “VBA is old, so everything goes to Office Scripts”

Office Scripts is a strong option, but Microsoft itself explains that VBA covers a broader range of desktop Excel features. Furthermore, Office Scripts does not support Excel-level events.⁴

So the idea of laterally porting macros with deep Excel desktop dependencies as-is is dangerous.

9.2 Unattended execution that keeps launching Excel itself

This is remarkably common. It looks convenient while it works, but Microsoft does not recommend server-side automation of Office.⁶

For nightly batches and services, it is safer to lean toward assembling Excel files rather than driving Excel.

9.3 Changing the screens, reports, and business rules all at once

What is really frightening in VBA replacement is not the code conversion itself but dropping pieces of the business specification. Excel sheets and Access forms have a great deal of operational rules embedded in them that are written nowhere in the code.

Change everything at once and you invite breakage like “it looks close, but differs only at month-end.”

flowchart TB
    accTitle: What happens when everything changes at once
    accDescr: A diagram showing that the real danger in a VBA replacement is not code conversion but dropping pieces of the business specification, because Excel sheets and Access forms hold operational rules written nowhere in the code, so changing screens, reports, and business rules all at once invites output that looks close but differs only at month-end.
    g1["Change screens, reports, and rules all at once"] --> g2["Drop operating rules written nowhere in the code"]
    g2 --> g3["Looks close but differs only at month-end"]
    g2 -.-> g4["The danger is lost specification, not code conversion"]

Figure 24: Change everything at once and the specification living outside the code is what gets dropped.

9.4 Deferring 32-bit / 64-bit and external references

In migration projects, what blows up first is often not the VBA code itself but:

• Declare
• External DLLs
• COM / ActiveX / OCX
• Office bitness
• References

Push these to the back and the final stretch of implementation becomes painful all at once.⁷

9.5 Conflating the VBScript story with the VBA story

From VBA’s perspective, the phased deprecation of VBScript is a matter of revisiting some dependencies. It does not mean the end of VBA as a whole.¹⁰

Mix the two and a sloppy internal rumor - “apparently VBA is ending” - easily takes on a life of its own.

10. Summary

In a phrase, VBA is an extension language tightly attached to Office desktop applications. For automating the work right at the user’s desk, next to Excel and Access, it remains quite practical.¹

But what matters in practice going forward is not treating VBA as an all-purpose central technology.

• If you want browser / cross-platform, look at Office Scripts and Office Add-ins⁴⁵
• For unattended / server-side processing, avoid Office Automation⁶
• Move heavy logic and external integrations out to .NET or a separate process
• If Excel / Access has become painful as a UI, move out to a Windows app or web app

The answer is neither “replace everything” nor “change nothing,” but “split by responsibility and thin out in stages.”

flowchart TB
    accTitle: The answer on replacement
    accDescr: A diagram showing that the answer for VBA assets is neither replacing everything nor changing nothing but splitting by responsibility and thinning out in stages, and that the replacement is safest when run as reorganization rather than as translation.
    q0{"What to do with VBA assets"}
    q0 -.->|"extreme"| e1["Replace everything"]
    q0 -.->|"extreme"| e2["Change nothing"]
    q0 -->|"the practical answer"| e3["Split by responsibility and thin out in stages"]
    e3 --> e4["Run it as reorganization, not translation"]

Figure 25: The answer is neither extreme, but splitting by responsibility and thinning out in stages.

Glanced at carelessly, VBA assets look old. But in practice they are packed with business specifications, operating procedures, report designs, and the field’s accumulated habits.

That is exactly why replacement is safest when run as reorganization, not translation.

11. Related Articles

• What Are COM / ActiveX / OCX? - The Differences and Relationships Explained
• Using a .NET 8 DLL from VBA with Full Typing - COM Exposure and dscom TLB
• How to Build Excel Report Output - COM / Open XML / Templates

12. References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Is VBA going to stop working?

At least as of March 2026, there is no clear official Microsoft announcement that VBA itself will be terminated in the near future. What is happening is not a sudden abolition but a change in which the places VBA can be used and the preconditions for using it have become clearer. Specifically, Excel for the web cannot create, run, or edit VBA, and macros in files that came from the internet are blocked by default. It is more natural to read VBA's future as a clarification of boundaries than as extinction.

Should we just migrate all of our VBA to Office Scripts?

Not recommended. Microsoft itself explains that VBA currently covers a broader range of Excel features available in the desktop client, and Office Scripts does not support Excel-level events. Office Scripts is more accurately seen not as a replacement for VBA but as an automation building block on M365 that drives workbooks on OneDrive or SharePoint together with Power Automate. The realistic approach is to choose a destination separately for each responsibility.

Is it acceptable to run Excel macros unattended on a server or in a nightly batch?

It is risky. Microsoft explicitly states that it does not recommend or support server-side automation of Office applications. Office is designed around an interactive desktop and a user profile, and in unattended environments it can become unstable or deadlock. If the requirement is mass report generation, the recommended approach is to assemble Excel files directly using formats such as Open XML rather than launching the Excel application.

How should existing VBA assets be migrated?

Rather than pushing everything onto a single new technology from the start, a staged migration is safer. Begin with an asset inventory that records the .xlsm files, references, external DLLs, and 32-bit / 64-bit assumptions, then split the code by responsibility: UI manipulation, business logic, reports, and I/O. From there, keep UI and sheet manipulation in VBA for now, move business logic to .NET DLLs or a separate process, shift unattended report generation to Open XML, and take M365 workflows to Office Scripts. For reports and aggregation, run the old and new implementations in parallel and compare the output before cutting over.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.