If you write scripts or add-ins that automate Outlook using the Outlook Object Model or VBA, you have likely heard that Microsoft is replacing Classic Outlook with New Outlook. The core question is whether New Outlook supports the same automation features that your existing code depends on. New Outlook is built on a web-based platform and does not support the same COM-based object model that Classic Outlook uses. This article explains exactly which automation features are missing, what alternatives exist, and whether you can safely migrate your automation workflows today.
Key Takeaways: New Outlook vs Classic Outlook for Object Model Automation
- Outlook Object Model (COM): Not available in New Outlook. Classic Outlook uses COM-based automation; New Outlook uses REST APIs and web-based add-ins only.
- VBA macros: Not supported in New Outlook. No VBA editor or macro recording exists in New Outlook.
- COM add-ins (e.g., VSTO, third-party): Not supported in New Outlook. Only web-based add-ins (JavaScript/HTML/Office Add-ins framework) run in New Outlook.
Why New Outlook Cannot Run the Classic Outlook Object Model
Classic Outlook uses the Microsoft Outlook Object Model, a Component Object Model interface that allows external applications and scripts to control Outlook programmatically. This model exposes objects like Application, Namespace, MAPIFolder, MailItem, and AppointmentItem. VBA macros and COM add-ins built with Visual Studio Tools for Office (VSTO) or other COM languages rely on this interface.
New Outlook is a web-based application built on Microsoft’s Outlook Web App platform. It does not load the COM runtime and does not expose the classic object model. Instead, New Outlook supports only the Office Add-ins platform, which uses web technologies like JavaScript, HTML, and CSS. These add-ins communicate with Outlook through REST APIs and do not have access to the full set of objects and methods that the classic object model provides.
Key Technical Differences
The classic object model runs in-process with Outlook and can perform actions like sending mail, modifying calendar items, and reading the Inbox directly. New Outlook add-ins run in a sandboxed browser environment and must request permissions through a manifest file. They cannot execute arbitrary code on the client machine, access the file system, or run background tasks without user interaction.
What Automation Features Are Missing in New Outlook
The following automation features that exist in Classic Outlook are not available in New Outlook.
- VBA macros and the VBA editor
New Outlook has no VBA editor, no macro recording, and no way to run VBA code. All VBA macros stop working. - COM add-ins (VSTO, shared add-ins, third-party)
Any add-in built using COM interop or VSTO cannot load in New Outlook. Only web-based Office Add-ins are supported. - Automation from external applications (early or late binding)
Scripts that use CreateObject(“Outlook.Application”) or New Outlook.Application in .NET fail because New Outlook does not register the COM Application class. - Direct access to the Outlook object model from PowerShell or other languages
PowerShell scripts that use the Outlook COM object cannot connect to New Outlook. - Background or unattended automation
New Outlook add-ins require user interaction to activate and cannot run scheduled or server-side automation tasks without a user logged in and the app open.
What Automation Is Possible in New Outlook
New Outlook supports the Office Add-ins platform, which provides a subset of automation capabilities through JavaScript APIs. These are the main automation features available.
- Web-based add-ins
You can create add-ins using the Office Add-ins framework with a manifest file. These add-ins can read and write mail items, calendar items, and contacts through the Outlook REST API. - Event-based activation
Add-ins can run when a user opens a message, composes a new message, or views an appointment. They cannot run on a schedule or without user action. - REST API calls
Add-ins can call Microsoft Graph or Outlook REST APIs to perform actions like sending mail, moving items, or managing folders. These require the user to be signed in and grant consent. - Custom task panes and UI extensions
You can add buttons, ribbons, and task panes to the New Outlook interface using the add-in manifest.
If You Need to Automate Outlook Today
If your organization relies on VBA macros, COM add-ins, or external automation scripts that use the Outlook object model, you cannot replace Classic Outlook with New Outlook without rewriting those automation tools. Here are the practical steps to evaluate your situation.
Option 1: Continue Using Classic Outlook
Classic Outlook is still supported and will receive security updates for several years. Microsoft has not announced a retirement date for Classic Outlook. You can keep Classic Outlook installed and block the New Outlook toggle using Group Policy or registry settings. This preserves all existing automation.
Option 2: Rewrite Automation Using the Office Add-ins Platform
For new automation projects or if you have the budget to rewrite, you can convert VBA macros or COM add-ins to web-based Office Add-ins. This requires learning JavaScript, HTML, and the Office.js library. You lose the ability to run unattended or background automation.
Option 3: Use Microsoft Graph API for Server-Side Automation
For server-side or scheduled tasks like sending automated emails or processing mailboxes, use Microsoft Graph API instead of the Outlook object model. Graph API works independently of any Outlook client and does not require New Outlook or Classic Outlook to be installed.
Common Misconceptions About New Outlook Automation
“New Outlook supports VBA through a compatibility layer”
This is false. New Outlook does not include any VBA runtime or compatibility layer. VBA macros simply do not run.
“You can run PowerShell scripts against New Outlook”
PowerShell scripts that use the Outlook COM object cannot connect to New Outlook. New Outlook does not register the COM Application class. You can use PowerShell to call Microsoft Graph API, but that is a different approach.
“New Outlook add-ins can run in the background”
Office Add-ins in New Outlook require the user to have the application open and the add-in activated. They cannot run as background services or scheduled tasks.
New Outlook vs Classic Outlook: Automation Feature Comparison
| Feature | Classic Outlook | New Outlook |
|---|---|---|
| VBA macros | Supported | Not supported |
| COM add-ins (VSTO, third-party) | Supported | Not supported |
| External automation (CreateObject) | Supported | Not supported |
| PowerShell automation via COM | Supported | Not supported |
| Web-based add-ins (Office Add-ins) | Supported | Supported |
| Microsoft Graph API access | Supported (via add-ins) | Supported (via add-ins) |
| Unattended / background automation | Supported | Not supported |
| Server-side automation (no client) | Not applicable | Not applicable |
New Outlook cannot replace Classic Outlook for any automation that depends on the Outlook object model, VBA, or COM add-ins. If you need these features, continue using Classic Outlook. For new automation projects, consider Microsoft Graph API for server-side tasks and Office Add-ins for client-side tasks. The key action is to audit your existing automation code and determine whether it relies on COM or VBA before planning any migration.