You’ve decided HubSpot no longer meets your needs. Dynamics 365 offers deeper integration with your Microsoft stack, better customisation for your specific processes, and cost advantages at scale. The decision makes sense. Then you look at five years of HubSpot configuration, hundreds of contacts, dozens of deals in various stages, and custom properties you’ve added to track information that doesn’t fit the standard HubSpot model.
The question shifts from “Should we move?” to “How do we move without losing data or disrupting the business?”
HubSpot to Dynamics 365 migrations are usually straightforward compared to moving from enterprise systems, but they come with their own gotchas. Most of them are about how HubSpot and Dynamics 365 think about data differently, not about technical impossibility.
This guide covers what breaks in a HubSpot to Dynamics 365 migration, why it breaks, and how to plan for it.
What Translates Cleanly
Start with what moves easily. HubSpot’s core objects map reasonably well to Dynamics 365:
- Contacts to contacts. HubSpot contacts become Dynamics 365 contacts. Basic fields (first name, last name, email, phone, company) map directly. Custom properties on contacts become custom columns in Dynamics 365 contact tables.
- Companies to accounts. HubSpot companies map to Dynamics 365 accounts. The same field-mapping logic applies: standard fields translate, custom properties become custom columns.
- Deals to opportunities. HubSpot deals become Dynamics 365 opportunities. Deal stages become opportunity pipeline stages. Deal properties become custom columns on the opportunity table.
- Associations between objects. HubSpot’s contact-to-company associations and deal-to-contact associations map to Dynamics 365 relationships. One contact linked to a company stays linked after migration.
- Basic automation. HubSpot workflows that send emails, create records, or update fields usually translate to Power Automate flows with straightforward logic. Simple workflows migrate cleanly.
- Contact lists. HubSpot static and dynamic contact lists can be migrated as Dynamics 365 views or segments, though the filtering syntax is different.
The gotchas come from how HubSpot and Dynamics 365 handle process, data structure and automation differently.
Contact and Deal Mapping: Where It Gets Awkward
These seem like simple mappings, but the details matter.
Contact-to-company relationships
In HubSpot, a contact is associated with a company, and that association can be primary or non-primary. One contact can be linked to multiple companies.
Dynamics 365 works differently. A contact has a primary account (a lookup field that points to one account). A contact can have other relationships to multiple accounts, but those relationships are secondary and need to be managed separately.
The gotcha: if your HubSpot setup relies on a contact being equally associated with multiple companies (both are “primary” in business terms), Dynamics 365 requires you to choose one as the primary lookup and store the others in a separate many-to-many relationship table or custom columns. This requires rethinking how you’ll use that relationship going forward.
Deal-to-contact associations
HubSpot lets you associate multiple contacts with a deal. A deal might have a primary contact (the decision maker) and secondary contacts (influencers, stakeholders).
Dynamics 365 opportunities also support this through the Connection table, which links opportunities to contacts with a role. But the mental model is different. You’re not just listing “associated contacts”; you’re creating explicit role-based relationships. That’s more structured, but it requires knowing the role of each contact upfront.
The gotcha: if your HubSpot deals don’t have consistent role definitions for associated contacts, you’ll need to decide during migration how to populate the role field in Dynamics 365. This often requires manual review.
Deal stage to pipeline stage
HubSpot deals have a stage (Negotiation, Proposal Sent, etc.). Dynamics 365 opportunities have a statecode (Open, Won, Lost) and a stagecode (Qualification, Proposal, Negotiation, etc.).
HubSpot doesn’t separate the concept of “open” from “won” until the deal closes. Dynamics 365 does. A Dynamics 365 opportunity is either open, won or lost. Stages only apply to open opportunities.
The gotcha: if your HubSpot deals don’t clearly indicate whether they’re actually won or lost, you need to make that decision during migration. A deal stuck in “Proposal” stage might actually be dead, but the HubSpot record doesn’t say so. Dynamics 365 will force you to decide: is this open, won or lost?
Email Sync and Engagement Data
HubSpot’s email sync is a built-in feature. Emails to and from contacts automatically appear in HubSpot, creating an audit trail.
Dynamics 365 doesn’t have automatic email sync out of the box. You need Server-side Sync (if using Exchange or Office 365) or a third-party tool to replicate this behaviour.
The gotcha: email history lives in HubSpot
When you migrate, your historical emails stay in HubSpot. They don’t automatically import into Dynamics 365. You can export them, but importing email history into Dynamics 365 is messy: you’re importing records (email activity records) rather than integrating live sync.
Many migrations accept this: “We’ll keep HubSpot as the historical email record for past deals, and Dynamics 365 is the source of truth going forward.” That’s a reasonable trade-off, but it creates a period where you have two systems to check.
Engagement tracking
HubSpot tracks email open rates, link clicks, document views. This engagement data is HubSpot-specific; it doesn’t have a direct Dynamics 365 equivalent.
Once you migrate, engagement tracking requires either keeping HubSpot for historical data or implementing a tool like Marketo or LinkedIn Sales Navigator that works with Dynamics 365. Many organisations accept that historical engagement data is lost and focus on forward-looking engagement in Dynamics 365.
Workflows and Automations: What Doesn’t Translate 1:1
HubSpot workflows are powerful, but they work differently from Dynamics 365 automations.
HubSpot workflows that don’t carry over cleanly
Workflows triggered by email engagement. HubSpot can trigger a workflow when someone opens an email or clicks a link. Dynamics 365 doesn’t have this trigger without a third-party tool. If you rely on engagement-based automation, you’ll need to rethink it in Dynamics 365.
Workflows triggered by form submission. HubSpot forms auto-create or update contacts. Dynamics 365 forms don’t auto-create contacts the same way. You can build forms that feed into Dynamics 365, but the mechanism is different. Form submission usually becomes a Power Automate trigger instead.
Workflows that update deal properties based on related contact activity. HubSpot can trigger a deal workflow if a related contact opens an email. Dynamics 365 automation (plugins or Power Automate) can do similar things, but the logic needs rebuilding.
Enrollment sequences. HubSpot sequences automatically enroll contacts into multi-step email cadences based on conditions. Dynamics 365 doesn’t have a direct equivalent. You can use Power Automate and email templates, but it requires rebuilding the logic.
What does translate
Simple field updates. A workflow that updates a property when a condition is met becomes a Power Automate flow or a Dynamics 365 business rule.
Record creation. A workflow that creates a contact or deal when a condition is met becomes a Power Automate flow.
Notifications. A workflow that sends an email notification becomes a Power Automate action.
The pattern is: simple conditional logic translates; logic that relies on HubSpot’s specific features (engagement tracking, form submissions at the platform level) needs redesign.
Data Quality: HubSpot-Specific Issues
HubSpot’s interface and process encourage certain data quality problems. When you migrate, these become visible.
Duplicate contacts
HubSpot makes it easy to create contacts, and it’s easy to end up with duplicates. The same person signed up from two different sources, or the same email address was entered slightly differently. HubSpot has merge tools, but many organisations have duplicate contacts that were never cleaned up.
Dynamics 365 is stricter about duplicates. You can create them, but the system doesn’t help you manage them. When you migrate, you need to decide: do you merge duplicates before you migrate (keeping HubSpot clean), or accept that Dynamics 365 will have the same duplicates and deal with them afterward?
Most organisations should merge before migration. It’s slower, but starting Dynamics 365 with clean data saves months of frustration.
Lifecycle stage mapping
HubSpot has a “Lifecycle Stage” property with standard values: Subscriber, Lead, Marketing Qualified Lead, Sales Qualified Lead, Opportunity, Customer, Evangelist.
Dynamics 365 doesn’t have a standard lifecycle stage property. You need to create one or use a different mechanism. The gotcha is deciding what lifecycle stage mapping looks like in Dynamics 365. Is a “Lead” in HubSpot a Dynamics 365 Lead record, or a Contact with a “Lead” status? The answer depends on your process, and it’s a decision that affects how you’ll use Dynamics 365.
Custom properties that don’t fit standard tables
HubSpot lets you add custom properties to contacts, companies and deals. Some of these are specific to your process. Examples: “Preferred contact method”, “Budget range”, “Industry segment”, “Competitor mentioned in discovery call”.
These migrate as custom columns in Dynamics 365. The gotcha is that Dynamics 365 doesn’t have “just add a property” simplicity. Custom columns need to be created, and if you have a lot of them, you’re deciding whether they belong on the contact table, a related table, or a custom table. That structural decision doesn’t exist in HubSpot; it becomes necessary in Dynamics 365.
Deal pipeline stages that don’t indicate closure
In HubSpot, a deal stays in a stage until you manually close it as Won or Lost. Some organisations use this loosely: deals linger in “Negotiation” or “Proposal” stages for months without being explicitly closed.
Dynamics 365 forces this decision: every opportunity is either Open, Won or Lost. A deal can’t just be stuck in Negotiation indefinitely without an explicit status. Before migration, you need to audit your HubSpot deals and decide which ones are actually lost and should be closed.
Contact data spread across properties
HubSpot contact properties often accumulate over time. You’ve got custom properties for things that might belong in a company (account) record, or in a related note, or in a task. Before migration, clean this up.
Dynamics 365 has a different data model. Account-level information belongs on the account table, not on individual contact records. During migration, you might need to consolidate data or create new relationships.
The Realistic Migration Approach
Given these issues, what actually works?
Audit your HubSpot setup first. Spend a week reviewing your contacts, companies and deals. Look for duplicates, lifecycle stage inconsistencies, and deals that are actually stalled rather than active. Decide what to fix before migration versus what you’ll accept in Dynamics 365.
Make decisions about relationships upfront. How will you represent contact-to-company associations that aren’t strictly primary? How will you handle contacts linked to multiple deals with different roles? Decide this before migration.
Plan email sync separately. Decide whether historical emails stay in HubSpot or whether you’re accepting that email history is lost and starting fresh in Dynamics 365.
Map workflows before you migrate. Review your HubSpot workflows. Categorise them: “This translates directly”, “This needs rebuilding”, “This is engagement-based and we’ll accept we lose it.” Don’t assume every workflow moves over.
Clean your data before migration. Merge duplicates, close stalled deals, standardise lifecycle stages and custom properties. It’s tedious, but starting Dynamics 365 with clean data saves months of cleanup afterward.
Run a pilot migration. Migrate a subset of your data (maybe last year’s deals and related contacts). Test it. Verify that deal associations work, that custom properties came across, that the data structure makes sense. Fix issues before you do the full migration.
What to Expect After Migration
The migration is the easy part. The harder part is using Dynamics 365 differently than you used HubSpot.
Dynamics 365 is more structured. Opportunities are open, won or lost. Contacts are linked to a primary account. Custom properties require more thought about where they belong. Automation is more explicit. This isn’t worse; it’s different. It gives you more control and structure, but it requires learning a different way of thinking about your data.
Budget time for your team to learn Dynamics 365. The features are more powerful, but they’re less obvious than HubSpot’s interface.
Your Next Step
If you’re evaluating a HubSpot to Dynamics 365 move, the first conversation should focus on your current HubSpot setup. How many contacts and deals? How many custom properties? How many active workflows? What does your data quality look like? Once you understand the scope, migration planning becomes a matter of categorising the work, deciding what needs rebuilding, and planning the data cleanup before you go live.
Book a discovery call to audit your HubSpot setup and plan a realistic migration, or explore how Dynamics 365 compares to HubSpot to understand whether migration makes sense for your business.
