COM Add-ins and VBA Stop Working When You Move to the New Outlook — How to Replace Your Business Automation

Outlook for Windows now comes in two forms: the existing desktop version (classic Outlook) and the new Outlook for Windows. The new Outlook cannot use COM add-ins, VBA macros or the Outlook object model (OOM)¹. An add-in that checks recipients before sending, a macro that saves attachments from incoming mail, and a tool that sends mail by driving Outlook from Excel all stop working once users move to the new Outlook.

The short answer has three points. First, classic Outlook is supported until at least 2029, and there will be notice before the switch, so you have time to identify the automation that will stop². Second, choose a replacement for each piece of automation you find based on where the processing runs. For checks before sending, the candidate is an Outlook web add-in; for processing triggered by incoming mail or a time of day, Power Automate or Microsoft Graph; and for applying the same processing to everyone’s mail in the organization, Exchange Online mail flow rules. Third, none of these can do everything VBA or COM add-ins could, so for processing that cannot be replaced, decide how long it stays on classic Outlook.

This article is for companies using Outlook with work accounts on Microsoft 365 (Exchange Online), and for IT staff who maintain automation built on Outlook. Statements about timing are based on Microsoft documentation consulted as of November 1, 2026.

What stops working in the new Outlook

In Microsoft’s feature comparison table, the following items are “Available” in classic Outlook and “Not supported” in the new Outlook¹.

In the same table, rules, Quick Steps, .pst files and offline use are “Partially available”¹. This means the feature exists, but not necessarily with everything classic Outlook offers.

On COM add-ins, Microsoft’s developer documentation states that the new Outlook does not support VSTO and COM add-ins, in order to provide a more reliable and stable add-in experience³. Add-ins built with .NET VSTO are included. To use the same functionality in the new Outlook, you need to migrate to an Outlook web add-in. VSTO and COM add-ins continue to work in classic Outlook³.

In classic Outlook, VBA macros run through a COM add-in called “Microsoft VBA for Outlook Addin,” and in many cases they call the OOM⁴. The OOM is the set of Outlook objects, properties, methods and events, and it is what the VBA reference documents⁵.

What is easy to overlook is tools that drive Outlook from outside Outlook. Calling CreateObject("Outlook.Application") from Excel VBA to start Outlook, compose a message and send it is a way of using the OOM that is described in Microsoft’s VBA documentation⁶. Tools that drive Outlook in the same way from PowerShell or C# also use the OOM. The new Outlook has no OOM, so these tools do not work on PCs without classic Outlook either.

flowchart TB
        accTitle: Mechanisms that stop working in the new Outlook
        accDescr: Shows that COM add-ins, VBA macros and external tools that use the OOM run only on classic Outlook and cannot be used in the new Outlook, while Outlook web add-ins run in both.
        AUTO["Business automation using Outlook"] --> COM["COM add-ins (including VSTO)"]
        AUTO --> VBA["VBA macros"]
        AUTO --> EXT["External tools using the OOM"]
        AUTO --> WEB["Outlook web add-ins"]
        COM --> CLASSIC["Run only in classic Outlook"]
        VBA --> CLASSIC
        EXT --> CLASSIC
        WEB --> BOTH["Run in both Outlooks"]
        CLASSIC -.-> STOP["Stop when users move to the new Outlook"]

Figure 1: COM add-ins, VBA macros and external tools that use the OOM run only in classic Outlook; web add-ins run in both.

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 (14 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

The three stages of the switch and their timing

Microsoft explains that migration to the new Outlook proceeds in three stages: opt-in, opt-out and cutover².

• Opt-in: A “Try the new Outlook” toggle appears at the top right of classic Outlook. The new Outlook is off by default; users can try it and return to classic Outlook if needed. The two can also run side by side. According to the documentation updated on February 23, 2026, this is the current stage.
• Opt-out: The new Outlook is on by default, and users are moved to it automatically. Even at this stage, they can return to classic Outlook if needed. For managed Enterprise plans, administrators are to be notified at least 12 months in advance.
• Cutover: Users can no longer return to classic Outlook, and newly deployed Outlook under Microsoft 365 subscriptions is the new Outlook. Notice is to be given at least 12 months before this happens in the production ring.

flowchart TB
        accTitle: The three stages of migration to the new Outlook
        accDescr: Shows that in opt-in users can try the new Outlook and return to classic Outlook, in opt-out users move to the new Outlook by default but can return, and in cutover they can no longer return; that there is at least 12 months' notice before opt-out and before cutover; and that existing classic Outlook is supported until at least 2029.
        S1["Opt-in (off by default, users can try it)"] --> N1["At least 12 months' notice"]
        N1 --> S2["Opt-out (on by default, can return)"]
        S2 --> N2["At least 12 months' notice"]
        N2 --> S3["Cutover (cannot return)"]
        S3 -.-> KEEP["Existing classic Outlook supported until at least 2029"]

Figure 2: Migration proceeds in three stages, with notice before opt-out and before cutover.

Microsoft 365 Message Center post MC949965 (updated February 20, 2026) announced that the start of the opt-out stage in Enterprise environments had been moved from April 2026 to March 2027⁷. The same notice states that users excluded by the opt-out policy, users for whom the toggle is hidden, users with perpetual licenses, and users with on-premises accounts are not subject to the migration, and that migrated users can return to classic Outlook. The timing of cutover was not stated in the documentation I consulted.

Even after cutover, existing installations of classic Outlook from perpetual licenses and subscriptions are supported until at least 2029². There is no need to rush to replace everything, but once opt-out begins, users will move to the new Outlook unless you do something. Identify the automation that would stop at that point before opt-out begins.

Using the new Outlook requires a Microsoft 365 work or school account connected to Exchange Online. According to the developer documentation, the new Outlook does not currently support Exchange accounts that are on-premises, hybrid or in sovereign clouds³.

Settings that hold off migration until replacements are ready

If some departments have not finished their replacements, administrators can delay migration with the following settings⁸.

• Hide the toggle in classic Outlook with the cloud policy “Hide the “Try the new Outlook” toggle in Outlook” in the Microsoft 365 Apps admin center.
• Disable (0) the policy “Manage user setting for new Outlook automatic migration” to stop automatic migration to the new Outlook. In the registry, this corresponds to the NewOutlookMigrationUserSetting value. This policy does not apply to migration through “Admin-Controlled Migration to New Outlook,” which the administrator drives.
• Use an Exchange mailbox policy to prevent work mailboxes from being added to the new Outlook.

flowchart TB
        accTitle: Administrator settings that delay migration
        accDescr: Shows that three settings, a cloud policy that hides the toggle, a policy that stops automatic migration, and a mailbox policy that stops mailboxes being used in the new Outlook, let you keep using classic Outlook until replacements are ready.
        ADMIN["Administrator settings"] --> P1["Hide the toggle"]
        ADMIN --> P2["Stop automatic migration"]
        ADMIN --> P3["Block mailboxes in the new Outlook"]
        P1 --> KEEP["Use classic Outlook until replacements are ready"]
        P2 --> KEEP
        P3 --> KEEP

Figure 3: Administrators can use three settings to delay migration until replacements are ready.

These settings only buy time; they do not change when support for classic Outlook ends. Move the replacements forward while migration is on hold.

Identifying the automation that will stop

The first step is to build a list of the automation that depends on Outlook. Investigate in the following order.

1. List the COM add-ins. On the Inventory page of the Microsoft 365 Apps admin center, you can see and export the COM add-ins installed on your users’ PCs⁴. If you need a per-PC list, collect the registry keys where add-ins are registered using a device management tool such as Intune. According to the VSTO add-in documentation, add-ins installed for all users are registered under HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Outlook\Addins, and add-ins used only by the user who installed them are registered under the same path in that user’s HKEY_CURRENT_USER. Add-ins deployed with ClickOnce are registered only in HKEY_CURRENT_USER. On 64-bit Windows, add-ins for all users may also be registered under HKEY_LOCAL_MACHINE\Software\WOW6432Node\Microsoft\Office\Outlook\Addins⁹. If you collect only HKEY_LOCAL_MACHINE, you will miss add-ins installed per user. Users can check the add-ins on their own PC in Outlook under File > Options > Add-ins.
2. Check whether VBA macros exist. Even if “Microsoft VBA for Outlook Addin” is installed, that does not mean macros are in use. Microsoft’s documentation gives opening the VBA editor and seeing whether it contains anything as the simplest way to check⁴. Also ask users whether their rules call macros.
3. Look for tools that drive Outlook from outside. Search Excel macro-enabled workbooks, PowerShell scripts and in-house C# applications for the strings Outlook.Application and Microsoft.Office.Interop.Outlook. Scripts that run periodically from Task Scheduler are also in scope.
4. For each piece of automation you find, write down what it does. Fill in the items in the following table.

flowchart TB
        accTitle: Steps for identifying the automation that will stop
        accDescr: Shows the flow of listing COM add-ins from the admin center and from the per-user and machine-wide registry, checking whether VBA macros exist, searching for tools that drive Outlook from outside by string, and recording the trigger and inputs and outputs of each piece of automation to prepare for choosing a replacement.
        A["List the COM add-ins"] --> B["Check whether VBA macros exist"]
        B --> C["Look for tools that drive Outlook from outside"]
        C --> D["Record the trigger, inputs and outputs of each"]
        D --> E["Choose a replacement"]

Figure 4: Search for add-ins, macros and external tools in that order, and record the contents of each one you find.

When you take inventory, Microsoft’s own COM add-ins also appear in the list. Microsoft’s documentation shows alternatives for add-ins such as the Teams meeting add-in that have built-in features in the new Outlook, and for those that have already served their purpose⁴. Handling them separately from add-ins made in-house or by outside vendors narrows down what you need to consider replacing. How to audit Excel macros broadly is explained in “A VBA and in-house tool audit guide to prepare for the deprecation of VBScript.”

Four options for replacement

Replacements fall into four groups depending on where the processing runs.

• Outlook web add-ins: run inside the user’s Outlook while a message is being composed or read.
• Power Automate cloud flows: run in Microsoft’s cloud, triggered by incoming mail or a time of day.
• Microsoft Graph: your own programs or scripts call the API to send mail or read received mail.
• Exchange Online mail flow rules: run on Exchange Online servers and apply conditions and actions to mail in transit.

flowchart TB
        accTitle: Where processing runs for each replacement
        accDescr: Shows that Outlook web add-ins run inside the user's Outlook, Power Automate cloud flows in Microsoft's cloud, Microsoft Graph is called from your own programs, and mail flow rules run on Exchange Online servers while mail is in transit.
        WHERE["Where processing runs"] --> U["The user's Outlook"]
        WHERE --> C["Microsoft's cloud"]
        WHERE --> S["Your own programs"]
        WHERE --> X["In transit"]
        U --> W["Web add-in"]
        C --> P["Cloud flow"]
        S --> G["Graph API"]
        X --> R["Mail flow rules"]

Figure 5: The four replacements differ in where the processing runs.

VBA and COM add-ins ran inside Outlook on the user’s PC, with access to both the mailbox and files on the PC. In the replacements, that processing is divided up by where it runs. A single VBA macro is sometimes replaced by two pieces, a web add-in and a Power Automate flow.

Outlook web add-ins

Outlook web add-ins use the Office Add-ins platform and are built with HTML and JavaScript. They run in both the new Outlook and classic Outlook, and can also be used in Outlook on the web and Outlook for Mac³. Users switching to the new Outlook for the first time can choose whether to bring their classic Outlook add-ins. COM add-ins cannot be used, so if a corresponding web add-in exists, that is installed instead³.

To replace pre-send checks, use event-based activation and Smart Alerts. Event-based activation starts an add-in without any user action in response to events such as composing a new message, changing recipients or adding an attachment¹⁰. Smart Alerts uses this mechanism to run processing on the OnMessageSend event after the user presses Send¹¹. It can check whether an attachment was forgotten or an external recipient slipped in, and if the conditions are not met, stop the send and display the reason. OnMessageSend was introduced in Outlook requirement set 1.12¹¹.

What happens when the conditions are not met, or when the add-in cannot be loaded, is set by the send mode in the manifest¹¹.

flowchart TB
        accTitle: How behavior differs by Smart Alerts send mode
        accDescr: Shows that when Send is pressed the Smart Alerts add-in checks the conditions and the message is sent if they are met; if not, prompt user lets the user choose whether to send, and soft block and block prevent sending until the problem is fixed; and when the add-in cannot be loaded, only block stops the send.
        SEND["The user presses Send"] --> CHECK["The add-in checks the conditions"]
        CHECK -->|"Met"| OK["The message is sent"]
        CHECK -->|"Not met"| MODE["Depends on the send mode"]
        MODE --> PU["prompt user: the user chooses whether to send"]
        MODE --> SB["soft block / block: cannot send until fixed"]
        SEND -.-> NA["The add-in cannot be loaded"]
        NA -.-> NB["Only block stops the send"]

Figure 6: What happens when the conditions are not met and when the add-in cannot be loaded depends on the send mode.

The skeleton of the processing when Send is pressed looks like the following. This is an illustration of the mechanism, not code that has been run and verified as is. You also need to specify the event and send mode in the manifest separately.

// Illustration: skeleton of Smart Alerts send-time processing (not verified to run)
function onMessageSendHandler(event) {
  // Check recipients, subject, attachments and so on here
  const passed = true; // Result of the check

  if (passed) {
    event.completed({ allowEvent: true });
  } else {
    event.completed({
      allowEvent: false,
      errorMessage: "Before sending attachments to external recipients, please check the recipients."
    });
  }
}

Office.actions.associate("onMessageSendHandler", onMessageSendHandler);

Web add-ins have constraints that VBA and COM add-ins did not.

• Event-activated add-ins start automatically only when an administrator deploys them from the Microsoft 365 admin center¹⁰. Add-ins that use the block send mode cannot be published in Microsoft Marketplace and are limited to deployment by the organization’s administrator¹¹.
• Event-activated add-ins need an internet connection to start. They time out about 300 seconds after starting¹⁰. If send-time processing takes longer than 5 seconds, a dialog tells the user that it is taking a while¹¹. The documentation recommends finishing heavy checks in advance on the events fired when recipients or attachments change.
• In the new Outlook, add-ins cannot be used offline³. If you want the pre-send check to run even when Outlook starts offline, enable the Exchange Online mailbox policy OnSendAddinsEnabled. When it is enabled, mail sent offline is not sent but saved to Drafts¹¹.
• Not everything COM add-ins could do can be done with web add-ins. In the coverage table in the developer documentation, message encryption and data synchronization with external systems are only partly supported, and proofreading text while it is being written is not supported³.

Power Automate cloud flows

Processing triggered by incoming mail can be moved to Power Automate cloud flows. The Office 365 Outlook connector trigger “When a new email arrives (V3)” receives incoming mail, and the flow can save attachments or pass the contents to another system. Sending mail based on an Excel table can be built with the action “Send an email (V2)”¹².

Cloud flows run in Microsoft’s cloud, so they do not depend on which Outlook the user is using. They run even when the user’s PC is off.

flowchart TB
        accTitle: A cloud flow that saves attachments from incoming mail
        accDescr: Shows the flow in which, when mail arrives, the Office 365 Outlook connector trigger starts the flow, the attachments are retrieved with a separate action and placed in the destination, and the person in charge is notified.
        IN["Mail arrives"] --> TR["Trigger: When a new email arrives (V3)"]
        TR --> GA["Retrieve the attachments"]
        GA --> SAVE["Place them in the destination"]
        SAVE --> NOTE["Notify the person in charge"]

Figure 7: Triggered by incoming mail, retrieve and save the attachments, then send a notification.

The connector documentation includes the following cautions¹².

• It requires an Office 365 mailbox with the REST API enabled. Mailboxes on an on-premises Exchange Server may cause errors.
• If “Include Attachments” is set to “Yes” on the trigger, it waits until all attachments have been downloaded. When many messages with attachments arrive at once, this can time out, so the documentation recommends setting it to “No” and retrieving attachments with the action “Get Attachment (V2).”
• The maximum size of message content is 49 MB.

How to build a flow that saves attachments is covered in “Automatically processing order and invoice PDFs that arrive by email with Power Automate,” and how much Excel VBA can be moved to Power Automate is covered in “Migrating Excel VBA macros to Power Automate.”

Microsoft Graph

Microsoft Graph exposes Microsoft 365 data and functionality as a REST API. The mail API works with users’ mailboxes and shared mailboxes in Exchange Online¹³. Sending mail is POST /me/sendMail and requires the Mail.Send permission. When the request is accepted, 202 Accepted is returned, and by default the sent message is saved to Sent Items¹⁴. The attachments of a received message can be listed with GET /me/messages/{id}/attachments, which requires the Mail.Read permission¹⁵.

Tools that sent mail from Excel VBA through the OOM can be replaced by calling Graph from a server or a script. Outlook is not started, so they work even if the user’s PC has no Outlook.

flowchart TB
        accTitle: Replacing a tool that sends through the OOM with Microsoft Graph
        accDescr: Shows that before the replacement, Excel VBA drives classic Outlook through the OOM to send mail, and after the replacement, your own program or script calls Microsoft Graph sendMail and the mail is sent from Exchange Online.
        subgraph before ["Before"]
            B1["Excel VBA"] --> B2["Drive classic Outlook through the OOM"]
            B2 --> B3["Send mail"]
        end
        subgraph after ["After"]
            A1["Your own program or script"] --> A2["Call Microsoft Graph sendMail"]
            A2 --> A3["Send mail from Exchange Online"]
        end
        B3 -.-> A1

Figure 8: Instead of driving Outlook, call the Graph API from a program.

The request body passed to sendMail looks like this. The recipient and body are example values.

{
  "message": {
    "subject": "Sending our quotation",
    "body": {
      "contentType": "Text",
      "content": "Please find our quotation attached."
    },
    "toRecipients": [
      { "emailAddress": { "address": "customer@example.com" } }
    ]
  }
}

To use Graph from a program, you need to register an app in Microsoft Entra ID and grant permissions such as Mail.Send. Decide with your Microsoft 365 administrator which mailbox mail is sent from and who manages those permissions. How to use Graph from PowerShell is explained in “Introduction to Microsoft Graph PowerShell.”

Exchange Online mail flow rules

Mail flow rules (also called transport rules) find messages that match conditions among the mail flowing through an Exchange Online organization and apply actions to them. They run in transit, not inside the user’s Outlook¹⁶. Conditions can be based on the subject, body, attachments, recipients and so on, and actions include rejecting, redirecting to another recipient, adding recipients, prepending words to the subject and inserting a disclaimer.

flowchart TB
        accTitle: Where mail flow rules run
        accDescr: Shows that whichever Outlook a user sends from, the mail passes through Exchange Online delivery, where mail flow rules apply actions such as rejecting, redirecting, adding recipients or inserting a disclaimer to matching mail before it reaches the recipients.
        N["Send from the new Outlook"] --> T["Exchange Online delivery"]
        C["Send from classic Outlook"] --> T
        T --> RULE["Mail flow rules check the conditions"]
        RULE --> ACT["Reject, redirect, add recipients, disclaimer, etc."]
        ACT --> DEST["Delivered to the recipients"]

Figure 9: Mail flow rules run in transit no matter which Outlook the mail was sent from.

The same rules apply no matter which Outlook the mail is sent from, so they suit processing you want enforced company-wide without exception. On the other hand, because they run in transit, they are not suited to having the user confirm something on screen at the moment of sending, as Smart Alerts does. After a rule is created or changed, it can take up to 30 minutes before it is applied to mail¹⁶. Rules are configured in the Exchange admin center or with PowerShell, so it is administrators who create and fix them.

Decision table: common automation and its replacements

Applying the four options so far to automation commonly built in Outlook gives the following.

The candidates in the table were chosen from where each replacement runs and the constraints covered so far. When in doubt, asking the following questions in order narrows it down.

flowchart TB
        accTitle: Order for choosing a replacement
        accDescr: Shows choosing a web add-in if a check on the user's screen is needed before sending, mail flow rules if the same rule applies to everyone's mail in the organization, Power Automate if processing is triggered by receipt or time and the provided actions are enough, and otherwise a program that calls Microsoft Graph, and deciding how long to keep on classic Outlook any processing that none of these can replace.
        Q1{"Confirm on screen before sending?"} -->|"Yes"| W["Web add-in"]
        Q1 -->|"No"| Q2{"Same rule for everyone's mail?"}
        Q2 -->|"Yes"| R["Mail flow rules"]
        Q2 -->|"No"| Q3{"Are the provided actions enough?"}
        Q3 -->|"Yes"| P["Power Automate"]
        Q3 -->|"No"| G["A program that calls Graph"]
        G -.-> K["Decide how long to keep what cannot be replaced"]

Figure 10: Asking about the user’s screen, the whole organization, and the provided actions in that order narrows down the replacement.

How to proceed with migration

As preparation for migration, Microsoft lists talking with users and teams that have special requirements, deciding the scope for checking how the new Outlook affects existing workflows, and drawing up a readiness plan². For Outlook automation, proceed in the following order.

1. For each piece of automation you identified, decide on the replacement and the person responsible.
2. Build the replacement and try it with some users. During this time, users can run classic Outlook and the new Outlook side by side².
3. Once you have confirmed that the replacement works, remove the settings that hold off migration for that department.
4. For processing that cannot be replaced, decide which departments keep it on classic Outlook and for how long, and review it within the support period of at least until 2029.

flowchart TB
        accTitle: How to migrate Outlook automation
        accDescr: Shows deciding on the replacement and person responsible for each piece of automation identified, building the replacement and trying it with some users, removing the settings that hold off migration once it has been confirmed to work, and deciding which departments keep processing that cannot be replaced on classic Outlook and for how long.
        A["Decide the replacement and owner"] --> B["Build the replacement"]
        B --> C["Try it with some users (run both Outlooks side by side)"]
        C --> D["Remove the settings that hold off migration"]
        A -.-> E["Decide how long to keep irreplaceable processing on classic Outlook"]

Figure 11: Build and try the replacements, then proceed with that department’s migration.

The people who built automation with COM add-ins or VBA may no longer be at the company. For anything whose contents are unknown, first check what it does on classic Outlook, record it with the steps in Figure 4, and then choose a replacement. How to tell processing that suits VBA from processing that does not is covered in “What is VBA? Limits, future, when to replace it, and realistic migration patterns,” and COM itself is explained in “What are COM, ActiveX and OCX?.”

Related articles

• Automating Purchase-Order and Invoice PDFs That Arrive by Email With Power Automate
• Migrating Excel VBA macros to Power Automate
• An Introduction to Microsoft Graph PowerShell
• Preparing for VBScript Deprecation: An Audit Guide for VBA and Internal Tools
• What Is VBA?
• Why did Outlook send an NTLM response before the mail was even opened?

References

Related Articles

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

Related Topics

These are topic pages close to this theme. Starting from the article, you can go on to related services and other articles.

Services Connected to This Topic

This article leads to the following service pages. Start from the entry point closest to your situation.

Frequently Asked Questions

Questions commonly asked at the time of consultation about the topic of this article.

Do VBA macros run in the new Outlook?

No. In Microsoft's feature comparison table, VBA macros in the new Outlook are listed as "Not supported." COM add-ins and the Outlook object model (OOM) cannot be used either. They keep working in classic Outlook, so you can continue to use classic Outlook until the replacements are in place.

How long can classic Outlook be used?

According to Microsoft's documentation, existing installations of classic Outlook from perpetual licenses and subscriptions are supported until at least 2029. The switch proceeds in three stages, opt-in, opt-out and cutover, and administrators are to be notified at least 12 months before opt-out and before cutover.

Are tools that send mail by driving Outlook from Excel VBA also affected?

Yes. A tool that drives Outlook from Excel VBA with CreateObject("Outlook.Application") uses the Outlook object model (OOM). The new Outlook has no OOM, so on PCs without classic Outlook, mail cannot be sent this way. Replace it with sending from a Power Automate cloud flow or with Microsoft Graph sendMail.

What should replace an add-in that checks recipients and attachments before sending?

The first candidate is Smart Alerts (the OnMessageSend event) in an Outlook web add-in. It runs a check after the Send button is pressed, and if the conditions are not met it can stop the send and display the reason. However, event-activated add-ins run only when deployed by an administrator, and they need an internet connection.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and bug investigation, with particular strength in projects where existing assets remain and in investigating failures whose cause is hard to see.