Migrate from Crust CRM to Salesforce Sales Cloud

Crust CRM Contact records with an unqualified or prospect-level status property map to Salesforce Lead. Contacts with a customer, account, or active-stage status property map to Salesforce Contact tied to an Account. We compute the split using the source Contact's status and stage fields, and preserve the original status in a custom field crust_original_status__c on both Lead and Contact for audit. If Crust CRM stores Leads and Contacts in a single object, we apply the same split logic during the migration transform.

Crust CRM Company records map directly to Salesforce Account. The company domain or website field becomes the Account Website, and domain name is used as the dedupe key during import. Account is provisioned before any Contact import so the AccountId Lookup is satisfied at Contact insert time. We run deduplication checks against existing Account records using company name and domain as match keys.

Crust CRM Deal records map to Salesforce Opportunity. The source dealstage field maps to Salesforce StageName via the translation table collected during discovery. Closed-Lost and Closed-Won dates migrate to CloseDate and any custom loss-reason fields present in the source. Amount, probability (if present), and close date transfer directly. OwnerId is resolved via User mapping at migration time.

Crust CRM pipeline and stage definitions are organization-specific and stored in the platform's workflow configuration. We collect the full pipeline-stage map during schema discovery and generate a Salesforce Record Type and Sales Process for each Crust pipeline. Each stage name in Crust maps to a StageName value in Salesforce with probability percentages rounded to the nearest integer that Salesforce accepts. If Crust CRM stores pipeline metadata as custom module records rather than platform-native configuration, we extract them during the schema audit and generate the translation table from that export.

Where Crust CRM stores Leads as a distinct object from Contacts, they map directly to Salesforce Lead. The source lead status field maps to Salesforce Lead Status with a custom field crust_lead_score__c carrying any imported scoring value. If the source stores a qualification rating or tier, we preserve it as a custom Salesforce field.

Crust CRM task records map to Salesforce Task with Status, Priority, ActivityDate, and subject preserved. Owner assignment migrates by resolving the source owner reference to the Salesforce OwnerId via the User mapping. Tasks without a resolvable owner are placed in a reconciliation queue.

Crust CRM call records map to Salesforce Task with TaskSubtype = Call. Call disposition, duration, and any recording URL field migrate to custom Task fields. ActivityDate preserves the original timestamp to maintain timeline ordering in the Salesforce activity feed.

Crust CRM email engagements migrate to Salesforce EmailMessage records (the email content) linked to an Activity Task record (the timeline entry). The WhoId on Task points to the converted Lead or Contact; WhatId points to the related Opportunity or Account. Body content and subject transfer as plain text. Attachments migrate as ContentDocument records linked via ContentDocumentLink.

Crust CRM meeting records map to Salesforce Event with StartDateTime, EndDateTime, Location, and Subject preserved. Attendee mapping links to EventRelation records pointing at the converted Leads, Contacts, and Users. If the source meeting records include an agenda or body field, it migrates as the Event Description.

Crust CRM notes migrate to Salesforce Note records linked via ContentDocumentLink to the parent record (Lead, Contact, Account, or Opportunity). Note body migrates as rich text with any embedded file attachments preserved as separate ContentDocument records. If the source stores notes with an is_pinned flag, we carry that as a custom Note field.

Crust CRM's configurable module architecture means every organization may have unique custom objects not present in a standard install. We run a pre-migration schema audit to enumerate every custom module, its field types, and any lookup dependencies between modules. We pre-create the destination Salesforce custom object schema (with __c API names matched to Crust module names) including all custom fields, lookup relationships, and validation rules before any data import. Unsupported field types (e.g., Crust-specific data types with no Salesforce equivalent) are flagged for the customer to resolve before migration begins.

Crust CRM user records map to Salesforce User by email match. We extract every distinct owner referenced on Contact, Company, Deal, and Activity records and match against the Salesforce destination org's User table. Users without a match go to a reconciliation queue; the customer's Salesforce admin provisions missing Users before record import resumes. Inactive source users map to inactive Salesforce users so historical assignment is preserved without licensing implications.

Crust CRM file attachments stored per-record migrate as Salesforce ContentDocument records attached via ContentDocumentLink to the parent record (Lead, Contact, Account, or Opportunity). We export files individually, preserving filename and record association, and re-attach them in Salesforce using the Bulk API 2.0 for files over the individual API attachment threshold. Very large files or image-heavy attachments may require separate handling depending on the source storage backend.

Crust CRM tags and label fields stored as multi-checkbox properties migrate to Salesforce multi-select picklist fields where the tag set is bounded and small (fewer than 150 unique values). For open-ended tag sets, we recommend Salesforce Topics with TopicAssignment records. The customer chooses the tag strategy during scoping based on the source tag volume and intended use in Salesforce reporting.

Crust CRM's built-in enterprise messaging module generates Slack-like thread conversations that have no direct Salesforce equivalent. We export the messaging metadata (participant list, thread timestamps, message bodies) as a structured JSON dataset during schema discovery and deliver it as a written inventory. For organizations that use Crust Messaging for customer-adjacent collaboration rather than customer-facing support, we recommend replicating thread context in Salesforce Chatter (available on Professional and above) or in a linked Confluence-style wiki. We do not migrate Crust Messaging as live Salesforce records without explicit scoping and a customer-approved data model.