Most failed dynamics to hubspot migration projects don't fail because of data volume. They fail because someone exported 200,000 Opportunities before deciding how Business Process Flow stages map to HubSpot deal stages. Or they moved Contacts before resolving Team-owned records and deactivated SystemUsers. Or they migrated Option Set values raw, and now every dropdown in HubSpot reads 100000002 instead of "Enterprise."
Dynamics 365 and HubSpot don't share a data model. Dynamics is built on a rigid, relational entity schema: polymorphic lookups, N:N intersect entities, integer-keyed Option Sets, Team-based ownership, and Business Process Flows layered on top of statecode and statuscode fields. HubSpot's model is flatter. It has Contacts, Companies, Deals, Tickets, Custom Objects, and Associations. There is no clean 1:1 translation between the two, and that gap is where migrations break.
This blog is about resolving those translation decisions before a single live record moves. That is exactly how a dynamics to hubspot migration goes from a three-to-six-week slog to a 3-4 day execution.
The mental model that sinks these projects is treating the migration as a "lift and shift": pull the records out of Dynamics, push them into HubSpot, done. That works when two systems share a schema. Dynamics and HubSpot do not.
Start with the Lead entity. Dynamics treats Leads as a first-class entity, fully separate from Contacts and Accounts, with their own qualification lifecycle. HubSpot's Lead object, introduced in 2023, is pipeline-oriented and limited[1]. It is not a full record type that carries decades of qualification history. So every Dynamics Lead needs a decision: does it become a HubSpot Contact, a Contact + Company pair, or a Lead-object record? Get this wrong across a segment and you either duplicate records or strand qualification history.
Then there's the polymorphic "Regarding" lookup. Every Dynamics Activity, whether a Phone Call, Email, Appointment, or Task, attaches to its parent through a single polymorphic field that can point at a Contact, an Account, an Opportunity, or a custom entity[2]. HubSpot's engagement model doesn't have a polymorphic anything. If the migration doesn't resolve what each activity is regarding and rebuild that association, you lose call and meeting history against the right record.
This is why the first two phases of any serious migration are discovery and mapping, not export. You resolve the schema mismatch on paper before you touch production data.
Here's the entity-to-object translation table that every dynamics to hubspot migration has to define explicitly. Each row hides a trap.
Leads → Contacts / Companies / Lead object. As above, this is a per-segment decision, not a global one. Marketing-sourced Leads with only an email often become Contacts. Qualified Leads tied to a named account become a Contact + Company pair. Getting the dedup key right here matters, and there's more on that below.
Contacts → Contacts. The cleanest mapping, but watch the ownership field and the Regarding-based activity links hanging off each record.
Accounts → Companies. HubSpot dedupes Companies on domain[3]. Legacy Dynamics Accounts frequently have no website populated, which means they'll either merge incorrectly or multiply on import if you don't set a dedup strategy in the mapping phase.
Opportunities → Deals. This is where Business Process Flow stages have to be translated into linear deal stages. It deserves its own section below.
Cases → Tickets. Straightforward object mapping, but the status and priority Option Sets need integer-to-label resolution, and the Regarding link back to the Contact or Account has to be rebuilt.
Activities → Engagements. The Activity table is almost always the largest object in a Dynamics org, with hundreds of thousands of records accumulated over years[4]. It is also the object most likely to be under-scoped. Phone Calls, Emails, Appointments, and Tasks each map to a HubSpot engagement type, and each carries a Regarding association that must survive.
Custom entities → Custom Objects (Enterprise) or flattened properties. Dynamics custom entities only land as HubSpot Custom Objects on the Enterprise tier[5]. On Professional or lower, they have to be flattened into properties on standard objects. That's a mapping-phase decision. You cannot discover it at execution and improvise.
In SuprSwitch, this translation happens in Phase 2, Mapping Logic. The transformation layer defines each entity-to-object rule, creates the required custom properties in HubSpot, and sets the association rules, all reviewed before the first record moves. The point is that nobody is deciding what a Lead becomes while 80,000 of them are already halfway through the pipe.
Two Dynamics constructs silently destroy relationship data if you ignore them.
The first is the polymorphic "Regarding" lookup on Activities. Because a single field can point at any parent entity type, a naive export dumps activities as a flat table with a GUID reference and an entity-type code. Push that into HubSpot without resolution and every call, email, and meeting lands as an orphan: technically imported, associated with nothing.
SuprSwitch handles this with association integrity mapping. It reads the Regarding entity type and GUID, resolves the target record in HubSpot, and rebuilds the engagement association so a Phone Call regarding an Opportunity lands against the correct Deal instead of floating in the void. This preserves the 1:1 relationship fidelity between the activity and its parent.
The second is N:N intersect entities. Dynamics models many-to-many relationships, such as Contacts to marketing lists or custom N:N entities, through intermediate intersect tables. HubSpot associations don't model arbitrary N:N the same way. Left unmapped, these relationships drop without an error message. You won't know a Contact was on twelve marketing lists until someone asks why segmentation is empty. These relationships have to be explicitly mapped to HubSpot associations or active list membership in Phase 2.
This is the single most misunderstood part of a dynamics to hubspot migration.
Dynamics Opportunities carry two things people confuse. There's statecode and statuscode, the underlying state (Open, Won, Lost) and the granular reason. And there's the Business Process Flow (BPF), a separate construct layered on top that defines the stages the rep actually clicked through: Qualify, Develop, Propose, Close.
HubSpot has no BPF equivalent. It has linear deal stages per pipeline. So the question is: what do you map to those deal stages?
If you map raw statuscode values, your pipeline history becomes fiction. The rep saw "Develop" in their process flow. Your HubSpot report shows "In Progress" because that's what the status field held. Every historical stage-conversion metric you build on that is wrong.
The correct approach is to map the BPF stage the rep actually progressed through to the corresponding HubSpot deal stage, and preserve statuscode, including closed-lost reason, as a separate property. Collapsing statecode and statuscode into one field loses closed-lost reason analysis, which is often the most valuable pipeline data you own.
In SuprSwitch, this BPF-stage-to-deal-stage logic is defined in Phase 2 and validated against a real spread of Opportunity stages during Phase 3, Pilot Validation, so you catch a mis-mapped stage on a sample of 50 deals, not across 50,000.
Two ownership problems will stop records from importing cleanly.
Deactivated SystemUsers. Enterprise Dynamics orgs accumulate years of disabled users who still own thousands of Opportunities, Contacts, and Activities. HubSpot cannot assign a record to a user seat that doesn't exist. Without a resolution pass, those records import unowned or fail outright, and routing and reporting collapse the moment go-live happens.
Team-owned records. Dynamics lets a record be owned by a Team, not just a user[6]. HubSpot only supports individual owner assignment. Every Team-owned record needs a resolution rule, whether that's reassign to a team lead, a round-robin of active reps, or a designated fallback owner, before migration, or ownership lands nowhere.
SuprSwitch's ownership transfer engine resolves both cases before the migration runs. Deactivated SystemUsers and Team-owned records are mapped to active HubSpot owners or a designated fallback during Phase 2, so nothing imports unowned. This is a pre-migration pass, not a post-migration cleanup, which is the whole point.
Three data-quality traps show up in nearly every Dynamics org.
Option Set integers vs. labels. Dynamics stores picklist values as integers with a separate label layer. A field showing "Enterprise" stores 100000002. Migrate the raw integer and every dropdown in HubSpot fills with meaningless numbers[7]. This is the most common Dynamics migration error, and it's entirely preventable with integer-to-label resolution defined in mapping.
statecode vs. statuscode. As covered above, both carry meaning, and collapsing them loses reason-level analysis. Map them to distinct HubSpot properties.
GUID identity vs. HubSpot dedup keys. Dynamics keys every record on a GUID. HubSpot dedupes Contacts on email and Companies on domain. Records with no email, which is common for Leads and legacy Accounts, will either merge incorrectly or multiply on import if the dedup strategy isn't set during mapping. You have to decide, per object, what the dedup key is before execution.
SuprSwitch's Phase 1 Schema Analysis surfaces these issues up front, including duplicate GUIDs, empty required fields, orphaned activities, and every custom Option Set, so they're resolved in the mapping layer rather than discovered mid-run.
The reason a dynamics to hubspot migration gets quoted at three to six weeks is almost never data volume[8]. It's manual field mapping done in spreadsheets, broken associations that surface mid-run, and post-migration cleanup that drags. SuprSwitch compresses this to 3-4 days by moving the discovery and validation work to the front.
Phase 1, Schema Analysis (Day 1). SuprSwitch scans the Dynamics org and identifies every custom entity, Option Set, record count, and data-quality issue, including duplicate GUIDs, empty required fields, and orphaned activities. Nothing moves. This is where the Lead-mapping and custom-object-tier decisions get made.
Phase 2, Mapping Logic (Day 2). The transformation layer maps every Dynamics entity to the HubSpot data model: Leads to Contacts/Companies/Lead object, Opportunities to Deals with BPF-stage-to-deal-stage mapping, Cases to Tickets, and Option Set integer-to-label resolution. Custom properties are created, association rules defined, and ownership transfer logic set. All of it is reviewed before the first record moves.
Phase 3, Pilot Validation (Day 2-3). A representative sample migrates to HubSpot, including a spread of Opportunity stages, activity types, and Team-owned records, to validate relational integrity, activity history formatting, field truncation, and association chains. Issues get fixed in the mapping layer, not after the full run.
Phase 4, Final Execution (Day 3-4). The full dataset runs through the migration engine with real-time record validation. Every record is validated as it lands, and failures flag immediately rather than surfacing three weeks later in a support ticket. The retry mechanism automatically re-runs failed records without restarting the full job, which is critical when the Activity table runs into hundreds of thousands of records.
One more thing that matters at enterprise scale: SuprSwitch's no-storage architecture means customer data is never held on SuprSwitch servers. For IT and security review, the step that usually stalls enterprise migrations, that shortens the sign-off considerably.
Real-time validation confirms records landed, but you still run a human audit before you flip the switch.
Record-count reconciliation. Match source counts to HubSpot counts per object: Contacts, Companies, Deals, Tickets, and each engagement type. Any gap larger than the known-bad records flagged in Phase 1 needs explanation.
Association spot-checks. Pull ten Deals across different pipeline stages and confirm their Contacts, Companies, and activity history are attached. Do the same for a handful of records that were Team-owned or owned by deactivated users in Dynamics, and confirm they now carry a valid HubSpot owner.
Pipeline-report sanity check. Build a deal-stage funnel and compare it to your last Dynamics pipeline report. If the shape is wildly different, your BPF-to-deal-stage mapping is off. Catch it now, not in a QBR.
A dynamics to hubspot migration is a schema-translation problem wearing a data-transfer costume. The records move easily. What's hard is deciding what a Lead becomes, how a Business Process Flow stage maps to a deal stage, where a Team-owned record's ownership lands, and how a polymorphic activity link gets rebuilt. Those decisions determine whether your pipeline history is accurate or fiction.
The projects that drag on for weeks aren't slow because Dynamics has a lot of Activity records. They're slow because those translation decisions get made mid-run, in a spreadsheet, after something has already broken. SuprSwitch inverts that order. Schema Analysis surfaces the traps on Day 1, Mapping Logic resolves them on Day 2, and Pilot Validation proves the mapping on a sample before the full dataset runs with real-time record validation and an automatic retry mechanism.
Do the translation work up front, validate on a pilot, and reconcile before go-live. That's the difference between a migration you spend three weeks cleaning up and one you confirm clean in four days.