Dynamics 365 to Salesforce FSC migration requires translating flat CRM entities into FSC's Person Account/Household hierarchy — get the data model mapping right or your relationship data breaks silently.
Migrating from Microsoft Dynamics 365 Sales to Salesforce Financial Services Cloud (FSC) is fundamentally a schema-translation problem with no native migration path between the two platforms. Dynamics 365 Sales operates on Microsoft Dataverse using a flexible entity-relationship model with standard CRM objects, while FSC layers financial-services-specific objects — including Person Accounts, Household Accounts, FinancialAccount, and AccountContactRelation junction objects — on top of the Salesforce platform. The most critical architectural decision is whether to enable Person Accounts in FSC, an irreversible org-level change that transforms how Dynamics 365 Contacts are represented and linked to Household structures. Custom ETL work is required to build ID crosswalk tables, construct household groupings from Dynamics data that has no native household concept, and remap all polymorphic lookups, option sets, and owner references to their Salesforce equivalents.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
If your Salesforce org has other active integrations using Bulk API, coordinate before
If your Salesforce org has other active integrations using Bulk API, coordinate before running large migration jobs. Bulk API 2.0 concurrent job limits (25 max) are org-wide. Running a marketing automation sync alongside a migration can cause job queue failures on both sides.
Disable Salesforce triggers, workflow rules, process builders, and FSC-specific
Disable Salesforce triggers, workflow rules, process builders, and FSC-specific validation rules before running migration loads. FSC's managed package includes triggers on Account, Contact, and ACR objects that will fire on every insert. At scale, this causes Apex CPU time limit exceptions and generates thousands of automated notifications. Re-enable and test after validation.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Agree scope, pipeline design and success criteria before touching data.
Objective A scope covering every object in the revenue model, with sales leadership signed up to the pipeline design.
Keep these open
-
Inventory every object in Dynamics 365 Sales
Count accounts, contacts, leads, deals or opportunities, activities, notes, emails, files, products and quotes. Activity and email history is usually the largest object by an order of magnitude and the one people forget to size.
Data Profiler Get real record counts instead of estimating from memory -
Map the current pipeline and agree the target model
Document every pipeline, stage, probability and required field, then agree the Salesforce model with sales leadership. Migrating a broken pipeline faithfully is a wasted opportunity; redesigning it mid-migration is a wasted migration.
Stage changes alter historical conversion rates. Agree how you will restate reporting before you change the model.
-
Catalogue integrations and automation
List every system touching Dynamics 365 Sales: marketing automation, quoting, billing, ERP, data enrichment, dialler, BI. Each is a separate cutover task with its own owner, and each can silently write bad data into your new CRM.
-
Capture the reporting that must survive
Interview the people who actually live in the dashboards — forecast, pipeline coverage, rep activity, cohort conversion. Every one of these needs the underlying fields to migrate, which frequently expands the scope.
-
Build the business case and pick the go-live date
Model licence delta, implementation effort and productivity dip. Then choose the date deliberately: mid-quarter is disruptive, quarter-end is worse. Most teams land on the first week of a new quarter.
COI & ROI Calculator Build the 36-month business case you will need for sign-off
Don't move on until
- Object counts confirmed for accounts, contacts, deals and activities
- Target pipeline and stage model agreed with sales leadership
- Reporting requirements captured from the people who use the reports
02 Data Audit CRM data is usually dirtier than anyone expects. Find out how dirty.
Objective A profiled export with duplicates, ownership gaps and relationship integrity all quantified and triaged.
Keep these open
-
Export and profile every object
Profile null rates, distinct values and type consistency across all objects. Pay attention to fields sales reps were supposed to fill in: an 80% null rate on a field your forecast depends on is a business finding, not a data one.
Data Profiler Profile the Dynamics 365 Sales export for nulls, outliers and type drift -
Quantify duplicates and agree the merge policy
Measure duplicate accounts (same company, different spellings and suffixes) and contacts (same email, or same person at a renamed company). Agree survivorship rules before merging: which record wins, which fields, and what happens to the activity history on the loser.
Merging before you have agreed survivorship rules destroys history irreversibly. Decide first, merge second.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Verify relationship integrity
Check every deal has a valid account, every contact a valid account, every activity a valid parent. Referential breaks are the defect that turns a clean-looking load into a CRM where the pipeline report does not tie to the account list.
-
Resolve ownership and the user map
Build the Dynamics 365 Sales user → Salesforce user map, including leavers. Every record needs a valid owner: records assigned to deactivated users either fail to load or land unassigned, and unassigned pipeline is pipeline nobody works.
Records owned by deactivated users are a top cause of load failures. Decide the reassignment target before you start.
-
Scan for PII and regional compliance
CRMs hold marketing consent, lawful basis and unsubscribe state. Confirm these fields migrate intact and that consent provenance survives — losing consent records is a regulatory problem, not a data-quality one.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Clean, normalise and archive the pre-state
Normalise country and state values, phone formats, currencies and casing, and standardise all timestamps to UTC. Keep an untouched copy of the raw export — it is your only reference if a mapping decision turns out wrong.
Dynamics 365 Sales → Salesforce specifics
- Accounts
- Count active vs. inactive. Identify parent-child hierarchies.
- Contacts
- Count total. Identify contacts without associated accounts (orphans). Flag contacts that should become Person Accounts vs. business contacts.
- Opportunities
- Map pipeline stages to FSC Opportunity stages. Count by status (Open, Won, Lost).
- Activities
- Total Tasks, Emails, Phone Calls, Appointments. Decide historical cutoff (e.g., last 2 years only).
- Custom Entities
- List all custom entities. Determine FSC target: FSC standard object, custom Salesforce object, or exclude.
Don't move on until
- Duplicate rate quantified per object with a merge policy agreed
- Every record has a valid owner mapped to a target user
- Relationship integrity verified — no orphaned deals or contacts
03 Field Mapping Map objects, relationships and picklists — in that order.
Objective A signed mapping spec that covers objects, relationships, picklist values and currency handling.
Keep these open
-
Map objects and their relationships first
Establish how Dynamics 365 Sales objects correspond to Salesforce objects before any field work. Leads-versus-contacts, accounts-versus-organisations and deal hierarchies differ structurally between CRMs, and a field map built on the wrong object model has to be redone.
Schema Mapper Opens pre-loaded with the Dynamics 365 Sales → Salesforce field pair -
Generate and then hand-review the field map
Auto-match both schemas, then review every row. Look hardest at anything named "type", "source", "stage" or "status", where names match and meanings do not.
-
Map every picklist value, including retired ones
Enumerate all values on both sides — deal stages, lead sources, industries, statuses — and map each explicitly, including values no longer offered but still present on old records. Unmapped values either fail the row or land as blanks that quietly break segmentation.
Historical records often carry picklist values that were retired years ago and no longer appear in the UI.
-
Decide currency, amount and date handling
If you sell in multiple currencies, confirm how Salesforce stores amounts, exchange rates and dated conversion rates. Recalculating historical deal values at today's rate silently rewrites your revenue history.
Multi-currency deals re-converted at current rates will not tie to your historical reporting or your finance system.
-
Determine the load order
Sequence the load so parents exist before children: users, then accounts, then contacts, then deals, then activities and notes. Keep source IDs in custom fields so relationships can be rebuilt by lookup rather than guesswork.
-
Freeze the spec and sign off
Version-control the mapping, walk RevOps and sales leadership through the decisions that change reporting, and get written sign-off before the pilot.
Dynamics 365 Sales → Salesforce specifics
- Custom Fields per Object
- Count custom fields on each Dynamics 365 entity. FSC's managed package pre-consumes custom field slots — the Account object is most constrained, with the FSC managed package consuming approximately 100–150 of the 500 available custom field slots (varies by FSC version and enabled features). Run SELECT count() FROM FieldDefinition WHERE EntityDefinition.QualifiedApiName = 'Account' AND IsCustom = true in your FSC sandbox to see actual availability.
Don't move on until
- Object and relationship model mapped and reviewed
- Every picklist value explicitly mapped, including dead values
- Load order determined so parents always exist before children
04 Test Migration Pilot with related records, not a flat sample.
Objective A pilot load whose relationships, ownership and roll-up reporting all verify against source.
Keep these open
-
Configure the Salesforce sandbox to match the agreed model
Build the pipelines, stages, custom fields, record types and user roles first. Load into a default configuration and you will only discover the configuration defects at full scale.
-
Select a connected pilot slice
Take complete account trees — 50-100 accounts with all their contacts, deals, activities and files — rather than a flat random sample. Relationship defects are the whole point of a CRM pilot and a flat sample cannot expose them.
-
Run the load in dependency order with full logging
Load users, accounts, contacts, deals, then activities, logging every request against its source ID. Note which failures are transient (rate limits, timeouts) and which are structural (validation, missing parent).
-
Verify relationships and roll-ups
Confirm every deal sits on the right account with the right owner and stage, and that pipeline totals per account and per rep match Dynamics 365 Sales exactly. Roll-up mismatches almost always mean a relationship or currency defect upstream.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Measure throughput and project the full load
Record actual records-per-hour under Salesforce's API limits and extrapolate, remembering activity history usually dominates volume. If the projection exceeds your window, split the load or trim activity scope now.
-
Let reps work the pilot data
Put two or three reps in the sandbox against their own accounts. They spot missing context, wrong owners and unusable notes far faster than any reconciliation script, and their buy-in is what makes adoption work.
Don't move on until
- Relationships intact across the whole pilot slice
- Pipeline roll-ups match source for the pilot accounts
- Reps have worked pilot records and confirmed they are usable
05 Cutover Switch the revenue system with the pipeline intact.
Objective All in-scope CRM data live in Salesforce, integrations repointed, and reps selling on day one.
Keep these open
-
Pre-load history ahead of the freeze
Load closed deals, historical activities and inactive accounts while Dynamics 365 Sales stays live. Only open pipeline and the final delta need to move inside the window.
-
Publish the cutover runbook
A timed sequence with owners and abort criteria: freeze, final export, delta load, integration switch, smoke test, go/no-go, rep enablement. Pick a window that avoids quarter-end and month-end close.
-
Freeze Dynamics 365 Sales and take the final delta
Set Dynamics 365 Sales read-only and export everything changed since the pre-load. Reps updating deals during an unenforced freeze is the classic way to lose the most recent — and most valuable — pipeline changes.
A rep who updates a deal in the old CRM during the freeze will lose that update permanently.
-
Load the delta and reconcile the pipeline
Run the delta, then verify open pipeline value and count per rep against Dynamics 365 Sales before anything else. If the pipeline number is wrong on day one, reps stop trusting the system and never fully come back.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint every integration and verify with real records
Switch marketing automation, quoting, billing, enrichment, dialler and BI connections, then push a live record through each path. An unrepointed integration writing into the old CRM causes divergence that gets harder to reconcile every day.
Two-way integrations left pointing at the old CRM will keep writing there. Disable them before you switch, not after.
Cron Expression Builder Schedule the delta syncs that run through the freeze -
Go/no-go, then enable the reps
Call the decision explicitly against the exit criteria. Run enablement on real data with their own accounts on screen, and keep Dynamics 365 Sales read-only rather than cancelled until validation closes.
Don't move on until
- Historical load complete and reconciled before the freeze
- All integrations repointed and verified end to end
- Reps logged in with pipeline visible and correct
06 Validation Prove the revenue numbers tie out, then close the project.
Objective Reconciled data, forecast parity with pre-migration reporting, and signed acceptance.
Keep these open
-
Reconcile every object
Compare counts and values across accounts, contacts, deals, activities and files, plus field-level spot checks on a random sample. Produce a single report suitable for audit and for finance.
Migration Validation Tool Reconcile Dynamics 365 Sales and Salesforce record-for-record -
Tie the pipeline and forecast to baseline
Rebuild forecast, pipeline coverage and win-rate reporting and compare to pre-migration figures. Every variance needs an explanation — most trace back to stage or currency mapping decisions made in Field Mapping.
Stage-model changes will legitimately shift historical conversion rates. Restate the baseline rather than chasing the difference as a defect.
-
Verify ownership, visibility and permissions
Confirm every record has the right owner and that sharing rules, territories and role hierarchy give each rep exactly the visibility intended. Over-broad visibility in a CRM is a data-protection issue as much as a config one.
-
Re-profile for field completeness
Compare loaded null rates against the source profile per field. A field that arrived empty while counts matched is the failure counts alone cannot detect.
Data Profiler Prove field completeness held up through the load -
Test automation and integration write-back
Fire every workflow, assignment rule, sequence and notification, and confirm each integration writes correctly in both directions. Automation is rebuilt rather than migrated, so it is unproven until observed.
-
Sign off and schedule decommission
Get written acceptance against the Discovery criteria, keep Dynamics 365 Sales read-only for 30-90 days with a final archive export taken, then diarise cancellation so the contract does not auto-renew.
-
Record counts
Total records per entity in Dynamics 365 vs. FSC
Dynamics 365 Sales → Salesforce specifics
- Field-level spot checks
- Sample at least 5% of records and compare field values
- Relationship integrity
- Verify all Person Accounts have at least one ACR record
- Opportunity pipeline
- Confirm stage distribution matches source
- Activity linkage
- Verify activities are linked to correct parent records
- Financial Account ownership
- Every FinancialAccount must have a Primary Owner role record
Don't move on until
- Full reconciliation report complete across all objects
- Forecast and pipeline reports tie to pre-migration baselines
- Acceptance signed and Dynamics 365 Sales decommission scheduled
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
Entity FSC Target
| Dynamics 365 Sales field | Salesforce field | Notes |
|---|---|---|
| account (Organization) | Account (Business Account record type) | Map name, address1_*, telephone1, industrycode. Direct mapping for B2B accounts. |
| contact | Person Account | Not a standard Contact. Create Person Account records using the Person Account record type. Map firstname, lastname, emailaddress1, birthdate. |
| lead | Lead or Person Account + Opportunity | FSC supports Leads. For qualified leads at migration time, convert to Person Account + Opportunity. Depends on pipeline stage. |
| opportunity | Opportunity or Financial Goal | Map name, estimatedvalue → Amount, estimatedclosedate → CloseDate, statuscode → StageName. Long-term client objectives may map to Financial Goals depending on your FSC implementation. |
| task | Task | Direct mapping. Map subject, description, scheduledstart, scheduledend. Link via regardingobjectid → WhatId/WhoId. |
| Task (Email type) or EmailMessage | If Email-to-Case is enabled, use EmailMessage. Otherwise, map to Task with TaskSubtype = 'Email'. | |
| phonecall | Task (Call type) | Map to Task with TaskSubtype = 'Call'. Map phonenumber, subject, description. |
| appointment | Event | Map subject, scheduledstart → StartDateTime, scheduledend → EndDateTime. |
| annotation (Notes/Attachments) | Note, ContentNote, or ContentVersion | annotation.notetext → Note.Body. For rich text, use ContentNote. Attachments in annotation.documentbody require separate handling via ContentVersion + ContentDocumentLink. |
| Custom entities (e.g., Investment Portfolios) | FinServ__FinancialAccount__c or custom object | Map to FSC-native objects where possible rather than building custom objects from scratch. Record types control account type (Checking, Savings, Loan). |
| N/A (construct during migration) | Household Account + ACR | Build Household Accounts and Account-Contact Relationships to establish household membership. |
| Account-Contact relationships | AccountContactRelation | FSC uses ACR as a junction object. Set Roles and IsPrimary fields. |
| Connections/Relationships | AccountAccountRelation / Reciprocal Roles | Map inter-account relationships (subsidiary, parent company) and inter-person relationships. |
Dynamics 365 FSC
| Dynamics 365 Sales field | Salesforce field | Notes |
|---|---|---|
| Account Name | Account Name | Direct |
| Phone | Phone | Direct |
| Website | Website | Direct |
| Industry | Industry | Option Set → Picklist |
| Annual Revenue | Annual Revenue | Money → Currency |
| Contact First Name | First Name | Person Account field |
| Contact Last Name | Last Name | Person Account field |
| Contact Email | Person Account field | |
| Contact Birthdate | Birthdate | Date → Date |
| Contact ID | Source ID | Text (External ID) |
| Opportunity Name | Opportunity Name | Direct |
| Est. Revenue | Amount | Money → Currency |
| Est. Close Date | Close Date | DateTime → Date |
| Pipeline Phase | Stage | Option Set → Picklist |
| Owner | Owner | GUID → Salesforce ID (via crosswalk) |
| Status | Active | Transform 0/1 to True/False |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Contacts | high | Dynamics 365 Contacts must be transformed into Person Account records in FSC — not standard Contacts — requiring org-level Person Account enablement, record type assignment, and validation of all Contact-dependent triggers and automations in sandbox before cutover. |
| Accounts | low | B2B organization Accounts map relatively directly to FSC Business Account record types with standard field alignment on name, address, phone, and industry code, though Account-Contact Relationship junction records must be created separately to restore contact affiliations. |
| Households | high | Dynamics 365 Sales has no native household entity, meaning household groupings must be constructed during migration using address normalization heuristics and relationship field analysis, with false positives creating incorrectly merged households that are more difficult to split in FSC than to merge. |
| Opportunities | medium | Core Opportunity fields map with reasonable alignment, but pipeline stage values require explicit mapping from Dynamics statuscode integers to FSC StageName picklist values, and long-term client objectives may need to be rerouted to Financial Goal records depending on the FSC implementation design. |
| Leads | medium | FSC supports the Lead object, but leads that are already qualified at migration time should be converted to Person Account plus Opportunity records rather than imported as Leads, requiring a pipeline-stage evaluation and conversion step before load. |
| Tasks and Activities | medium | Tasks, phone calls, and emails require transformation into Salesforce Task records with the correct TaskSubtype field values, and all WhatId and WhoId lookup references must be remapped using the ID crosswalk table after related records are loaded. |
| Notes and Attachments | high | Dynamics annotation records containing binary attachment data in documentbody require separate extraction and re-upload as ContentVersion records with corresponding ContentDocumentLink associations, making them one of the most technically complex entity types to migrate correctly. |
| Custom Fields | medium | Custom fields on Dynamics entities must be recreated in FSC before migration, with option set integer values remapped to Salesforce picklist labels and all custom lookup fields updated via the ID crosswalk table to prevent broken references. |
| Users and Ownership | medium | All Dynamics 365 ownerid values must be remapped to provisioned Salesforce user IDs via a user crosswalk table built before migration begins, as records imported without a valid OwnerId will fail or default incorrectly. |
| Financial Accounts | high | Dynamics custom entities representing financial products such as investment portfolios or loan accounts must be mapped to FSC-native FinancialAccount records with the correct record types (Checking, Savings, Loan), and this schema design decision must be finalized in sandbox well before the migration load phase. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Person Account Model Decision
Enabling Person Accounts in FSC is irreversible at the org level, requiring all Dynamics 365 Contacts to be transformed into Person Account records rather than standard Salesforce Contacts, which triggers downstream impacts on Apex triggers, Flows, SOQL queries, and third-party integrations.
Household Construction from Scratch
Dynamics 365 Sales has no native household concept, so migration teams must apply address normalization heuristics, relationship field analysis, and shared Account associations to construct FSC Household Account records and AccountContactRelation junction objects — a data enrichment step that requires business stakeholder validation before load.
ID Crosswalk Table Management
All Dynamics 365 entity GUIDs used in lookup fields must be tracked in a crosswalk table and remapped to new Salesforce IDs post-migration to prevent orphaned records and broken relationship context across objects like Opportunities, Tasks, and Activities.
Option Set to Picklist Translation
Dynamics 365 stores option sets as integer values with display labels, requiring extraction of both value and label during export, explicit creation of matching picklist values in FSC before import, and careful mapping to avoid validation rule failures on fields like StageName and record Status.
Activity and Attachment Migration Complexity
Emails, phone calls, and appointments must be transformed into FSC Task and Event records with the correct TaskSubtype values, while Notes with attachments stored in Dynamics annotation.documentbody require separate handling via ContentVersion and ContentDocumentLink objects in Salesforce.
Financial Object Schema Alignment
Dynamics 365 custom entities representing investment portfolios or financial accounts must be evaluated against FSC-native objects such as FinancialAccount and FinancialHolding, requiring record type configuration and field-level mapping decisions that cannot be made during cutover week.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
How do you map Dynamics 365 Contacts to Salesforce Financial Services Cloud?
Dynamics 365 Contacts map to Person Accounts in FSC, not standard Salesforce Contacts. Person Accounts combine Account and Contact fields into a single record. You must also create Account-Contact Relationship (ACR) records to link Person Accounts to Household Accounts, which is how FSC models family and client group structures.
What are the API rate limits for Dynamics 365 and Salesforce FSC during migration?
Dynamics 365 returns a maximum of 5,000 records per API page and enforces service protection limits over 5-minute sliding windows. Salesforce Enterprise Edition starts at 100,000 REST API requests per 24 hours, and Bulk API 2.0 supports up to 100 million records per 24-hour period with 10,000 records per internal batch and a 150 MB per-job limit.
What is the correct load order for a Salesforce FSC migration?
The recommended load order is: 1) Users, 2) Business Accounts, 3) Household Accounts, 4) Person Accounts, 5) Account-Contact Relationships (ACR), 6) Account-Account Relationships (AAR), 7) Financial Accounts, 8) Opportunities, 9) Activities, 10) Attachments/Notes. Each step depends on IDs created in previous steps.
Can you undo Person Account migration in Salesforce FSC?
No. Enabling Person Accounts in a Salesforce org is irreversible — you cannot convert Person Accounts back to standard Accounts. This makes thorough testing in a sandbox org critical before any production migration. Your rollback plan should involve reverting users to Dynamics 365 and deleting records from the FSC sandbox.
How do you handle Dynamics 365 attachments during a Salesforce FSC migration?
Dynamics 365 stores attachments as Base64-encoded content in the annotation entity. You must extract the binary content, create ContentVersion records in Salesforce, then create ContentDocumentLink records to associate files with parent records. Stream files individually to avoid memory bloat, and verify total attachment size against your Salesforce file storage limits.