Dynamics 365 to HubSpot Workflow Migration Guide

 Data moves. Automation does not. A Dynamics 365 to HubSpot workflow migration is not an export and import, because there is nothing to export: classic workflows, business rules, Power Automate flows and plug-ins are logic that lives in Dataverse, and HubSpot has no way to read it. Every rule your team depends on has to be understood, documented and rebuilt.

This guide covers how Dynamics 365 workflows and business rules work, how to audit what you have, how to map each process to HubSpot workflows, how to rebuild triggers, conditions and actions, how to handle field-level logic, which automation needs custom development, and how to test the result before launch.

How Dynamics 365 Workflows and Business Rules Work

Dynamics 365 automation sits on Microsoft Dataverse, and it comes in several forms. Microsoft Learn groups them as business rules, Dataverse processes (real-time workflows and actions) and Power Automate flows, including business process flows and cloud flows. Most orgs also have plug-ins written by developers.

Classic workflows. Microsoft describes workflows as automation that runs without a user interface. They come in two types: background workflows, which Microsoft says run asynchronously when the system has resources available, and real-time workflows, which run immediately and synchronously. Their steps include creating, updating and assigning rows, sending email, changing status, starting child workflows, checking conditions and waiting until a condition is met. Developers can add custom steps.

Power Automate flows. Microsoft now recommends building new automation as Power Automate flows instead of classic workflows, and reviewing existing background workflows for replacement. Many Dynamics 365 orgs therefore have a mix of both.

Business rules. Microsoft Learn describes business rules as a simple interface for fast-changing, commonly used rules. They can set or clear column values, set defaults and validate data with an error message. Some actions only apply when the rule is scoped to forms: setting a column's requirement level, showing or hiding columns, enabling or disabling columns, and business recommendations. A rule scoped to the table (Entity) applies to model-driven app forms and the server.

Business process flows. These guide users through stages on a form. Microsoft describes them as a set of steps in a model-driven app that people follow to reach an outcome.

The distinction matters because each type maps to a different HubSpot feature. Server-side workflows usually become HubSpot workflows. Form behavior usually becomes property settings, pipeline settings or record layout changes.

Audit Existing Dynamics 365 Automation

You cannot rebuild what you have not found. Before you migrate Dynamics workflows to HubSpot, start with a complete inventory of Dynamics 365 automation, including items nobody remembers creating.

Pull every process from the solution or the Processes area, plus every Power Automate flow that uses the Dataverse connector, every business rule per table and every registered plug-in step. For each item, record:

• Name and type: Classic background workflow, real-time workflow, business rule, business process flow, cloud flow or plug-in.
• Status: Activated or draft. Draft processes can usually be ignored.
• Table and trigger: Which table it runs on and what starts it, such as create, update of a column, status change or schedule.
• What it does: A plain language summary of the conditions and actions.
• Owner: The team that relies on it and the person who can confirm it is still needed.
• External calls: Any custom step, plug-in or connector that reaches another system.

Then sort every item into one of four buckets: rebuild as is, rebuild in a simpler form, replace with a native HubSpot setting, or retire. Retiring is common. Workflows created for a campaign years ago, rules for fields that are no longer used and flows that duplicate each other are all frequent finds. Every one you retire is one less thing to build and test.

Map Dynamics 365 Processes to HubSpot Workflows

Once the inventory is complete, map each item to the HubSpot feature that will replace it. HubSpot workflow automation covers most server-side processes. HubSpot's knowledge base states that workflows are available on Professional and Enterprise subscriptions across its hubs, so confirm the subscription before the design is final.

Map one process to one HubSpot workflow where you can. Dynamics orgs often have several small workflows on the same table and trigger. Combining them into one HubSpot workflow with branches is easier to maintain than rebuilding each separately.

If the workflow rebuild is part of a full Dynamics 365 to HubSpot migration,plan it alongside the data mapping. Workflows depend on property names, pipeline stages and owners, so they should be built after those are final and before users go live.

Rebuild Workflow Triggers Conditions and Actions

Rebuild each process in three parts: what starts it, what decides its path, and what it does.

Triggers. HubSpot describes enrollment triggers as criteria that automatically enroll records in a workflow, and lists filter-based, event-based, schedule-based and webhook-based triggers, plus manual enrollment. A Dynamics workflow that starts on create usually becomes an event trigger for record creation. One that starts when a column changes becomes a property value trigger. A scheduled cloud flow becomes a schedule-based trigger.

Re-enrollment. This is the most common source of rebuilt workflows that only run once. HubSpot notes that re-enrollment is off by default, and that a record can only re-enroll after it has completed the workflow. If the Dynamics workflow ran every time a column changed, turn on re-enrollment for that trigger.

Conditions. Dynamics Check Condition and Conditional Branch steps map to HubSpot branches. HubSpot supports branches based on a single property or on AND/OR logic. Wait conditions map to HubSpot delays, which can wait for a set time, a date property, a calendar date or an event.

Actions. Most Dynamics steps have a direct HubSpot action:

• Create row: Create record.
• Update row: Edit record, which HubSpot describes as setting, editing, copying and clearing property values.
• Assign row: Edit the owner property, or rotate record to owner for round robin assignment.
• Send email: Send internal email notification for staff, or send email for contacts.
• Change status: Edit the status or stage property.
• Start child workflow: Go to another workflow, or move the steps into the parent.

Rebuild the workflow from your audit summary, not by copying the Dynamics designer step by step. The aim is to reproduce the outcome, which is often simpler in HubSpot than it was in the original.

Handle Business Rules and Field-Level Logic

Dynamics 365 business rules are mostly form behavior, and HubSpot handles form behavior differently. Treat each business rule according to what it does.

• Required fields: HubSpot lets you mark properties as required on the create form, and as conditional stage properties when a record moves into a pipeline stage. HubSpot states that users cannot create or update the record until required properties are filled.
• Validation with an error message: Simple checks such as number ranges can often be enforced through property settings. More complex validation may need a workflow that flags or corrects the record after save.
• Set or clear a value: Use a workflow that edits the record. Note the difference: the business rule changes the form before save, while the workflow changes the record after save.
• Show or hide, enable or disable: Use conditional logic on dropdown properties, record layout customization or field level permissions, depending on the case.
• Stage controls from business process flows: Use pipeline rules. HubSpot's pipeline rules can restrict skipping stages, restrict moving backwards and control who can edit records in certain stages, on Professional or Enterprise subscriptions.

Some form behavior has no exact HubSpot equivalent. When that happens, decide with the business owner whether the rule still matters, and whether a post-save check is acceptable.

Identify Automation That Requires Custom Development or Integrations

Some Dynamics 365 automation cannot be rebuilt with standard workflow actions. Identify it early because it drives cost and timeline.

• Plug-ins and custom workflow activities: These are .NET code registered in Dataverse. They cannot run in HubSpot. Rewrite the logic as a HubSpot custom code action, an external service called by a webhook, or an integration.
• Calls to other systems: Cloud flows that use connectors to an ERP, finance tool or data warehouse need a HubSpot integration or a middleware platform in their place.
• Synchronous blocking logic: Real-time workflows and plug-ins that stop a save when a condition fails have no direct equivalent, because HubSpot workflows run after the record is saved. Use required properties and pipeline rules where possible, and accept post-save correction where not.

HubSpot's knowledge base lists the webhook and custom code workflow actions as Data Hub Professional and Enterprise only. Confirm your subscription includes them before planning a rebuild that relies on code.

For each item in this group, write a short specification: inputs, logic, outputs, error handling and who owns it after launch.

Test and Validate Migrated Workflows

Test every rebuilt workflow before users rely on it. Build in a HubSpot sandbox if your subscription includes one, or keep new workflows switched off until they pass.

For each workflow, create test records that cover every branch, including records that should not enroll. Run them through and confirm:

• The right records enroll, and the wrong ones do not.
• Each branch sends the record down the expected path.
• Every action fires once, with the expected values.
• Re-enrollment behaves as the Dynamics workflow did.
• Required properties and pipeline rules block the moves they should block.

HubSpot's workflow documentation notes that when a workflow is throttled, actions queue rather than running immediately. Test with realistic volumes before launch, especially for workflows that run on imports or bulk updates.

Run the rebuilt workflows in parallel with the source system's outcomes for a short period if you can. Compare assignments, notifications and stage changes on the same records in both systems.

Common Workflow Migration Challenges

The same problems appear in most Dynamics 365 workflow migration projects:

• Undocumented automation. Plug-ins and old workflows run quietly until they are switched off. A complete audit prevents surprises after go-live.
• Assuming real-time behavior. HubSpot workflows run after save, so logic that blocked a save in Dynamics needs a different design.
• Re-enrollment left off. A workflow that should run on every change runs once.
• Rebuilding before data is final. Workflows built on property names or stages that later change break silently.
• Too many small workflows. Recreating every Dynamics process one to one leaves a portal that is hard to maintain.
• Missing subscription features. Custom code, webhooks and some pipeline features need specific tiers.
  
  

Conclusion

A successful CRM process migration from Dynamics 365 comes down to a few decisions: which automation to retire, which to rebuild as HubSpot workflows, which business rules become required properties or pipeline rules, and which logic needs custom code or an integration. Make those decisions from a complete audit, rebuild against outcomes rather than steps, and test every workflow on real scenarios before launch.

Start with the inventory, because it turns an unknown into a list your team can work through. If you would rather have a team handle the rebuild, OneMetric's HubSpot CRM migration services include workflow audits and rebuilds alongside the data move. To talk through your own Dynamics 365 automation, get in touch with OneMetric.