Migrating from Microsoft Dynamics to Salesforce: What Nobody Tells You

What the Sales Process Obscures

Every Salesforce AE who has sold a Dynamics displacement knows the pitch. The narrative is familiar: Salesforce is more innovative, more extensible, better supported by a global partner ecosystem, and — subtly implied — the choice that demonstrates CRM ambition rather than CRM adequacy. The sales process is professionally executed and commercially compelling. It is also, in important respects, a distortion of what the programme actually involves.

The distortion is not malicious. Salesforce AEs are not lying when they tell you the migration is achievable. It is achievable. Hundreds of organisations have done it. The problem is that the sales process is optimised to make the decision to proceed feel safe, and the delivery process then reveals the complexity that was either minimised or simply never raised. By that point, the contract is signed, the programme budget is approved, and the organisation is committed.

The first distortion is the data migration estimate. A Salesforce SI will typically scope data migration as a discrete workstream with a fixed cost. That estimate almost always underestimates the complexity of the actual data state in the Dynamics environment. Dynamics organisations accumulate years of customisation, data quality debt, decommissioned workflows that left orphaned records, and custom entities that have no direct Salesforce equivalent. The data migration is not a lift-and-shift. It is a transformation, and the cost of that transformation scales with the complexity of the source data — which is almost always worse than the initial assessment suggests.

The second distortion is process translation. The sales pitch implies that business processes running in Dynamics will be reproduced in Salesforce. That is rarely what actually happens — or rather, it is what happens when the programme is badly run. The correct approach is process re-engineering: using the migration as an opportunity to improve the processes, not replicate them. But process re-engineering is expensive, takes significantly longer than translation, and requires business ownership that many organisations cannot mobilise at the pace a CRM programme demands.

The third distortion is timeline. A competent Dynamics-to-Salesforce migration for a mid-sized enterprise — say, 500 sales users, moderate data complexity, standard integrations — will take 12 to 18 months to deliver a production-quality system. The sales process will often anchor on 9 months. The anchor is aspirational. The delivery reality is not.

The Data Migration Complexity

Dynamics 365 and Salesforce share a broad conceptual CRM data model — Accounts, Contacts, Opportunities, Activities — but the implementation differences at the field and relationship level create significant migration complexity. Understanding these differences before the programme starts is the difference between a manageable migration and a programme that loses control of scope in the data workstream.

The Entity Model Mismatch

Dynamics uses the concept of Business Units as the primary security and organisational hierarchy mechanism. Salesforce uses a combination of Role Hierarchy, Territory Management, and Sharing Rules. These two models are not equivalent. An organisation that has spent five years structuring its Dynamics security model around Business Units cannot translate that model directly into Salesforce. The migration team must map the intent of the security model — who should see what, under what conditions — and rebuild it using Salesforce constructs. This mapping exercise is almost always underestimated, particularly when Business Units have been used in Dynamics to manage regional or divisional data separation in ways that have no clean Salesforce equivalent.

The Activity data model presents a different problem. Dynamics stores Tasks, Phone Calls, Emails, and Appointments as separate entity types with separate schemas. Salesforce uses a unified Activity object with a Type field. The migration must not only move the records but resolve the schema differences, and in doing so must decide how historical activity data is presented in the target system. A phone call log in Dynamics becomes a Task record with Type = "Call" in Salesforce — but if the Dynamics Phone Call entity had custom fields that captured call outcome, call duration, or call direction, those fields may not have a direct target in Salesforce. Every custom field is a migration decision.

The Data Quality Reality

Most Dynamics environments that have been in production for more than three years carry significant data quality debt. Duplicate Account records — sometimes in the thousands — that accumulated when Dynamics deduplication was not enforced. Contact records that are not linked to Accounts, or are linked to archived Accounts that were never formally decommissioned. Opportunity records that were never closed because the team found it easier to create a new one than to update the old one. Custom lookup fields that point to records that were deleted without cascading the change.

The data quality assessment in the discovery phase must quantify this debt, because it determines the data migration timeline. Cleaning 50,000 Account records before migration is not the same programme as cleaning 500,000. The cleaning effort is linear but the complexity is not — data quality problems in Dynamics are often interdependent, and resolving one category of problem can expose another. Build the timeline from the data quality assessment findings, not from a standard template.

The Historical Data Decision

One of the most important programme decisions, and one of the least well-handled in most migrations, is how much historical data to migrate to the new Salesforce environment. The tempting answer is "all of it." The correct answer is almost never "all of it."

Historical data that pre-dates a reasonable retention window — typically three to five years for active CRM data — has limited operational value in the new system. Migrating it adds cost, extends the migration timeline, introduces more opportunity for data quality issues in the target environment, and increases the org's data storage costs in Salesforce. The right approach for most organisations is to migrate active data and recent historical data to Salesforce, and archive older historical data in a read-only reporting environment — either a data warehouse or a maintained Dynamics environment in read-only mode. This decision must be made early and must have business sign-off, because revisiting it mid-programme is expensive.

Process Re-Engineering, Not Process Translation

The distinction between process re-engineering and process translation is not semantic. It is the difference between a migration that improves the business and a migration that rebuilds the existing problems in a more expensive platform.

Process translation means: take the workflow that exists in Dynamics today and reproduce it in Salesforce. The Lead qualification process that uses three stages in Dynamics becomes a three-stage process in Salesforce. The Opportunity approval workflow that routes through four managers in Dynamics is rebuilt as a four-step approval process in Salesforce. The outcome of process translation is a system that does exactly what the old system did — with the same inefficiencies, the same workarounds, and the same data quality problems — but now running on Salesforce.

Process re-engineering means: using the migration as the forcing function to question every process. Why does the Lead qualification process have three stages? Are all three stages adding value, or have they accumulated over years of incremental addition? Does the Opportunity approval workflow actually enforce any risk controls, or has it become a rubber-stamp process that delays deals without adding oversight? These are the questions that process re-engineering asks — and answering them well requires business stakeholder time, process expertise, and the organisational courage to eliminate processes that people are attached to even when they no longer serve a purpose.

The Business Readiness Problem

Process re-engineering requires business engagement at a level that most organisations underestimate when they approve the programme. It requires sales leaders, operations managers, and process owners to attend workshops, review designs, make decisions, and approve changes — repeatedly, over the full duration of the programme. In most organisations, these are the busiest people, with day jobs that do not disappear because a CRM migration programme is running.

The failure mode is predictable: business engagement starts strong in the discovery and design phases, degrades during the build phase, and essentially collapses in the UAT phase when the business nominally "tests" the system but actually reviews it superficially and then raises a wave of change requests in the two weeks before go-live. Those change requests are not malicious — they reflect genuine feedback from the first time the business has seen a near-complete system. But they arrive too late to be absorbed without either delaying go-live or accepting a system that does not meet requirements.

The mitigation is structural. The programme plan must build in business engagement as a formal dependency — not a nice-to-have — with named individuals accountable for specific decisions at specific times. The programme director must have the authority to escalate when business engagement falls below the required level, because the alternative is a system that fails user acceptance.

The Dynamics-Specific Process Patterns to Question

Several process patterns that are common in mature Dynamics environments should be reviewed critically rather than migrated automatically. Business Unit-based security that enforces data separation between teams or regions deserves particular scrutiny: in many cases, the separation was implemented for technical reasons in the early Dynamics deployment and is no longer operationally necessary. Migrating it to Salesforce Sharing Rules adds complexity with no business benefit.

Custom entity usage is another area for review. Dynamics environments frequently accumulate custom entities that were created to solve specific problems — sometimes several custom entities that solve the same problem slightly differently, built by different teams at different times. Each custom entity is a migration candidate. Not all of them should be migrated. A review of custom entity usage data — which entities are being actively used, by how many users, at what frequency — will typically reveal that 30 to 40 percent of custom entities have very low usage and are candidates for consolidation or retirement.

The User Adoption Problem

The most technically competent Dynamics-to-Salesforce migration in history will fail if users do not adopt the new system. Adoption failure is the single most common reason CRM migrations do not deliver the business case — and it is far more common in migrations than in greenfield CRM implementations, because migration users have a working alternative system to revert to.

The Dynamics User Profile

Dynamics users in large organisations are frequently characterised by deep familiarity with a specific workflow in a specific interface, and low enthusiasm for changing either. The Dynamics interface — particularly for organisations running the older Dynamics CRM or early Dynamics 365 versions — has a desktop application feel that many users are very comfortable with. Salesforce's interface is different in character: more web-native, more configurable, more reliant on the administrator having correctly configured the page layouts and record types for the specific workflow. A Salesforce environment that has been carefully configured for the user's workflow can be highly efficient. One that has been configured generically, or configured by a technical team that did not deeply understand the sales process, can feel significantly less efficient than the Dynamics system it replaced.

The adoption risk from this profile is that users find Salesforce harder to use in the first months, revert to workarounds — maintaining their own spreadsheets, logging activity in Dynamics if it remains accessible, or simply not logging activity at all — and the business case for the migration fails on CRM adoption metrics. That failure is recoverable, but recovering it requires significant investment in retraining, process adjustment, and sometimes system reconfiguration that was not budgeted.

The Parallel Running Decision

One of the most consequential decisions in a Dynamics-to-Salesforce migration is whether to run both systems in parallel during the transition period. Parallel running — maintaining a live Dynamics environment while Salesforce is being adopted — reduces the risk of a failed go-live but introduces a different risk: users maintaining records in Dynamics rather than adopting Salesforce.

The organisations that have managed this best have done two things. First, they have established a clear, public, immovable decommission date for Dynamics from the moment of go-live. Not "we will decommission Dynamics when we are comfortable" — that date never arrives. A specific date, communicated widely, makes the migration to Salesforce the path of least resistance. Second, they have made specific, high-visibility workflows Salesforce-only from day one of go-live — pipeline reporting for the executive team, deal approval workflows, forecast submissions. When the workflows that leaders care about live only in Salesforce, adoption follows.

Training That Works for Dynamics Users

Standard Salesforce onboarding training is designed for users who have not previously used a CRM. It explains concepts — pipelines, stages, activities, contacts — that Dynamics users already understand. Using standard onboarding training for a Dynamics migration is a waste of time that leaves users less prepared than if the training had been role-specific and focused on the specific workflows they will use in Salesforce.

The training that works for Dynamics migrations is comparative and workflow-specific. It explicitly acknowledges what the user already knows from Dynamics, explains how the equivalent in Salesforce is structured differently, and demonstrates the specific daily workflows — not generic Salesforce capabilities — that the user will perform. It is significantly more expensive to design than standard training, requires process knowledge that most training vendors do not have, and must be built after the system is configured, not before. Organisations that build this training — and that invest in a network of trained "champions" who can provide peer support during the adoption period — achieve measurably better adoption outcomes.

Realistic Timeline and Risk Planning

The final capability a programme director needs for a Dynamics-to-Salesforce migration is a realistic view of timeline and a structured approach to risk. Both are frequently absent from the initial programme plan, and both are essential to delivering a programme that the organisation retains confidence in.

The Phases That Actually Take the Most Time

Data migration takes longer than almost every initial estimate suggests. The typical pattern: initial estimate of eight weeks, actual delivery of sixteen to twenty weeks, driven by data quality findings that were not fully understood at estimation time. The mitigation is to start the data migration workstream in parallel with the design and build phases, not sequentially after them. An organisation that begins data profiling, data cleansing, and transformation rule development at the start of the programme — rather than waiting until the Salesforce environment is built — will consistently hit a more predictable go-live date.

User Acceptance Testing takes longer than planned because business stakeholders are not available at the intensity the testing phase requires, and because UAT in a migration programme reveals requirements that were not captured in the design phase. Budget two rounds of UAT for a migration of any complexity. Plan for at least four weeks of UAT per round. Treat the first round as a findings exercise, not a sign-off exercise — it will be.

Integration build and testing takes longer than planned because Dynamics-connected integrations are almost never documented to the level of detail that Salesforce integration architects need. Integration endpoints change during the programme. Authentication models differ between Dynamics and Salesforce in ways that require rework on the upstream system side. Buffer the integration workstream with 50% contingency from the outset.

The Commercial Negotiation That Determines Value

The commercial structure of a Dynamics-to-Salesforce migration has several negotiation levers that organisations frequently do not use effectively. On the Salesforce licence side, the period between contract signature and go-live is dead licence cost — you are paying for licences that are not yet live. Negotiating a delayed licence start date, or a phased licence ramp that matches the go-live schedule, can save six to twelve months of licence cost on a programme of typical length.

On the SI side, the most important commercial principle is to avoid fixed-price contracts for data migration and integration workstreams. Both workstreams have cost drivers — data quality, integration complexity — that are not knowable at the time of contract. Fixed-price contracts for unknowable work either produce an inflated fixed price (the SI's risk premium) or a change control war when the unknowable complexity materialises. Time-and-materials with a defined governance framework for scope control is the more honest commercial model for these workstreams.

The Dynamics decommission cost is a frequently overlooked item. Microsoft licences do not end at go-live date. If the organisation is mid-contract on a Dynamics Enterprise Agreement, breaking that contract or maintaining it for its remaining term has a real cost that must be in the migration TCO. Organisations that plan for Salesforce cost without modelling the Dynamics exit cost underestimate the total investment in the migration by a material amount.