Migration route

Microsoft Dynamics 365 to Salesforce Data Migration

Migrate accounts, contacts, leads from Microsoft Dynamics 365 to Salesforce using a controlled process for extraction, mapping, transformation, validation, loading and reconciliation.

Typical data scope

Scope is agreed in discovery. On this route it usually covers:

Source-to-target mapping

A mapping workbook carries every field in scope from its Microsoft Dynamics 365 source through its transformation rule to the Salesforce target object and field. It is reviewed and approved with the business before the production migration, and applied identically in every cycle so a decision made once is not re-made under cutover pressure.

How Salesforce accepts the data

Load order is part of the design, not an implementation detail.

1. 1Reference and setup data firstTerritories, currencies, price books, products and picklist values. Everything downstream resolves against these.
2. 2Accounts, then contactsAccounts head the customer hierarchy. Parent-child account relationships resolve in a second pass, because a parent has no target key until it has itself been created.
3. 3Use External Id fields for upsertLoading against an External Id makes a reload an update rather than a duplicate, which is what makes multiple migration cycles survivable.
4. 4Leads with conversion state intactSo converted leads are not re-presented to sales as open work on day one.
5. 5Opportunities and line itemsResolved against account and owning user. Stage and close date drive forecasting, so their mapping is validated rather than assumed.
6. 6Activities, cases and historyEach resolving to a parent that now exists.
7. 7Ownership and sharingOwner drives visibility. Where a source owner has no counterpart, the fallback is an explicit decision rather than a default.

Migration cycles

The pipeline is run end to end more than once before anything touches production. A typical structure is a first rehearsal that surfaces the bulk of mapping and data-quality corrections, a second that applies them and demonstrates production readiness, and the production cutover itself. How many cycles a programme needs depends on data quality and scope, which is established during discovery.

1. 1Mock / PPR 1First full extract, transform, load, reconcile and exception analysis. Expect the largest correction list here.
2. 2Mock / PPR 2Corrections applied, re-extract, re-run. Intended to closely replicate the production migration.
3. 3Production cutoverFinal extract, data freeze, load, reconciliation, business validation and sign-off.

How Syntra ETL supports this route

Related migration routes