Migrate from SalesTown CRM to Salesforce Sales Cloud

SalesTown CRM Leads are the primary acquisition object, collected via auto-capture and distributed through smart rules in the Lead Management System. We map them directly to Salesforce Lead, preserving lead source, owner assignment, lead status, and any scoring properties. The Lead object is created in Salesforce before Contact migration begins so that any Leads-to-Contacts conversions can proceed post-migration. Custom lead properties from SalesTown CRM export inspect the available fields and map them to typed Salesforce custom fields on the Lead object.

SalesTown CRM Contacts carry name, phone, email, and custom properties linked to the Lead Management System. We map them to Salesforce Contact, preserving owner assignment (resolved by email match), phone numbers, and any custom contact-level fields available in the export. Contacts are inserted after Account creation so that the AccountId lookup is satisfied at insert time. If the source export contains Contacts without an associated Company/Account, we create a placeholder Account named after the Contact's company field or personal name for solo contacts.

SalesTown CRM Company records exist but their field schema is not publicly documented. We inspect the CSV export during the discovery phase to enumerate available company fields, map each to the corresponding Salesforce Account field, and flag any unmapped fields for a post-migration cleanup. Company domain or website becomes the Account Website field and serves as the dedupe key. Account is inserted before Contact to establish the parent lookup relationship.

SalesTown CRM Deals carry amount, stage, owner, expected close date, and associated pipeline reference. We map them to Salesforce Opportunity, preserving Amount, CloseDate, Description, and OwnerId (resolved by email). The dealstage property maps to the Salesforce StageName value that corresponds to the destination pipeline's configured stage. Deals are inserted only after the destination Salesforce Pipeline, Record Type, and Sales Process are fully configured, so that RecordTypeId and StageName are valid at insert time.

SalesTown CRM Pipelines are customizable with configurable Stages per pipeline. We export pipeline names, stage order, and stage-specific win/loss flags from SalesTown CRM during discovery. In Salesforce, each SalesTown Pipeline becomes a Record Type on Opportunity with a corresponding Sales Process that whitelists the stage values. We configure this in Salesforce Setup or via metadata API before any Deal records are migrated, ensuring that every incoming Deal has a valid StageName and RecordTypeId.

SalesTown CRM Stages are pipeline-specific with names, probabilities, and ordering. We map stage-to-stage explicitly rather than by position, because source and destination pipelines may have different stage counts. The SalesTown stage probability maps to Salesforce StageProbability (rounded to the nearest integer). Closed-Lost and Closed-Won stages from SalesTown CRM are mapped to the corresponding Salesforce standard stage values.

SalesTown CRM Activities log individual touchpoints (calls, emails, WhatsApp) linked to Contacts or Leads. We split the activity type at migration time: call activities map to Task with TaskSubtype=Call and CallDurationInSeconds; email activities map to Salesforce EmailMessage records linked to an Activity Task; WhatsApp activities map to Task with a custom TaskSubtype and a custom WhatsApp body field, since Salesforce does not have a native WhatsApp object. The WhoId on each activity resolves to the migrated Salesforce Lead or Contact ID. WhatsApp message status flags map to custom picklist fields.

SalesTown CRM WhatsApp activities carry thread-level metadata including message status flags and timestamp sequences that flat CSV exports split into individual rows, losing parent-child thread associations. We reconstruct thread relationships during the transform phase by grouping rows on ConversationID (or a composite of ContactID + date range when no explicit thread ID is available), ordering by timestamp, and setting a custom thread_reference__c field on all rows belonging to the same WhatsApp conversation. The thread ordering is preserved via the ActivityDate sequence, rehydrating conversation continuity in the Salesforce Activity Timeline.

SalesTown CRM Users carry name, email, and team assignment. We map SalesTown Users to Salesforce Users by email match. Any SalesTown Owner whose email does not correspond to a Salesforce User record is held in a reconciliation queue for the customer's admin to provision before record import resumes, because OwnerId is a required reference on most Salesforce standard objects. We flag any duplicate email addresses in the destination org before migration begins.

SalesTown CRM customizable email and communication templates exist but have no documented export schema. We export available template metadata (name, subject, associated pipeline, and any visible body text) and flag the template body mapping as a post-migration task. The customer's admin rebuilds the template content in Salesforce Email Templates or Lightning Email Templates using the exported metadata as a reference. We do not attempt to reconstruct template body HTML from the export without schema documentation.

SalesTown CRM Reports and Dashboard definitions are stored server-side with no documented export mechanism. We do not migrate report or dashboard configurations. We migrate the underlying data (Leads, Contacts, Accounts, Deals, Activities) so that the customer's Salesforce admin can rebuild equivalent reports in Salesforce Reports & Dashboards using the migrated dataset. We provide a written mapping of SalesTown report names to the corresponding Salesforce report types and objects for the admin's reference rebuild.

SalesTown CRM's smart lead distribution rules assign Leads to Users based on geography, team, or round-robin logic. These rules do not have a documented export mechanism and cannot be migrated as code. We document the rule logic identified during discovery interviews and deliver an Assignment Rules design document for the customer's Salesforce admin to configure in Salesforce Lead Assignment Rules or Omni-Channel. The admin implements the equivalent routing logic post-migration.