Migrate from Sellsation CRM to Microsoft Dynamics 365 Sales

Sellsation Customers (company-level records) map directly to Dynamics 365 Accounts. We use the Sellsation Customer name as the Account Name field and the primary address block as the Account address. Account is the first object migrated because Contact Persons and Sales Projects link to it via lookup. If the customer uses Sellsation's multi-address features (billing vs. shipping), we map these to the Account's address fields and any custom address fields in Dynamics.

Sellsation Contact Persons map to Dynamics 365 Contacts with the Customer reference resolved to AccountId at migration time. We preserve the contact's email, phone, role, and any custom fields. Sellsation stores the relationship between Contact Persons and their linked Customer as a foreign key; we resolve this to the Dynamics Account lookup during the Contact import phase. Contacts without a valid AccountId are held in a reconciliation queue for the customer's admin to resolve before the migration completes.

Sellsation Sales Projects map to Dynamics 365 Opportunities. The Sellsation pipeline stage name becomes the Opportunity's StageName, and we configure the corresponding Business Process Flow and sales process in Dynamics 365 before migration. The estimated deal value, close date, and potential analysis fields migrate as Opportunity fields. Closed-won and closed-lost outcomes and timestamps are preserved as stage transition data.

Each named pipeline stage in Sellsation becomes a configured Opportunity Stage in Dynamics 365. We create a Business Process Flow that mirrors Sellsation's guided pipeline stages, with stage names, probabilities, and optional required fields matching the source. Traffic-light stagnation indicators from Sellsation transfer as a custom indicator field (stagnation_days__c or similar) rather than as native automation rules, since Dynamics does not replicate Sellsation's automated deal-flagging behavior natively.

Sellsation Activities encompass calls, appointments, notes, and tasks in a single object distinguished by an activity_type field. We split this into the appropriate Dynamics 365 entity: calls become Task records with TaskSubtype = Call and call disposition fields; appointments become Event records with start/end time, duration, and attendees; notes become Note records linked via ContentDocumentLink; standalone tasks become Task records. The original Sellsation timestamp and linked Contact Person or Sales Project are preserved on every record.

Sellsation multi-level campaigns map to Dynamics 365 Campaigns, but the nested action structure (automated emails, conditional stage movements, task creation) requires manual rebuild in Power Automate or Dynamics workflow designer. We export the campaign name, target audience contacts, campaign status, and scheduled dates as Campaign records and CampaignMember entries. The detailed automation logic is documented in the campaign handoff inventory so the customer's Dynamics admin rebuilds it post-migration.

Sellsation Tasks map directly to Dynamics 365 Tasks. Task status (open, completed), due date, assigned user, and linked Contact Person or Sales Project migrate as-is, with the OwnerId resolved by email match against the destination User table. Tasks without a matching user are flagged in the reconciliation report.

We enumerate every Sellsation custom field during scoping and map each to an equivalent Dynamics 365 custom field on the corresponding entity. Picklist fields require pre-created option sets in Dynamics; formula fields are flagged as requiring recalculation post-migration since formulas do not carry their logic across platforms. Custom field dependencies (fields that trigger other field visibility or requirements) are documented separately for the customer's admin to re-implement.