Migrate from EspoCRM to Salesforce Sales Cloud

EspoCRM Contact records map directly to Salesforce Contact. The Email field serves as the dedupe key during import. We map all standard fields (FirstName, LastName, Phone, MobilePhone, MailingAddress) plus any custom fields. EspoCRM multi-email fields (multiple email addresses on one contact) require splitting: the primary email maps to Email and additional addresses are stored in a custom Textarea field custom_email_secondary__c. Multi-enum fields (capped at 20 options in EspoCRM) map to Salesforce Multi-Select Picklist fields with no option count limit.

EspoCRM Account records map to Salesforce Account. We use the Account Name as the dedupe key. The industry sector, annual revenue, number of employees, website, and billing address fields map directly. Custom fields on EspoCRM Account map to custom fields on Salesforce Account (with __c suffix). Account must be created before Contact import so that AccountId Lookup is satisfied at insert time.

EspoCRM Lead records map to Salesforce Lead. EspoCRM stores Lead status in a status field with custom values; we map those values to Salesforce Lead Status picklist entries, creating new Status values in the destination org if the EspoCRM values do not already exist. Converted Leads (those that have been converted to Contact and Account in EspoCRM) are handled separately: we migrate the original Lead record and link it to the converted Contact via a custom field espo_converted_contact_id__c for audit trail.

EspoCRM stores converted Lead records with links to the resulting Contact and Account. During migration, we identify converted Leads by the presence of convertedContactId and convertedAccountId fields, then create both the Account (if not already present) and the Contact in Salesforce, and store the original EspoCRM Lead ID on the Contact in a custom field espo_lead_id__c for lineage tracking.

EspoCRM Opportunity records map to Salesforce Opportunity. Stage, probability, amount, close date, and description fields migrate directly. The pipeline assignment in EspoCRM maps to a Salesforce Record Type and Sales Process that we configure before migration. Custom fields on EspoCRM Opportunity (including any fields tracking product lines or deal-specific attributes) map to custom Opportunity fields in Salesforce.

EspoCRM Case records (support tickets) map to Salesforce Case. Status, Priority, and Resolution fields map to their Salesforce equivalents. The conversation thread (case comments and customer replies) migrates as CaseComment records linked to the Case. Attachments on Cases are extracted from the EspoCRM filesystem (on self-hosted) or database (on cloud) and re-registered as Salesforce ContentDocument records linked to the Case via ContentDocumentLink.

EspoCRM Campaign records map to Salesforce Campaign. Campaign name, type, status, start date, end date, budgeted cost, and actual cost migrate directly. The target Leads and Contacts list migrates as CampaignMember records (with Member Status values). We do not replicate email send history, open rates, or click-through data; EspoCRM does not expose this as structured data via its API, and reconstructing it from email integration logs is outside migration scope.

EspoCRM User records map to Salesforce User records by email address match. Role assignments and team memberships are recorded in custom fields (espo_role__c, espo_teams__c) because Salesforce role hierarchies and groups are org-wide structures that require admin design decisions rather than direct mapping. The customer's Salesforce admin provisions Users in the destination org before migration; we reconcile EspoCRM users against existing Salesforce Users and flag any without a match for manual provisioning.

EspoCRM Meeting records map to Salesforce Event with StartDateTime, EndDateTime, and Location preserved. The meeting description becomes the Event Description field. Attendees are mapped to EventRelation records pointing to the corresponding Contact, Lead, or User in Salesforce. Activity date ordering is preserved by setting the original EspoCRM timestamp.

EspoCRM Call records map to Salesforce Task with TaskSubtype set to Call. Call duration, disposition, and any notes migrate to custom Task fields. The original timestamp is preserved in ActivityDate. If the EspoCRM instance stores call recordings as file attachments, those files are extracted from the filesystem and attached to the Task as ContentDocument records.

EspoCRM standalone Task records map to Salesforce Task with Status, Priority, DueDate, and ActivityDate preserved. Task assignment migrates by resolving the EspoCRM assigned user (by email) to the Salesforce OwnerId via the User mapping. If the EspoCRM task is linked to a parent record (Contact, Account, Opportunity, Case), we resolve the parent reference and set WhatId or WhoId accordingly.

EspoCRM email records migrate to Salesforce as EmailMessage records (the email content) linked to an Activity Task record (the timeline entry). The email body, subject, from address, and to address migrate directly. The WhoId on the Task points to the related Contact or Lead; the WhatId points to the related Opportunity, Account, or Case. EmailMessage direction (inbound vs outbound) is preserved.

EspoCRM Document records linked to other entities (Contacts, Accounts, Opportunities) map to Salesforce ContentVersion and ContentDocument records. On self-hosted EspoCRM instances, the actual file data lives on the server filesystem under data/files/ rather than in the database. We identify all Document records during discovery, extract the referenced files from the filesystem archive, and upload them to Salesforce as ContentVersion records. On cloud-hosted EspoCRM, the file data is in the database and migrates with the standard database export. We re-register each file with the corresponding ContentDocumentLink to the parent record (Contact, Account, Opportunity, or Case).

EspoCRM custom entity types created via Entity Manager map to Salesforce Custom Objects with a __c suffix. We export the entityDefs metadata from EspoCRM first (field names, types, relationships, validation rules), then pre-create the destination Salesforce custom object schema including all custom fields, lookup relationships to standard objects (Contact, Account, Opportunity, Case), and validation rules. Custom entity relationships that reference other custom entities require topological sorting: we build a dependency graph, import entities with no dependencies first, then progressively import entities whose dependencies are satisfied.

EspoCRM link-multiple relationships (many-to-many or many-to-one) map to Salesforce Custom Object lookups or Master-Detail fields depending on the cascade-delete requirement. If EspoCRM's relationship is configured as required (mandatory link), we use Master-Detail; otherwise we use Lookup. Junction objects in EspoCRM (entities that hold two link-multiple references as a many-to-many join table) map to Salesforce junction objects with two Lookup fields.

EspoCRM Note records migrate to Salesforce Note records. The Note body migrates as plain text. If the Note contains embedded images, those images are extracted as separate files from the EspoCRM filesystem and re-attached to the Salesforce Note. Notes are linked via ContentDocumentLink to the parent record (Contact, Account, Opportunity, Case, or custom object).