Migrate from Sharpspring to Microsoft Dynamics 365 Sales

Sharpspring contacts split based on lifecycle_stage value. Contacts with lifecycle_stage = 'Customer' or 'Evangelist' land as Dynamics 365 Contacts. All other stages (Subscriber, Lead, MQL, SQL) land as Dynamics 365 Leads. The split preserves the original Sharpspring contact ID as Source_System_ID__c for traceability and delta-run de-duplication.

Sharpspring companies map directly to Dynamics 365 Accounts without transformation. Parent-company relationships in Sharpspring translate directly to the ParentAccountId lookup field in Dynamics 365. During the pre-migration audit, the system performs circular reference detection to flag any orphan parent links or circular parent-child hierarchies that would break referential integrity before the migration run executes.

Sharpspring deals migrate as Dynamics 365 Opportunities. The dealname becomes Opportunity.Name, amount maps to Amount, closedate maps to CloseDate. The Sharpspring pipeline field maps to the Business Process Flow (BPF) name in Dynamics 365, which scopes the stage pick-list values.

Each Sharpspring pipeline requires a corresponding Dynamics 365 Business Process Flow. Sharpspring stage names and probabilities are mapped value-by-value into the BPF stage definitions. The BPF must be pre-created in Dynamics 365 before the migration run so stage pick-lists are available for assignment.

Sharpspring stage values map to Dynamics 365 BPF stage names per pipeline. Probability values and forecast category assignments are carried over as stage metadata. If Sharpspring stages have no exact Dynamics 365 equivalent, they are created as custom stage names within the BPF.

Dynamics 365 has no native lifecycle stage field, so the Sharpspring lifecycle_stage value is preserved as a custom pick-list field (lifecycle_stage__c) on both Lead and Contact entities. Stage-transition timestamps are maintained as Lifecycle_Stage_Changed__c custom datetime fields for historical reporting continuity. The custom field must be created in the Dynamics 365 solution before migration begins.

Sharpspring engagement activities map to Dynamics 365 activity entities: calls become Tasks with Type='Phone Call', emails become Emails, meetings become Appointments. Notes map to Dataverse Notes (not the legacy Note object). Original timestamps, subject lines, body content, and owner assignments are preserved across all activity types.

Sharpspring's tag system has no direct Dynamics 365 equivalent. Tags can be collapsed into a single delimited custom field (Sharpspring_Tags__c) on Contact or Lead, or preserved as a separate tagging table with a many-to-many relationship to Contact. The choice depends on whether the tagging logic needs to drive segmentation in Dynamics 365.

Every Sharpspring custom field that has no standard Dynamics 365 equivalent requires a pre-created custom field in the Dynamics 365 solution before migration. Field type mapping applies: Sharpspring text and number types map to Text and Number fields in Dynamics 365, date fields map to Date fields, and pick-list fields map to Option Set fields.

Sharpspring-specific engagement data (form submissions, page visits, email opens/clicks) does not have a standard Dynamics 365 equivalent. These are preserved as custom fields on the Contact or Lead record — each metric becomes a separate Number or Date field capturing the most recent occurrence timestamp and aggregate counts.

Sharpspring lead status pick-list values map directly to Dynamics 365 Lead.Status field. If Sharpspring uses custom status values beyond the standard set, those require Option Set value creation in the Dynamics 365 solution before migration populates them. The mapping preserves all status transitions and ensures downstream workflow triggers fire correctly after migration.

Sharpspring owner IDs are resolved against Dynamics 365 SystemUser records by email address match. Unmatched owners are flagged before migration begins — your team either provisions the user in Dynamics 365 first or assigns records to a designated fallback owner. No record migrates without a valid OwnerId.