Dynamics 365 to HubSpot migration.
Off the tenant, onto a system people open. Dynamics migrations are rarely about features. They are about a CRM the sales team stopped using because it takes four clicks to log a call. The technical work is the security model, the solution layers and whatever Power Automate is quietly holding together.
Licensed for everyone. Used by nobody.
Dynamics is capable and it is configured by people who are good at Dynamics. The gap between what the system can do and what a salesperson does at 5pm on a Thursday is where the data quality goes, and no amount of additional configuration closes it.
Four clicks to log a call.
Dynamics — the adoption gapWhat the Microsoft estate was doing for you.
Business units and security roles
Dynamics models access with business units, teams and role-based privileges at field level. HubSpot permissions are flatter. Collapsing the model means deciding what visibility actually needs enforcing rather than reproducing the org chart.
Solution layers hide configuration
Managed and unmanaged solutions stack, so what a user sees is the sum of several layers. Reading the effective configuration rather than the last solution imported is the only reliable way to inventory it.
Power Automate and plugins
Flows and registered plugins carry business rules that never appear in an export. They get inventoried and either rebuilt as HubSpot workflows or kept in Power Automate pointed at the new endpoints.
Dual-write and the Dataverse
If Dynamics is dual-writing to finance and operations, the CRM is not a standalone system. That boundary has to be redrawn explicitly, and it is usually the thing that sets the project timeline.
Activity parties
Dynamics models an activity as having many parties with roles. HubSpot associates engagements more simply, so multi-party meetings and emails need a mapping decision rather than a direct copy.
Identity and SSO
Users authenticate through Entra ID and expect to keep doing so. HubSpot SSO gets configured against the same directory so the migration does not become a password reset exercise.
The sequence, start to cutover.
Discovery
Object counts, custom fields, automation and the integrations that will break on the way out, read from the source system rather than from a questionnaire.
Mapping
Field by field, including what will not carry across, agreed and signed before anyone exports anything.
Dry run
A complete rehearsal into a sandbox portal, reconciled against source counts so the gaps surface a month early rather than on cutover night.
Automation rebuild
Workflows, sequences and routing rebuilt to the new model rather than transliterated from the old one, which is how a migration inherits a decade of workarounds nobody remembers writing.
Cutover
A dated switch with the legacy system read-only for a defined window, and a rollback that was tested rather than assumed.
Post-migration support
A named engineer through the first full reporting cycle, which is when the questions actually arrive.
The new system inherits the old permissions.
Teams ask for the Dynamics security model to be reproduced, and it cannot be, and the attempt produces a permission scheme nobody can administer. The better question is which records genuinely must be invisible to which people. The answer is almost always shorter than the role matrix.
What people ask before they commit.
Can we keep using the rest of the Microsoft stack?
Yes, and most teams do. Outlook, Teams, SharePoint and Entra ID all integrate. What changes is that the CRM stops being a Dataverse app, so the boundary with finance and operations has to be made explicit.
How long does a Dynamics migration take?
Eight to sixteen weeks. The security model and the Power Automate inventory drive the timeline far more than record volume does.
What happens to our Power BI reports?
They get repointed. HubSpot data reaches Power BI through the API or, better for anything at scale, through the warehouse. We usually take the opportunity to move reporting onto a modelled layer rather than querying the CRM directly.
Will adoption actually improve?
Only if the implementation is built around what reps do rather than what the business wants to capture. We cut required fields to the ones that drive a decision, and that is the change that moves adoption, not the platform.
Can we migrate one business unit at a time?
Yes, and for a large estate it is usually right. One region or division moves first, runs for a quarter, and the rest follows the pattern that worked.
Where people go from here.
A CRM the team actually opens.
Tell us what you are running
What the system does today, where it breaks, and when it has to work. An engineer reads it — you get an answer inside one business day, not a sequence.