Dynamics 365 to HubSpot Data Mapping: Entities, Fields, and Relationships

Your Dynamics 365 export shows thousands of accounts, contacts, and opportunities. The records have names, owners, dates, and values. At first glance, the migration looks like a matter of matching columns and importing the files.

Then your team starts asking questions.

One customer has several subsidiaries. An opportunity has multiple stakeholders. A custom entity tracks the products installed at each location. Sales wants open pipeline to match the existing dashboard, while customer success needs to see the history behind each account.

Those requirements depend on how records relate to one another and what each field means. If the data arrives in HubSpot without that context, the record count may look right while the CRM becomes harder to use.

Dynamics 365 to HubSpot data mapping gives the migration team a way to make those decisions before the import. This guide explains how to map entities, fields, and relationships, and how to validate that the destination supports the work your teams need to do.

Why Data Mapping Matters in a Dynamics 365 to HubSpot Migration

Data mapping is the process of deciding where source information should go, how it should be represented, and what should happen when the source and destination work differently.

A mapping document might say that a Dynamics 365 account becomes a HubSpot company. It should also explain which account fields move, how owners are assigned, how duplicate accounts are handled, and how related contacts and opportunities will be connected.

Without those decisions, migration teams are left to make assumptions during the load.

Consider a Dynamics 365 field called “Account Status.” It might describe whether a customer has an active contract. A similarly named HubSpot property might be used by sales to track prospecting activity. Mapping the two based on their names could mix customer status with sales progress.

Good mapping connects technical fields to business definitions. It also gives users and project owners a way to review the proposed destination before data is imported.

The mapping should cover more than the destination property. For important fields, include the source definition, data type, allowed values, transformation rules, owner, and validation method. Record decisions about fields that will be excluded or archived as well.

Understand Dynamics 365 Entities and HubSpot Objects

Dynamics 365 applications use Microsoft Dataverse to store information in tables, which are also commonly referred to as entities. Each table contains rows and columns, and relationships connect records across tables.

HubSpot organizes CRM information through objects, records, properties, and associations. A company record may be associated with several contacts and deals, while a deal contains properties such as its amount, owner, and stage.

The terminology is similar enough to make direct mapping tempting. The underlying business use still needs review.

A Dynamics 365 entity may contain information that belongs across several HubSpot objects. Equally, multiple source fields or entities may be better represented through a simpler destination structure.

Before designing the mapping, ask:

• What does this entity represent in the business?
• Who creates and maintains its records?
• Which teams use the information?
• What other records is it connected to?
• Which reports, processes, or integrations depend on it?

The answers help you design HubSpot around the work users need to perform.

Map Standard Entities to HubSpot Objects

Standard Dynamics 365 entities provide a useful starting point, but the final mapping depends on your configuration.

These mappings should be tested against actual records before they are approved.

Accounts and companies

Dynamics 365 accounts often represent organizations, but some businesses also use them for branches, billing entities, partners, or individual locations.

Decide which of these need separate HubSpot company records and how they should relate. A shared domain alone may not be enough to determine that two records are duplicates if they represent separate legal entities.

Review parent and subsidiary relationships, account owners, and customer classifications. Agree on the matching rules before importing into an existing HubSpot account.

Leads and contacts

Dynamics 365 may contain separate lead and contact records for the same person. Before mapping both to HubSpot, identify overlaps and agree on how they will be matched.

A lead without an email address may still be important to sales. Define how such records will be identified and reviewed instead of silently excluding them.

Preserve the information needed to understand qualification, including the source status, owner, and relevant dates where required. Decide which historical lead fields remain useful after the move.

Opportunities and deals

Map each opportunity to the appropriate HubSpot deal pipeline and stage based on the sales process it represents.

A Dynamics 365 opportunity marked “Qualified” should not be assigned to a HubSpot stage with the same name unless both stages mean the same thing. Review the entry criteria and reporting purpose of each stage.

Check deal amounts and dates as well. Confirm whether the source value represents the full contract, an annual amount, a forecast amount, or another measure before using it in HubSpot reporting.

Map Custom Entities, Fields, and Properties

Custom Dynamics 365 entities often contain information that is central to how the business operates. They may track contracts, locations, assets, subscriptions, applications, or partner relationships.

Start with the business requirement before deciding whether to create a HubSpot custom object.

For example, a company may have several active subscriptions, each with its own product, value, start date, and renewal date. Storing one “Renewal Date” on the company would lose that detail. The destination needs a way to represent each subscription and connect it to the right customer.

A different custom entity might contain information that fits an existing standard object or belongs in an external system. The decision should account for how records will be created, updated, associated, and reported on after migration.

Custom objects require an eligible HubSpot Enterprise subscription, so confirm the destination design and commercial requirements together.

Map field meaning and data type

A field mapping document should explain what each source value means and how it will be represented in HubSpot.

Repeat this process for important dates, currencies, owners, statuses, and calculated values.

Choice fields need particular attention. Two options may have similar labels but different meanings, and old values may still appear on historical records. Dataverse choice columns use defined options, so document how every value in scope will be handled.

Calculated fields also require a decision. Importing the current result preserves a value at one point in time. If the value must continue changing, identify how the calculation will be maintained after migration.

Handle Entity Relationships and Associations

Relationships give CRM records context.

A contact may belong to a company, influence several opportunities, and have a different role in each one. An opportunity may connect to a customer account, a billing entity, and several stakeholders.

Dynamics 365 relationships need to be represented through the appropriate HubSpot associations and, where required, association labels. Microsoft Dataverse supports different relationship types, including one-to-many and many-to-many relationships.

For example, if one contact is linked to three opportunities, the migration needs to preserve all three connections. Importing the contact and opportunities separately without an association plan may leave sales users unable to see that relationship.

Use stable identifiers to match records. Source record IDs can help track which Dynamics 365 record corresponds to each HubSpot record. HubSpot also supports specified unique identifiers for imports and associations, depending on the object and import method.

Agree on the loading sequence and association method before the final migration. Where association labels are required, confirm that they are available in the selected HubSpot subscription and supported by the chosen import approach.

Test complex examples, including parent and child accounts, multiple contacts on one deal, and records linked across custom entities. The goal is to confirm that users can navigate the customer relationship correctly.

Clean and Transform Data Before Migration

A migration is a useful point to improve data quality, but cleanup should follow agreed business rules.

Start by profiling the source data. Look for duplicate records, missing owners, inconsistent dates, inactive users, outdated statuses, and values that no longer match the current process.

Then decide how each issue will be handled. Some duplicates can be merged before migration. Others may need manual review because similar names or shared domains do not always represent the same customer.

Standardize values

Review dropdown values and naming conventions across teams. One region may use “Active Client” while another uses “Customer” for the same status.

If the business agrees that those values mean the same thing, map them to a consistent destination value. Keep a record of the transformation so reports can be reconciled later.

Prepare users and ownership

Map Dynamics 365 owners to the correct HubSpot users. Decide what happens to records owned by former employees, inactive accounts, or teams that no longer exist.

Do not assign every unmapped record to a single person without agreement. That can create a misleading workload and make follow-up difficult after launch.

Review dates, currencies, and calculated values

Confirm the format and meaning of important dates before conversion. A contract end date, an expected close date, and a renewal date serve different purposes even if they appear in similar formats.

For currency fields, preserve the currency context and agree on how values will be compared in reports. A converted value should not replace the original amount without a clear reason and documented rule.

For calculated or roll-up values, decide whether HubSpot will maintain an equivalent calculation, receive the value from another system, or retain a historical snapshot.

Validate Data Mapping After Migration

Validation should prove that the information is accurate and usable for the business.

Begin by comparing record counts for each entity in scope. Account for records intentionally excluded, merged, or archived so the difference between source and destination is understood.

Then check the quality of individual records and relationships.

Use a representative sample that includes difficult cases. Select accounts with subsidiaries, opportunities with multiple contacts, records owned by inactive users, and custom entities with several relationships.

Compare important business totals using the same definitions. If one report uses expected close date and another uses actual close date, differences may reflect the report design rather than a failed migration.

Activities deserve a separate test. HubSpot notes that existing emails, meetings, notes, and tasks cannot be updated through import, so the loading and correction approach for those records should be agreed before the final migration.

Document issues, assign owners, and repeat the relevant checks after corrections. Obtain approval from the teams responsible for the data before treating the migration as complete.

Common Dynamics 365 Data Mapping Challenges

Mapping fields by name alone

Fields with similar names can have different meanings. Review definitions and actual values with business owners before approving the mapping.

Losing account hierarchy

Parent companies, subsidiaries, locations, and billing entities can appear similar in an export. Decide which relationships need to remain visible and how users will distinguish them in HubSpot.

Combining leads and contacts without matching rules

The same person may appear in both entities with different owners or values. Define how records will be matched and which information takes priority.

Importing values without their context

A calculated amount or status may be correct on migration day but depend on automation that has not been rebuilt. Document how the value will be maintained after launch.

Overlooking historical reporting requirements

Current records may migrate successfully while historical stage changes or activity details require a different method or archive. Agree on the reports and history the business needs before selecting the migration approach.

Validating only the number of records

A matching count does not prove that deals have the correct owners or that contacts are associated with the right companies. Combine counts with field checks, relationship checks, business totals, and user testing.

Conclusion

A successful Dynamics 365 to HubSpot migration depends on decisions made before the import begins.

Map entities according to their business purpose, define how fields will be transformed, and preserve the relationships users need. Then validate the destination against the source and the tasks your teams perform every day.

OneMetric can help assess your Dynamics 365 data structure, design the HubSpot mapping, and plan a migration around the information your business needs to retain.