Migrate from Sellsation CRM to Salesforce Sales Cloud

Sellsation Customers are the primary account-level records containing company information, linked to Contact Persons and Sales Projects. We map these 1:1 to Salesforce Account, preserving the Customer name as Account Name, any industry or classification fields as custom Account fields, and the Customer's internal Sellsation ID as a custom field sellsation_id__c for audit and reconciliation. Account is the parent record for all Contact imports.

Sellsation Contact Persons are individual contacts linked to Customers with full activity history including calls, meetings, and notes. We map these 1:1 to Salesforce Contact, preserving the Customer link as AccountId lookup and the Sellsation internal ID as sellsation_id__c. Any Sellsation traffic-light status (green/yellow/red indicating neglect) is preserved as a custom field traffic_light_status__c so the Salesforce admin can prioritize outreach on neglected contacts after migration.

Sellsation Sales Projects are the deal/opportunity records tracked through pipeline stages with automated potential analysis. We map these to Salesforce Opportunity, preserving the pipeline stage name as StageName, the deal value as Amount, and any Sellsation potential score as a custom field potential_score__c. The traffic-light stagnation flag from Sellsation migrates as a custom stagnation_days__c integer field so the new Salesforce admin can rebuild stagnation alerts in Salesforce Flow.

Sellsation's guided pipeline stages map to Salesforce Opportunity Stage values. We enumerate all Sellsation stage names during scoping, create matching Salesforce stage values with probability percentages, and configure a Salesforce Sales Process that scopes the stage whitelist per pipeline. If the customer uses multiple Sellsation pipelines, we create Salesforce Record Types to separate stage sets.

Sellsation Activities (calls, appointments, notes, tasks attached to Contact Persons or Sales Projects) map to Salesforce Task and Event objects. We distinguish by Sellsation activity type: calls map to Task with TaskSubtype=Call, appointments map to Event with StartDateTime/EndDateTime preserved, notes map to Salesforce Note linked via ContentDocumentLink, and tasks map to Task with Status, Priority, and ActivityDate. We use the Bulk API 2.0 with time-bounded chunking because Sellsation teams with years of history can have activity counts 10-20x their contact count.

Sellsation multi-level campaigns (combining emails, letters, conditional stage movements, and automated task creation) map to Salesforce Campaign records, but the automation logic does not migrate. We export campaign structure (name, type, status, start and end dates, budgeted cost) and campaign member enrollment data. The conditional stage movement logic and automated task creation rules are documented in the handoff inventory for rebuild in Salesforce Flow.

Sellsation Tasks assigned to users with due dates, linked to Contact Persons or Sales Projects, map directly to Salesforce Task. Task status, assignment (OwnerId via email match to Salesforce User), priority, and due date migrate. Sellsation task linking to Contact or Sales Project is preserved via the WhatId lookup pointing to the migrated Contact or Opportunity.

Sellsation Calendar appointments with date, time, duration, and attendee lists attached to Contact Persons map to Salesforce Event. StartDateTime, EndDateTime, Subject, Location, and DurationInMinutes migrate. Attendee lists map to Salesforce EventRelation records pointing to the migrated Contact and User records. Any appointment notes migrate as Event Description.

Sellsation supports custom fields on primary objects (Customers, Contact Persons, Sales Projects, Activities). We enumerate all custom fields during scoping, map them to Salesforce custom property schemas on the corresponding standard or custom objects, and flag any with picklist or formula dependencies for the customer admin to resolve before migration. Custom field API names are preserved with __c suffix per Salesforce standard. Picklist value mismatches require a mapping table during transform.

Sellsation territory and heatmap data is stored as internal map state rather than standard geographic coordinates. We export the linked Sales Project location data as standard address fields (Street, City, State, PostalCode, Country) and a custom geolocation field (latitude/longitude via custom number fields) so the geographic context is available for Salesforce territory management, MapAnything, or GeoPointe. The native heatmap visualization does not migrate.

Sellsation KPIs and custom reports store platform-native configurations with no export mechanism. We export all underlying data—Sales Projects with pipeline metrics, activity counts, deal values, stage durations—so the customer's Salesforce admin rebuilds reports from complete source data. The KPI dashboard layout and custom report definitions are documented in the handoff inventory with recommended Salesforce Report Type and Dashboard equivalents.

Sellsation users assigned to Contacts, Companies, Sales Projects, Activities, and Tasks map to Salesforce User by email address match. We extract every distinct Sellsation user referenced in the export, match against the destination Salesforce org's User table, and hold any unmatched owners in a reconciliation queue for the customer's admin to provision before record import proceeds. Inactive Sellsation users with historical record assignments are mapped to Salesforce Users with IsActive=false.

Sellsation captures survey responses as activities linked to Contact Persons. We export survey response data as Salesforce Tasks with custom fields capturing response scores and survey identifier, linked via WhatId to the parent Contact. The customer's Salesforce admin can rebuild survey collection using Salesforce Forms or a native Survey tool post-migration.