Classic Outlook to New Outlook: Content Forms – Migration options for custom form users

If you use custom forms in Classic Outlook for tasks like expense reports, time tracking, or customer feedback, the transition to New Outlook can disrupt your workflow. Custom forms built with the Outlook Form Designer rely on VBScript and COM add-ins, which New Outlook does not support. This article explains the technical differences between Classic and New Outlook forms and provides three migration paths: re-creating forms as Power Apps or adaptive cards, using third-party migration tools, and hybrid coexistence strategies.

You will learn the specific steps to export form definitions, convert them to supported formats, and test them in New Outlook before decommissioning your Classic Outlook forms. The goal is to retain your business logic without losing data or interrupting daily operations.

Why Classic Outlook Custom Forms Break in New Outlook

Classic Outlook custom forms are built using the Outlook Form Designer, which generates a form definition stored inside a message class. The form definition includes VBScript code for business logic, custom fields, and layout. New Outlook, built on a web-based Outlook on the web architecture, does not load VBScript or COM add-ins. It uses a different rendering engine that supports only HTML, CSS, JavaScript, and Microsoft Power Platform components.

When you open a message with a custom form class in New Outlook, the client ignores the form definition and displays the default Outlook item view. Form fields and scripts are invisible or nonfunctional. This is not a bug. It is a deliberate architectural change. Microsoft recommends migrating custom form functionality to Power Apps, Adaptive Cards, or custom add-ins using the Office JavaScript API.

What Happens to Form Data

The data stored in custom fields remains in the Exchange mailbox or PST file. New Outlook can display standard Outlook properties like Subject, To, and Body. Custom fields defined in the form definition are still present in the item, but New Outlook does not render them unless you extract them via a script or a third-party tool. The data is not lost, but the user interface for entering or viewing that data is gone.

Message Class Registration

Classic Outlook registers custom forms under a custom message class, for example, IPM.Note.CustomFormName. New Outlook does not recognize custom message classes. It treats all items as standard IPM.Note or IPM.Appointment. Any form publishing to the Organizational Forms Library or Personal Forms Library is ignored.

Three Migration Options for Custom Form Users

Choose the migration path that matches your technical resources and timeline. All three options preserve your form data and business logic.

Option 1: Re-create Forms as Power Apps or Adaptive Cards

This is the recommended path from Microsoft. Power Apps and Adaptive Cards run in New Outlook, Teams, and the web. They support rich input fields, data connections, and approval workflows.

1. Export the form definition from Classic Outlook
   Open the custom form in Classic Outlook. Go to File > Options > Custom Forms > Manage Forms. Select the form and click Save As to save it as an .oft file. This file contains the form layout, fields, and VBScript code.
2. Document the fields and logic
   Open the .oft file in a text editor. List every custom field name, data type, and validation rule. Note the VBScript event handlers like Item_Open or Item_Send. These must be re-implemented in Power Fx or JavaScript.
3. Create a Power App
   Go to make.powerapps.com. Create a new canvas app. Add screens and controls that match your original form layout. Use SharePoint lists or Dataverse as the data source. Connect each Power Apps control to the corresponding custom field.
4. Replace VBScript logic with Power Fx formulas
   For example, if your form validates a date range on send, write a Power Fx formula in the OnSelect property of a submit button. Test the app in the Power Apps player.
5. Publish the app to New Outlook
   In Power Apps, select Share and choose Outlook as the deployment channel. Users open the app from the Apps icon in New Outlook. They no longer need to open a specific message class.

Option 2: Use Third-Party Form Migration Tools

If you have many forms with complex logic, third-party tools can automate the conversion. These tools read the .oft file and generate a web-based form or add-in.

1. Evaluate a migration tool
   Tools like CodeTwo Outlook Forms Migrator or Add-in Express Outlook Forms to Web Converter scan your Exchange environment for published forms. They create a report of all custom message classes.
2. Run the conversion
   Select the forms you want to migrate. The tool exports field definitions and VBScript code. It generates an HTML form or a JavaScript add-in. Review the output for missing logic.
3. Deploy the new form or add-in
   Upload the generated file to a web server or to the Microsoft 365 App Catalog. Assign the solution to test users via the Microsoft 365 admin center.
4. Redirect existing data
   Some tools create a link between old items and the new form. Users open an old item, click a button, and the data appears in the new form. This prevents data from being stranded.

Option 3: Hybrid Coexistence with Classic Outlook

If your organization cannot migrate all forms immediately, keep Classic Outlook for form-heavy tasks while using New Outlook for standard mail. This is a temporary workaround.

1. Set a coexistence policy
   Use Group Policy or the Microsoft 365 admin center to allow Classic Outlook alongside New Outlook. Users who need custom forms launch Classic Outlook from the Windows Start menu. All other users run New Outlook by default.
2. Communicate the transition plan
   Tell users that custom forms work only in Classic Outlook. Provide a timeline for migration. Schedule training sessions for the new Power Apps or Adaptive Cards forms.
3. Migrate one form at a time
   Start with the most-used form. Follow Option 1 or 2. After testing, disable the Classic Outlook form by unpublishing it from the Organizational Forms Library. Monitor user feedback for two weeks.

If Custom Forms Still Do Not Work After Migration

Even after following one of the migration options, you may encounter issues. Here are the most common problems and their fixes.

Power App Does Not Load in New Outlook

If your Power App appears blank or does not open, the app may not be assigned to the correct users. Go to the Power Apps maker portal, select your app, and click Share. Add the security group or individual users. Ensure they have a Power Apps license. In New Outlook, click Apps and pin the app to the sidebar.

Old Items Show Default Outlook View Instead of Custom Form

This is expected. New Outlook cannot render the old form definition. To access the data, use the Power App or Adaptive Card that you created. Include a lookup feature that searches by Subject or custom field. Alternatively, export old items to Excel using a PowerShell script that reads the custom fields and uploads them to your new data source.

Third-Party Tool Generates Code with Errors

If the converted form has broken buttons or missing fields, the VBScript code may have been too complex for the tool to translate. Manually review the generated HTML or JavaScript. Replace unsupported functions like CDO.Message with XMLHttpRequest calls to Microsoft Graph. Contact the tool vendor for a patch or custom conversion.

Classic Outlook Custom Forms vs New Outlook Forms: Key Differences

Item	Classic Outlook Custom Forms	New Outlook Forms
Rendering engine	Outlook Form Designer (MAPI-based)	Web-based (OWA rendering)
Scripting language	VBScript	Power Fx, JavaScript, or no code
Storage location	Exchange mailbox or PST	SharePoint, Dataverse, or external web server
Message class support	Custom IPM classes	Standard IPM classes only
Deployment method	Publish to Organizational Forms Library	Power Apps deployment or App Catalog
Offline capability	Full offline with cached mode	Limited offline (Power Apps requires network)
Add-in compatibility	COM add-ins	Office JavaScript API add-ins

The table above shows that New Outlook forms require a network connection and a modern scripting environment. Classic Outlook forms work offline but are tied to the old MAPI stack. Plan your migration based on your users’ offline requirements and the complexity of your existing VBScript logic.

You now have three concrete migration paths for moving custom forms from Classic Outlook to New Outlook. Start by exporting your .oft files and documenting each form’s fields and logic. If you have fewer than ten forms, re-creating them in Power Apps is the fastest path. For large form libraries, evaluate a third-party migration tool to reduce manual work. As a final step, test each new form with a pilot group before disabling the Classic Outlook version. Use the coexistence option to run both clients side by side during the transition.