Migrate from Sugar Market to Microsoft Dynamics 365 Sales

Sugar Market Account records map directly to Microsoft Dynamics 365 Sales Account. The Account Name, Industry, Website, Phone, and Address fields map 1:1 to the corresponding Account fields. The Sugar Market Account ID is preserved in a custom field sm_account_id__c for audit and cross-reference during the migration window. Accounts are imported before Contacts so that the AccountId lookup is satisfied at Contact insert time.

Sugar Market Contact records map to Dynamics 365 Contact. Email, Phone, Job Title, Department, and Address fields migrate 1:1. The Sugar Market lifecycle stage and lead score properties are preserved in custom fields sm_lifecycle_stage__c and sm_lead_score__c as reference data since Microsoft Dynamics 365 Sales does not have a native lifecycle stage property on Contact.

Sugar Market Contacts with a lifecycle stage of subscriber, marketing qualified lead, or early lead are candidates for the Salesforce-style Lead-to-Contact split in Microsoft Dynamics 365 Sales . We define the split threshold during scoping based on the customer's Sugar Market lifecycle stage matrix. Contacts above the split threshold map to Lead; those at sales qualified or customer stage map to Contact attached to an Account. The original lifecycle stage is preserved in a custom field on both Lead and Contact for audit and reporting continuity.

Sugar Market Opportunities sync from the marketing platform to the parent Sugar Sell/Serve instance, but the association graph is CRM-driven. We export Opportunities with their stage, amount, close date, and linked Account ID, then map to Dynamics 365 Opportunity. The Sugar Market opportunity stage name maps to a Microsoft Dynamics 365 Sales Process stage that we configure before migration. Close date and amount migrate directly. Opportunity ownership migrates by resolving the Sugar Market Owner email to the corresponding Dynamics 365 User.

Sugar Market Campaigns map to Dynamics 365 Campaign. Campaign Name, Status, Start Date, End Date, Budget, and Type migrate as standard Campaign fields. Campaign member associations (Contacts enrolled in a campaign) migrate as CampaignMember records linked to the corresponding Dynamics 365 Contact or Lead. Campaign performance metrics (open rates, click rates) are preserved as custom fields on Campaign since Dynamics 365 standard Campaign does not store these natively.

Sugar Market Nurture flows store branching logic, step sequences, and contact enrollment states. The REST API exposes nurture definitions and enrollment records but does not surface the full branching ruleset in a portable format. We export nurture enrollment data (which Contacts were enrolled, step reached, enrollment date, completion status) as a mapping manifest. The customer evaluates Dynamics 365 Marketing, ClickDimensions, or a dedicated marketing automation tool as the nurture replacement. We do not migrate Nurture flows as code.

Sugar Market Landing Pages are associated with Forms and Campaigns. We export page metadata (URL slug, page title, form associations) as a mapping manifest. Landing page body content requires HTML export and re-rendering in the destination platform. Dynamics 365 Marketing or a third-party landing page tool replaces this capability. We do not migrate Landing Pages as functional records; we deliver a manifest of what existed for the customer's marketing team to rebuild.

Sugar Market Forms capture field definitions, submission routing, and progressive profiling settings. We export field names and types as a mapping manifest. The form schema and submission counts transfer as documentation. Dynamics 365 Marketing forms, Power Apps portals, or a third-party form tool replaces this capability. We do not migrate Forms as functional records; we deliver a manifest for the customer's marketing admin to rebuild in the chosen replacement tool.

Sugar Market engagement records (Calls, Emails, Meetings, Tasks) map to the corresponding Dynamics 365 activities using the Dataverse activity entities. Calls map to PhoneCall, emails to Email, meetings to Appointment, and tasks to Task. We use the Dynamics 365 webapi with batch operations and parent-record lookup resolution (regardingobjectid for Account, Contact, Lead, or Opportunity) to preserve the activity timeline ordering. ActivityDate (actualend or scheduledend) is set to the original Sugar Market timestamp to maintain chronological sequence.

Sugar Market Web Activity tracks anonymous and known visitor behavior tied to Contacts (page views, form submissions, email opens). The API exposes activity type, timestamp, and contact association. We export this as a custom activity entity or Note records on the corresponding Dynamics 365 Contact, depending on the customer's chosen data model. Web activity data does not map to a standard Dynamics 365 object and is delivered as structured CSV plus a schema definition for the customer to configure the custom activity or integrate with a marketing analytics connector.

Sugar Market Distribution Lists group Contacts for segmented sends. We export list membership per Contact as a CSV mapping manifest that lists the Dynamics 365 Contact ID or email against the Distribution List name. If the customer licenses Dynamics 365 Marketing, the lists import as Marketing List or Static List records with membership populated from the manifest. If Dynamics 365 Marketing is not in scope, the manifest is delivered as a reference document for the customer's marketing ops team to recreate segmentation logic in their chosen marketing tool.

Sugar Market custom fields on Accounts, Contacts, and Opportunities migrate to custom fields on the corresponding Dynamics 365 entities. We detect the custom field schema during discovery and pre-create the Dynamics 365 custom fields (with appropriate types: text, number, picklist, date) in a solution before data import. If the customer is on Sugar Sell Essentials, we confirm during scoping that only Studio-managed custom fields are in use, since Module Loader package uploads are blocked on that tier and any vardef-based custom fields cannot be exported.