You are evaluating whether the new Outlook for Windows can replace classic Outlook for MAPI-based automation tasks such as sending emails programmatically, managing calendar items, or automating folder operations. Classic Outlook supports MAPI automation through COM add-ins and VBA macros, while the new Outlook uses a web-based platform that does not expose the same MAPI interfaces. This article explains the technical differences between the two platforms, provides practical guidance for testing and migrating automation scripts, and outlines which automation scenarios work and which do not.
Key Takeaways: New Outlook vs Classic Outlook for MAPI Automation
- Outlook Object Model (COM) and MAPI: Classic Outlook supports full MAPI automation via COM. New Outlook does not expose the Outlook Object Model for external automation.
- VBA macros and COM add-ins: Classic Outlook runs VBA macros and third-party COM add-ins. New Outlook does not support either.
- Exchange Web Services (EWS) and Microsoft Graph: New Outlook uses Microsoft Graph API exclusively. Automation scripts must be rewritten to use REST API calls instead of MAPI.
Why New Outlook Cannot Run MAPI Automation Scripts Natively
Classic Outlook (Microsoft Outlook 2019, 2021, and Microsoft 365 versions) is a thick client that loads MAPI32.dll and exposes a COM-based object model. This object model allows external applications, VBA macros, and PowerShell scripts to automate tasks such as sending emails, reading mailboxes, and modifying calendar entries. The MAPI interface is tightly integrated with the Windows operating system and the local Outlook profile.
New Outlook for Windows is a web-based wrapper around Outlook on the web (OWA). It does not load MAPI32.dll and does not host the classic Outlook object model. Instead, it communicates with Microsoft 365 servers exclusively through the Microsoft Graph REST API. This architectural change means that any automation code that references the Outlook.Application object, MAPI session, or CDO (Collaboration Data Objects) will not run in the new Outlook environment.
Microsoft has stated that new Outlook is designed for users who do not require advanced customization or automation. The company recommends that organizations with automation dependencies remain on classic Outlook until their scripts are migrated to Microsoft Graph.
What MAPI Automation Covers
MAPI automation in classic Outlook includes these common scenarios:
- COM add-ins: Third-party tools that extend Outlook functionality, such as CRM connectors, email archiving software, and compliance tools.
- VBA macros: Scripts that run within Outlook to automate repetitive tasks like moving emails to folders, sending automated replies, or creating calendar appointments.
- External automation: PowerShell scripts or .NET applications that create an Outlook.Application object to send mail or read mailbox data.
- CDO (Collaboration Data Objects): Older libraries that wrap MAPI for server-side or client-side automation.
Steps to Test Your Automation Scripts in New Outlook
Before deciding to switch, test each automation scenario in new Outlook. Use the following structured approach.
- Identify all automation dependencies
Open classic Outlook and go to File > Options > Add-ins. Review the list of active COM add-ins. Also check the VBA editor by pressing Alt+F11 and reviewing all modules under Project1 (VbaProject.OTM). Document every script, add-in, and external application that calls Outlook programmatically. - Enable new Outlook for a test user
In the Microsoft 365 admin center, go to Org Settings > Modern Authentication and enable the toggle for new Outlook. Alternatively, each user can enable it by toggling the Try the new Outlook switch in the top-right corner of classic Outlook. Test on a non-production user account first. - Run each automation script manually
For VBA macros: open the VBA editor in new Outlook. The editor is not available. Macros will not run. For COM add-ins: check if the add-in loads under File > Options > Add-ins. Most COM add-ins will not appear because new Outlook does not support the COM add-in model. For external automation: run your PowerShell or .NET script that creates an Outlook.Application object. The script will throw error 0x80040154 Class not registered because the Outlook.Application ProgID is not registered by new Outlook. - Document failures and plan migration
For each failed automation task, determine if a Microsoft Graph equivalent exists. For example, sending an email via Graph uses POST /me/sendMail. Reading inbox items uses GET /me/messages. Calendar creation uses POST /me/events. Microsoft Graph Explorer (graph.microsoft.com) is a free tool to test these endpoints. - Rewrite scripts using Microsoft Graph
Use the Microsoft Graph PowerShell SDK or the Microsoft Graph REST API directly. Register an application in Azure Active Directory with the required permissions (Mail.Send, Mail.Read, Calendars.ReadWrite, etc.). Replace all Outlook object references with Graph API calls. Test the new scripts in a sandbox environment before deploying to production.
If Your Automation Still Relies on Classic Outlook
Organizations with heavy MAPI automation dependencies should not migrate to new Outlook until all critical scripts and add-ins are rewritten. The following issues are common.
COM add-in does not load in new Outlook
COM add-ins are compiled against the classic Outlook object model. New Outlook does not load COM add-ins at all. The vendor must provide a web add-in built with Office.js or a Microsoft Graph integration. Check with your add-in vendor for a migration plan. If no web add-in is available, you cannot use that add-in in new Outlook.
VBA macro fails with runtime error 429
When you try to run a VBA macro in new Outlook, the VBA editor is missing entirely. Macros cannot be created, edited, or executed. Migrate VBA logic to a PowerShell script or a Power Automate flow that uses Microsoft Graph.
External application cannot create Outlook.Application object
Any external program that uses CreateObject(Outlook.Application) or New Outlook.Application will fail because the COM class is not registered. Rewrite the application to use the Microsoft Graph SDK for .NET or a direct REST API call.
PowerShell script using New-Object -ComObject Outlook.Application fails
This is the same root cause. The Outlook COM object is not available. Replace the script with the Microsoft Graph PowerShell module. Install the module with Install-Module Microsoft.Graph and use commands like Send-MgUserMail instead of $outlook.CreateItem(0).
| Item | Classic Outlook | New Outlook |
|---|---|---|
| Automation interface | COM (Outlook Object Model) | Microsoft Graph REST API only |
| VBA macros | Supported via Alt+F11 editor | Not supported |
| COM add-ins | Supported | Not supported |
| CDO (Collaboration Data Objects) | Supported | Not supported |
| PowerShell automation | New-Object -ComObject Outlook.Application | Microsoft Graph PowerShell SDK |
| External .NET automation | Microsoft.Office.Interop.Outlook | Microsoft.Graph .NET SDK |
| MAPI32.dll dependency | Yes | No |
| Offline automation capability | Works with cached OST file | Requires internet connection |
New Outlook cannot replace classic Outlook for MAPI automation because the entire automation layer is different. Classic Outlook uses a local COM object model that gives scripts direct access to the mailbox. New Outlook uses a web API that requires Azure AD authentication and REST calls. Organizations with existing MAPI automation should plan a phased migration to Microsoft Graph while keeping classic Outlook for users who depend on COM add-ins or VBA macros. For a complete list of supported Graph API operations, review the Microsoft Graph documentation at learn.microsoft.com/graph.