Migrating from Salesforce to Dynamics 365: what the proposal doesn’t show
Jacek Szafader September 29, 2026 You're reading:
- Anatomy of a typical case
- The historical challenge: technical debt with no owner
- The technical challenge: data is only one workstream
- The business challenge: CRM as a source for financial forecasting
- Practical implications
- The deadline challenge: why “lift and shift” can be an illusion
- The archive: exporting is only the beginning
- 10 questions to ask before choosing a migration partner
- The key takeaway
Migrations from Salesforce to Microsoft Dynamics 365 are increasingly driven by cost pressures, the need to work within the Microsoft 365 ecosystem, and a desire to connect CRM with the tools sales teams use every day. Deciding to switch platforms, however, is easier than making the switch.
Below, we explore the real challenges through an anonymised scenario: an international services company with around 100 Salesforce licences, approximately 100 active users, and an environment developed over ten years. The figures and issues are genuine, but they do not identify a specific client.
Anatomy of a typical case
The starting point looks straightforward. That is precisely why these projects are often underestimated.
Dimension | Current state | Why it matters |
|---|---|---|
Age of the implementation | Approx. 10 years | The configuration embeds past processes and decisions. |
Licences | Approx. 100 active users | A small user base does not mean low complexity. |
Scope | Business Development / Sales | Other teams work outside the CRM or rely on manual processes. |
Core data | Accounts, Contacts, Opportunities, Activities | The core is simple; complexity usually lies in the configuration and exceptions. |
Fields | Many unused | You need to distinguish genuine requirements from legacy remnants. |
Automations | Incomplete knowledge of their number and usage | This is one of the biggest unknowns when estimating costs. |
Expertise | No in-house Salesforce expert | Institutional knowledge is missing: “Why was this built?” |
Ownership | One person responsible for both business and technical matters | A decision-making bottleneck and a continuity risk. |
Integrations | Formally out of scope | APIs, Connected Apps, SSO, email and exports still need to be checked. |
Critical dependency | Financial forecasting based on Opportunity data | The CRM is a critical source system for budgeting. |
Deadline | Fixed; no extended period of running both systems in parallel | Cutover and contingency planning become part of the core scope. |
The historical challenge: technical debt with no owner
An eight-year-old Salesforce implementation contains layers of decisions made by people who often no longer work at the company. Fields added for a single campaign. Notifications sent to inactive mailboxes. Validation rules protecting a process that changed long ago.
There is also a change on the vendor’s side: Salesforce ended support for Workflow Rules and Process Builder on 31 December 2025. Existing automations may continue to run, but these are legacy tools that the vendor no longer supports, with a recommendation to move to Flow Builder. Source: Salesforce Help
What to do before estimating costs
- Build an inventory of automations together: the partner extracts and analyses the configuration, while business owners confirm its role in the process.
- For each item, document the object, trigger, conditions, actions, dependencies, business owner and last confirmed use.
- Treat automations that have not run for a long time as candidates for retirement — but only after confirming this with the process owner and checking dependencies.
- Do not copy technical debt like for like. Each item should receive a decision: recreate, simplify, replace with standard functionality, or retire.
Warning: Building an inventory of automations and dependencies may take longer than technically transferring the core records. A proposal prepared without this knowledge is a budget scenario, not a full cost estimate.
The technical challenge: data is only one workstream
A common assumption is: “We have four main objects and a few tens of thousands of records, so the migration will be straightforward.” Transferring core records can indeed be more predictable than reconstructing the configuration and logic. That does not make it low-risk.
- Relationships between records, customer hierarchies and source identifiers must remain consistent.
- Record ownership and data visibility depend on the target security model.
- Activities, emails, notes and files require their own mapping model and tests.
- Change history and audit records are not ordinary business fields.
- Every migration run requires reconciliation: checking record counts, errors, relationships and key business totals.
Record Types have no single equivalent
Salesforce and Dynamics 365 serve similar CRM purposes, but differ in how they implement data models, security, processes and automation. Salesforce Record Types are a good example. They can affect page layouts, available picklist values and process flows, among other things. In Dynamics 365 and Dataverse, there is no single mechanism that should always be used in their place.
Depending on the case, the purpose of a Record Type is reproduced through a combination of forms, security roles, Choice columns, Business Process Flows, business rules, Power Automate, and sometimes a different model of tables and relationships. That is why field-to-field mapping is not enough. You need to map the business purpose behind the configuration.
Lower volumes help, but do not shorten everything
Limiting the migration to active data and the history required by finance reduces extraction, loading, cleansing and reconciliation time, as well as the number of exceptions. It does not, however, shorten the entire implementation proportionally. The target system still needs a data model, forms, security, automation, reporting, testing and launch preparation.Tools speed up the mechanics, not the decisions
Microsoft tools and partner accelerators are available to support metadata analysis, mapping and data transfer from Salesforce to Dataverse. They can reduce manual work and make successive migration runs more repeatable. Their availability and scope must, however, be confirmed for the specific project.Principle: No accelerator can decide whether an old automation still makes sense, who should be able to see a record, or how forecasting should work. Tools support migration; they do not replace process analysis and architecture.
The business challenge: CRM as a source for financial forecasting
The most important risk often only emerges during a discussion about reports. In this scenario, Opportunity values — expected revenue spread across years — are exported regularly and used by finance for budgeting. The CRM is not a financial accounting system, but it is a critical source system for forecasting.
Practical implications
- The minimum data scope for launch is defined not only by sales, but also by finance: periods, currencies, statuses, dates and how revenue is allocated over time.
- Reporting continuity is a go-live criterion, not something to refine during hypercare.
- Salesforce report definitions have no native one-to-one conversion to Dynamics. Their logic, filters, permissions and presentation must be recreated in Dynamics 365 or Power BI.
- Reconciliation should cover not only the number of Opportunities, but also expected revenue totals by year, currency, stage, owner and organisational unit.
Example go/no-go gate: Key financial reports in the target system must produce reconciled results for the same frozen dataset used by the source reports. Acceptable differences should be explicitly documented and approved.
Security and ownership do not map automatically
Salesforce Profiles, Permission Sets and sharing mechanisms do not translate directly into Dataverse security roles, business units, teams, ownership and column-level security. The target access model must be designed and then tested against real user personas: a salesperson, a manager, a finance user, an administrator, and a user with access restricted to a specific scope.The single-owner trap
If the same person is responsible for business requirements, technical matters, data cleansing, UAT and adoption, they become a single point of failure. Before launch, identify a sponsor, process owners and at least one person to support technical and operational decisions. The lack of an in-house administrator should be reflected in the post-launch service model.Practical implications
1. Data quality, duplicates and exceptions
2. Activities, emails and files
3. Integrations hidden outside the formal scope
The deadline challenge: why “lift and shift” can be an illusion
When the Salesforce agreement is expiring and running two platforms in parallel is too expensive, “lift and shift” is a natural idea: move the current setup without improvements. With an older implementation, however, this approach has a limitation — you cannot faithfully recreate a configuration whose purpose the organisation can no longer explain.
A phased approach under a tight deadline
Workstream | Scope | Success condition |
|---|---|---|
Phase 1 — the minimum needed for launch | Accounts, Contacts, Opportunities and essential Activities; a simple sales process; active data and the history required by finance; key reports; security; training and hypercare. | Scope frozen early; measurable go/no-go criteria. |
Phase 2 — after stabilisation | Remaining history, additional process types, selected automations, additional reports and expansion into account management. | A roadmap and decisions to “recreate / simplify / retire”. |
Archive — in parallel | A complete, verified export of the data, files, metadata and history available in the source environment. | The archive must be readable and searchable, not merely saved. |
Cutover is a project deliverable in its own right
With a fixed migration date, the cutover plan cannot be a single task in the schedule. It should include, at a minimum:- a mock cutover and confirmation of the actual time needed for extraction, transformation, loading and validation;
- a freeze on changes and data in Salesforce, with rules for handling exceptions;
- a final delta and a clearly defined cutoff time;
- owners for each step, a command channel and go/no-go criteria;
- a rollback plan or a controlled contingency scenario if a full return to Salesforce will not be possible;
- user communications and hypercare readiness from the first hour of operation.
Warning: If the proposal does not cover cutover, reconciliation and responsibility for the go/no-go decision, the risk has not disappeared. It has simply been transferred to the client.
The archive: exporting is only the beginning
A full Salesforce export should be completed and verified before the environment is shut down. Operational access may end once the subscription expires, and the ability to recover data later depends on the agreement terms and applicable procedures. That is why you should not build your plan around the assumption that “we can always go back to Salesforce if needed”.
What a complete archive should include
- Data with its original identifiers, relationships, hierarchies and value dictionaries.
- Users, owners and the information needed to interpret ownership.
- Salesforce Files, Content Versions, Attachments and Documents — together with their links to records.
- A separate snapshot of metadata and configuration: fields, objects, layouts, Record Types, automations, validations, Apex, permission sets and reports.
- Available change history and audit records, taking actual retention periods and existing licences into account.
- An export manifest, record counts per object, an error list, file checksums and a reconciliation report.
- A practical way to access the information: a data catalogue, relationship descriptions and an agreed method for finding information after the CRM has been shut down.
Important: A collection of CSV files and an attachments folder in a Data Lake is a technical copy. It only becomes a business archive when the organisation can find a record, reconstruct its relationships and open the associated document.
The adoption challenge: changing habits, not icons
Users who have worked in the same CRM for years have established habits. Changing platforms means changing how they work: where they save a note, how they qualify an Opportunity, which data is mandatory, and where they look for customer history. Working within the Microsoft ecosystem can lower the barrier to adoption because users remain close to Outlook and Teams. However, specific Copilot features or integration capabilities should not be promised without checking the configuration. Feature availability depends on the selected Dynamics 365 and Microsoft 365 plans, administrator configuration, Dataverse capacity, and any Power BI, Power Automate and Copilot licences.The minimum adoption plan
- Training based on real work scenarios, completed before the production launch.
- Super-users who take part in testing and support the team after launch.
- Hypercare with a defined scope, availability hours, priorities and duration.
- A support model for after hypercare, particularly when the client has no in-house administrator.
- A fusion team: client staff work alongside the partner so that expertise stays within the organisation.
10 questions to ask before choosing a migration partner
1. How will the partner inventory automations, Record Types, validations, reports, permissions and dependencies, and how will responsibilities be shared with business owners?
2. Which elements will be recreated, simplified, replaced with standard functionality or retired — and who will approve those decisions?
3. How will the security model, ownership and data access be mapped between Salesforce and Dataverse?
4. Which data quality, deduplication and survivorship rules will be applied to Accounts, Contacts and other data?
5. How will the partner handle Activities, emails, notes and files, and how will they verify that all relationships are intact?
6. What are the measurable acceptance and go/no-go criteria — including reconciliation of records, relationships, files and financial forecasting totals?
7. What is the detailed cutover plan: mock cutover, freeze, final delta, downtime window, owners for each step, and a rollback or contingency scenario?
8. What exactly does the archive include: data, files, metadata, history/audit records, a manifest, completeness checks and a way to access the information later?
9. Which reports must work on launch day, and how will their logic, filters, permissions and presentation be recreated in Dynamics 365 or Power BI?
10. What licences and capacity are required for each user persona, and which Dynamics 365, Outlook, Teams, Power BI, Power Automate and Copilot features are included, cost extra or have limitations?
The key takeaway
Migrating from Salesforce to Dynamics 365 is not difficult because records are hard to copy. It is difficult because, over the years, the CRM configuration has become an informal record of the company’s processes, exceptions, responsibilities and reporting practices.
The safest projects do not try to move everything without questioning it. They first establish what must work on launch day, how consistency of results will be verified, and where the remaining history will be stored safely. Only then do they choose the tools and migration sequence.
One sentence to remember: With a hard deadline, reduce the functional scope, but do not reduce the controls: security, testing, reconciliation, cutover and archiving.