Microsoft Dynamics 365 to HubSpot Migration

Configure each object type on its own: the native connector will not let you set up contacts, companies and deals together, only one at a time. For a Dynamics estate that has grown complex across several regional entities, that sequential setup is where the real time goes before a single record has moved.

Workaround: Sequence the setup deliberately: contacts, then companies, then deals, then everything else, and let each object finish syncing before the next one starts. Build that sequencing into the project plan you take to committee, since it is time the estimate has to account for rather than a detail to discover mid-build.

A dropdown, radio select, multi-select or checkbox field will not sync both ways: it flows one direction only, from Dynamics into a plain text field on the HubSpot side. Structured data arrives unstructured, and that is exactly the field type carrying emirate, jurisdiction and licence-category values that a regional record depends on.

Workaround: Build the matching dropdown or select properties in HubSpot by hand, then use Data Hub or a workflow to turn the arriving text back into structured values. Do this for the regional lists first: emirate, jurisdiction, nationality, since those are the ones most likely to have been typed by hand for years.

Lookup, or reference, fields are outside what the native connector supports, which means the relational links between Dynamics records carry no equivalent field value once they reach HubSpot. Anything a Dynamics entity model built its structure around is exactly what does not travel.

Workaround: Store the reference as a text-based ID field instead, then map the association by hand once the sync has run. Where the relational structure is genuinely complex, Power Automate, Make or n8n as middleware is worth the setup, particularly for a group structure that never reduces cleanly to a single lookup.

The default field mappings come free on any HubSpot plan; a custom field mapping between Dynamics and HubSpot does not, and needs a paid Data Hub subscription before it will run. Given how much of a Microsoft-estate deployment is customised beyond the defaults, budget for Data Hub from the outset rather than after the first mapping fails.

Workaround: Move to Data Hub Starter or above, or stay on the default mappings and fill the gaps with CSV imports or an API-based field transfer. Either way, put the decision and its cost into the same procurement submission as the rest of the migration rather than raising it once the committee has already signed off a number.

Line items on a deal sit outside what the native Dynamics 365 connector will sync at all, and the gap runs both ways: a price you change on a HubSpot deal record never reaches the Dynamics sales order it created. Anyone reconciling revenue between the two systems needs to know which side is authoritative before go-live, not after finance finds the mismatch.

Workaround: Move line items by hand, through a CSV import or the API, and if the two systems need to stay in step afterwards, put middleware in place for ongoing synchronisation rather than relying on the native connector to pick it up.

Dynamics 365 marketing lists have no native path into HubSpot's active lists or segments: nothing keeps the two in sync automatically.

Workaround: Rebuild the lists in HubSpot using filters and properties rather than expecting a transfer, and where the membership itself matters, export it from Dynamics and bring it in as a contact property. Do this early for any list a regional campaign calendar depends on, Ramadan or Eid promotions among them, since those are the lists most likely to be needed again within weeks of cutover.

The native connector holds strictly to one record on each side: a single HubSpot contact cannot generate or sync to more than one Dynamics lead, even though a Dynamics implementation built around repeat enquiries from the same buyer often depends on exactly that. Where a single contact opens more than one opportunity, at different entities in a group or in different markets, that structure does not survive the sync as built.

Workaround: Bring in middleware, Power Automate, Make or n8n, wherever the relationship is genuinely many-to-one or one-to-many, or redesign the data model around the one-to-one constraint the native connector actually enforces. Decide which route before the sync goes live: retrofitting middleware after records have already landed wrong is a second project on top of the first.

Parent-child account hierarchies and the territory rollups built on top of them do not survive the native sync at all. For a group that trades through a holding company and several operating or free-zone entities, that hierarchy is usually the only record of which accounts actually belong together, and losing it is losing the structure, not just a field.

Workaround: Recreate the parent-child company associations in HubSpot by hand, hold the territory information in custom properties, and rebuild the territory logic itself using HubSpot Teams and workflows. Give this rebuild to whoever already knows which entities in the group are one customer, because that is knowledge no import script carries with it.

Dynamics opportunity status codes and stages rarely map onto HubSpot deal stages without a gap, and where they do not, revenue gets attributed to the wrong stage or the wrong period. That is the kind of discrepancy a finance committee notices in the first board pack after go-live, not a cosmetic mismatch.

Workaround: Write the stage mapping document before a single opportunity moves, configure the HubSpot pipeline to mirror the Dynamics stages it replaces, and use a milestone-mirroring approach so a deal's position reads the same in both systems while they run in parallel.

Dynamics assigns through queues; HubSpot assigns through round-robin, and the two logics do not translate cleanly, which shows up as lead routing conflicts once both are running. Decide which model the sales organisation will actually keep before the sync is switched on, not while leads are landing with nobody assigned.

Workaround: Set the owner mapping rules before the sync runs, name one system as the source of truth for ownership, and use conditional sync logic to stop the owner field being silently overwritten from the other side. Confirm the source-of-truth decision with the country or division heads who actually run the queues, not with the project team alone.

An activity logged offline in Dynamics, through the mobile app with no connection, for example, may simply never reach HubSpot at all. Where field sales or site visits are the norm rather than the exception, and connectivity on a construction site or a remote project is not guaranteed, that gap can be a meaningful share of the activity record.

Workaround: Make offline sync a habit before go-live, not an assumption: confirm every Dynamics user has synced their offline activity before expecting it in HubSpot. Where that discipline cannot be guaranteed across a distributed field team, sync a summarised Last Activity Date instead of trying to carry every individual entry.

A task tied to a Dynamics Lead moves one way only, from Dynamics into HubSpot, and never back. Two-way task sync needs the task associated with a Contact or another supported object instead, so the direction a task travels depends on what it is attached to, not on the task itself.

Workaround: Attach tasks to contacts rather than leads wherever the process allows it, and where a task has to sit against a lead, accept the one-way sync rather than building a workaround for it.

Sync everything bidirectionally and a race condition becomes possible: whichever system wrote last wins, which can silently overwrite a change someone intended to keep. In a team spread across time zones or working staggered hours around Ramadan, last write wins is not always the same as correct write.

Workaround: Set clear ownership per field rather than leaving every field open to both systems: run owner, stage and revenue one-way only, since those are where conflicts bite hardest, and implement conditional sync logic through middleware for anything more nuanced.

Microsoft Dynamics 365 is on HubSpot's list of supported apps for custom object sync, but the listing is more optimistic than the field reports: a complex custom entity does not always sync reliably through the native Data Sync connector, and one with genuinely complex relationships may need a third-party tool regardless of what the listing promises. Treat 'supported' as a starting point to test, not a guarantee, particularly for the entities modelling units and towers, tenders, or licensed products that a regional deployment tends to build custom around.

Workaround: Test every custom entity in a sandbox before trusting it in production, and where the sync proves unreliable, move to a third-party tool: Make, Power Automate or a custom Azure Function are all realistic given a Dynamics estate already sits inside Microsoft's ecosystem. An API-based custom integration is the fallback if none of those close the gap.

File attachments and documents held in Dynamics 365 do not move through the native Data Sync connector at all. Trade licence copies, tender submissions and signed contracts sitting on a Dynamics record are exactly the files this gap leaves behind.

Workaround: Smart Transfer's one-time transfer is the route for attachments; for anything it misses, download and re-upload the critical files by hand, and script the transfer through the API where the volume is too large for a manual pass. Prioritise the licence, tender and contract documents first: they are the ones a retention review asks for.

Every Power App in your estate needs rethinking from its purpose outward, not a straight port: a model-driven app maps partially onto HubSpot record customisation, while a canvas app has no equivalent at all and needs external web application development to replace it. Work through each app's purpose, its user base and how critical it actually is to the business before committing to a rebuild, because a Power Apps estate of any size is often a major project sitting inside the wider migration rather than a task within it.

Every plugin in your Dataverse estate is custom .NET code with no direct equivalent in HubSpot, so each one needs individual analysis: does the logic become a workflow, a custom code action, or does it need an external service running alongside HubSpot instead? Pre-operation and pre-validation plugins are the hardest of the three, because HubSpot has no server-side point in the save sequence that can block a record from saving the way these do. Count every plugin in the estate before estimating the rewrite, not after.

An Azure integration is rarely a single connection: Service Bus, Functions, Logic Apps and the rest tend to sit deep inside the wider enterprise architecture, so every touchpoint needs its own evaluation rather than a blanket assumption either way. Some can simply redirect to the HubSpot API; others need rearchitecting from scratch. Where your organisation is heavily invested in Azure, treat this as a major workstream of its own rather than a subtask of the CRM move.

If your organisation runs Dynamics CRM and Dynamics Finance & Operations together, dual-write is doing real work today keeping customer, product and financial data in step across both, and moving the CRM half to HubSpot breaks that native sync outright. A custom integration between HubSpot and the ERP side has to replace it, so map every data flow running between CRM and ERP before the migration plan is written, not after.

structured data becomes unstructured the moment it crosses over, and the emirate, jurisdiction and nationality lists are usually the first to feel it

Lookup and reference fields carry no native sync path at all, which means relational data is lost unless it is caught and rebuilt separately

Account hierarchies and territory rollups break during migration, taking with them the only record of which entities in a group actually belong together

Opportunity status codes may not align between the two systems, and when they do not, revenue gets attributed against the wrong stage or period

Owner mapping conflicts arise between Dynamics queues and HubSpot's round-robin assignment, and they surface as leads landing with the wrong owner or none at all

Activities logged offline in Dynamics, from a mobile app with no connection, may never appear in HubSpot at all, which matters most for field teams working sites with patchy coverage

Tasks associated with a Lead sync one way only, Dynamics to HubSpot, and never travel back

Deal line items do not sync at all and have to be migrated as a separate step, on their own timeline

One HubSpot contact cannot map to more than one Dynamics lead, a real limit for any buyer who opens more than one opportunity across a group's entities

Custom field mappings need a paid Data Hub subscription; without it, only the default mappings are available, and the fields a regional record is actually identified by, trade licence number, VAT registration, entity of record, are almost always the custom ones

Every Power Platform integration connected to Dynamics, Power Apps, Power Automate and Power BI among them, loses its data source the moment Dynamics stops being the system of record, which is often the moment the true scope of leaving a Microsoft estate becomes clear

Lifecycle stages can get silently overwritten by automated marketing workflows, which produces false SQL counts that a sales leader will eventually notice do not match the pipeline

use the phased approach instead, 5 records, then 50, then full production, validating at each stage before scaling to the next

One mismatched column, or a single incorrect field mapping, is enough to import thousands of records wrong, which is why the 5-record and 50-record validation stages exist rather than trusting the mapping document alone