Company identity
Usually comes from the account.
Executive summary
The smallest reliable data model, not the most complete copy
A Microsoft Dynamics to HubSpot migration is rarely blocked by the CSV import. It's blocked by contracts, licenses, recurring revenue and years of process history that don't map cleanly onto HubSpot's data model.
Core thesis
A successful migration is not achieved by recreating every Dynamics object, field and historical process. It's achieved by classifying data into what's operational, reportable, historical, or legal — then designing the HubSpot operating model first and mapping Dynamics data into it second.
| Design decision | Recommended principle |
|---|---|
| Sequencing | Document the future HubSpot process before mapping a single Dynamics field. |
| Data depth | Classify data as operational, reporting, historical, or legal before deciding how to migrate it. |
| Contracts | Choose deliberately between deal, custom object, or external document — never by default. |
| Associations | Attach a stable legacy ID to every migrated object; never rely on names alone. |
| Validation | Prove the migration with real business cases, not matching record counts. |
Framework in one sentence
Migrate what daily work, reporting and legal compliance genuinely require; keep everything else as reference, not as a rebuilt native record.
01 · Process before objects
Start with the future process, not the legacy objects
Copying Dynamics objects first reproduces the old complexity. Documenting the future HubSpot process first gives the migration something real to map data into.
When does a contact become a lead?
When does a lead become a deal?
Which pipeline owns legacy contracts?
How are renewals managed?
Which object owns revenue?
Who needs access to what?
Recommended principle
Design the HubSpot operating model first. Map Dynamics data into it second — not the other way round.
02 · Inventory the Dynamics data model
Find out which object is actually the source of truth
Dynamics environments frequently contain overlapping or manually maintained objects. Recurring-revenue information is rarely stored in one clean place — it's distributed across opportunities, contracts, orders and license records.
Commercial context
Lives on the opportunity — what was sold, when, to whom.
Contract duration
Comes from the contract object, not the deal.
Current recurring price
Sits on the license record, often maintained by hand.
Legal documentation
Frequently stays in SharePoint or as an attached PDF.
The real question
Which object wins when two sources disagree?
03 · Classify data before mapping it
Four categories decide migration depth
Not every piece of Dynamics data deserves the same migration effort. Classifying data first prevents both under-migrating what sales needs daily and over-migrating what nobody will ever query.
| Category | Typical contents |
|---|---|
| Operational | Active companies, contacts, open leads, open deals, active contracts, current licenses, next billing/renewal dates |
| Reporting | Close date, deal amount, ARR, product category, pipeline stage, source, owner, conversion dates |
| Historical reference | Old offers, legacy invoices, historical price changes, expired licenses, manually adjusted discounts |
| Legal / archive | Signed contracts, order confirmations, PDFs, SharePoint links, legal appendices |
Rule of thumb
Historical reference data deserves context, not necessarily a native HubSpot record. Rebuild it only where a defined reporting requirement calls for it.
04 · Map standard CRM objects carefully
Most objects translate directly — contracts don't
Account to company, contact to contact, opportunity to deal: straightforward. Contracts and licenses need a deliberate decision, because HubSpot's own contract functionality is built around HubSpot-generated quotes and line items.
| Microsoft Dynamics | HubSpot |
|---|---|
| Account | Company |
| Contact | Contact |
| Lead | Lead |
| Opportunity | Deal |
| Product | Product library |
| Opportunity Product | Line item |
| Contract | Deal, custom object, or external document reference |
| License | Recurring line item or custom object |
| Activity | Activity, note, or external archive |
| Attachment | File attachment or SharePoint link |
Not always one-to-one
HubSpot's native Contracts object can import existing contracts using a custom identifier, but it requires Revenue Hub Professional or Enterprise and stays built around HubSpot quotes and deal associations — not a like-for-like copy of Dynamics history.
05 · Use unique legacy IDs for associations
Never associate records by name alone
Every imported object should retain its original Dynamics identifier. Names repeat, get misspelled, or shift slightly between exports — a stable ID doesn't.
Microsoft Dynamics Company ID
Microsoft Dynamics Contact ID
Microsoft Dynamics Deal ID
Microsoft Dynamics Contract ID
Microsoft Dynamics License ID
Microsoft Dynamics Parent Contract ID
What this buys you
Reliable association between contacts and companies, licenses linked back to their original deal, safe re-updates without duplicates, and a way to troubleshoot failed imports against the Dynamics export.
06 · Decide how to represent legacy contracts
Three models, three different trade-offs
None of the three options is universally correct. The right choice follows what the business actually needs from contract data — not the theoretical ideal.
Contract as deal
Best for renewal management, billing reminders, operational ownership.
Limitation: represents the active contract, not necessarily the original historical sale.
Custom contract object
Best for multiple contracts per deal, complex metadata, independent reporting.
Limitation: higher implementation effort and training.
External document + metadata
Best when SharePoint stays the legal archive and full reconstruction has no payoff.
Limitation: no native contract reporting in HubSpot.
Useful fields for option C
Contract URL, contract start date, contract end date, auto-renewal, notice period, current annual value, next billing date.
07 · Model recurring licenses as line items
One deal, one line item per license component
One active contract or renewal case becomes one HubSpot deal. Every recurring license component becomes one associated line item, prioritising current prices over full historical reconstruction.
Design principle
Product definitions belong in the product library. Customer-specific commercial values belong on the line item.
Name, SKU, description
Product type, module
Quantity, unit price, billing frequency
Billing start, term, contract end
Currency, discount, category
Legacy product ID, parent deal ID
08 · Do not rebuild every historical price change
Migrate the current price, archive the rest
A legacy contract can carry years of price increases, discounts and rounding adjustments. Rebuilding every period as its own line item is possible — it also produces hundreds of records nobody reports on.
The trade-off
Migrate the current active price. Keep the signed contract or pricing history as a document. Create additional historical records only where a defined reporting requirement calls for them.
09 · Define the source of truth for deal amount and ARR
Six numbers that are not interchangeable
Total contract value, ARR, invoice amount, recognized revenue, one-time revenue and current recurring value can each be calculated differently depending on billing frequency, term and line-item configuration.
Current ARR
One-time revenue
Total contract value
ARR start / end date
Next billing date
Revenue source
ARR reporting category
Booked vs. recognized
A deal can be booked in full on day one while accounting recognizes the same revenue in monthly slices across the term. Treating deal-close reporting as recognized revenue is a common source of finance-and-sales friction after migration.
10 · Be transparent about reporting limitations
HubSpot is strong at pipeline reporting, not fiscal-period accounting
HubSpot handles pipeline reporting, deal-based revenue, product analysis, forecasting and current recurring value well. Recognized-revenue reporting across financial periods usually needs help from outside the CRM.
| Requirement | Typical answer |
|---|---|
| Current recurring value, pipeline, forecast | Native HubSpot deal and line-item reporting |
| Recurring revenue properties at scale | Sales Hub Enterprise recurring revenue tooling |
| Custom recognition logic | Data Hub with custom code |
| Cross-period fiscal splits | Excel, Google Sheets, a BI platform, or ERP integration |
Example
A twelve-month invoice starting in July often needs to be split across two fiscal years for financial reporting — a different logic from deal or invoice reporting.
11 · Import in controlled phases
A fixed sequence prevents missing associations
Associations, products and deals import in an order that avoids duplicates and orphaned records — not in whatever order the source files happen to export.
Clean & standardizeSource data prepared before anything else moves.
Create propertiesRequired HubSpot fields exist before the first import.
Companies, contacts, associationsCore relationships established first.
Products, deals, line itemsCommercial structure imported and linked.
Notes, validation, trainingDocumentation, testing and enablement close the loop.
12 · Validate with business cases, not just record counts
A matching count proves nothing about whether it works
Representative scenarios reveal what a record count can't: one company with one license, a contract with multiple modules, an auto-renewal case, a fixed-term contract, a deal mixing recurring and one-time components.
Can the user identify the current recurring amount, prepare the next invoice, and see the renewal date? Can the contract document be opened, the correct company confirmed, and every current license seen in one place? Can management report on ARR and pipeline — and can the record be updated without opening Dynamics?
13 · Governance after migration
The migration is the start of data discipline, not the end
Mandatory fields per pipeline stage, controlled product names, documented properties and clear ownership are what stop the old complexity from quietly returning.
Prevent duplication
Controlled product names and SKUs, one property catalogue.
Assign ownership
Every object and custom property has a named owner.
Audit before retiring
Review imports before the legacy system is switched off.
Non-negotiable rules
Define mandatory properties by pipeline stage. Separate current values from historical values consistently. Create saved views for missing data instead of guessing.
14 · Migration readiness checklist
Is the migration actually ready to start?
Score each statement: 2 = complete, 1 = partly complete, 0 = not started. The result updates instantly.
01
The future HubSpot process is documented before any Dynamics field is mapped.
02
Every Dynamics object's source-of-truth question is answered, not assumed.
03
Data is classified as operational, reporting, historical, or legal.
04
Standard object mapping (account, contact, opportunity, product) is documented.
05
Legacy-ID properties exist for every object type that will be migrated.
06
The contract model (deal, custom object, or external) is chosen and justified.
07
Recurring licenses are mapped to line items with a clear product library.
08
The team has agreed not to rebuild every historical price change.
09
ARR, TCV and one-time revenue have agreed, governed property definitions.
10
Finance and sales agree on which reporting HubSpot owns and which stays external.
11
A phased import sequence and rollback plan are documented.
12
Post-migration governance rules (ownership, naming, audits) are assigned to named people.
0 / 24
Align the operating model first
A score of 0–13 indicates the target process and data classification should be settled before any import runs.
Conclusion
The goal is the smallest reliable data model, not the most complete copy
A migration from Microsoft Dynamics to HubSpot should leave the business with a cleaner system than the one it replaces — not a faithful reproduction of every workaround the old CRM ever accumulated.
Process first
The future HubSpot operating model is designed before Dynamics data is mapped into it.
Classify, then migrate
Operational, reporting, historical and legal data each get a different level of effort.
Govern after go-live
Ownership, naming and audits are what keep the new system from drifting back into the old one.
Final takeaway
The best result is not the most complete copy of the old CRM. It's the smallest reliable data model that supports sales, renewals, invoicing, reporting and future growth.
