Migrate from Civicrm to Salesforce Sales Cloud

CiviCRM Contact subtypes (Individual, Household, Organization) map to Salesforce Contact with subtype preserved in a custom field civicrm_contact_type__c. Household contacts generate Salesforce Household Accounts via the NPSP Household model if installed, or standard Account records if not. Organization contacts map to Salesforce Account directly. We preserve all standard address blocks (street, city, state, postal code, country), email, phone, and relationship links. The CiviCRM display_name becomes Contact Name, and the CiviCRM sort_name becomes a custom field for alphabetical ordering.

CiviCRM Relationships (household member, employee-employer, spousal, and custom relationship types) map to Salesforce Contact Relationship records. We preserve the relationship type label, both contact references (contact_id_a and contact_id_b), and the is_active flag. Bidirectional relationship types generate two Contact Relationship records in Salesforce. The relationship start and end dates migrate as custom fields on Contact Relationship if the destination org uses the NPSP relationship model.

CiviCRM Activities (the catch-all engagement record for calls, emails, meetings, tasks, and custom activity types) map to Salesforce Task and Event objects. Activity type determines the destination object: email maps to Task with Subject and Description; call maps to Task with TaskSubtype=Call; meeting maps to Event with StartDateTime and EndDateTime. Custom activity types from CiviCRM become custom Task or Event record types. We set ActivityDate on Task and StartDateTime on Event to the original CiviCRM activity_date_time for timeline ordering. The activity's assignees ( civicrm_activity_contact with record_type = 3 ) resolve to Salesforce OwnerId via email match.

CiviCRM Contributions include financial_type, total_amount, currency, receive_date, and payment_instrument. If the destination Salesforce org uses NPSP, Contributions map to Opportunity with NPSP-specific fields (npe01__Amount__c, npe01__Payment_Method__c, npe01__Check_Number__c). If NPSP is not installed, we map Contributions to a custom object with equivalent fields and a lookup to the Contact. Price sets introduce variable line-item complexity that must be flattened: each price field value becomes a separate Opportunity Product line or a custom Contribution_Line_Item__c record. We resolve the financial_type to a Campaign or custom field for segregation.

CiviCRM Membership records include type, status, start_date, end_date, and source. With NPSP, these map to the standard Membership object (npe5__Membership__c) with a lookup to the Contact and a separate Membership Type record. Membership Price Sets allow complex tier structures that must be mapped to the destination membership tier configuration. Without NPSP, Memberships migrate as a custom object with equivalent fields and the membership status mapped to a custom picklist. The membership_id is preserved as a custom field for reconciliation.

CiviCRM Groups and their membership lists (GroupContact) are migrated as static segments. Each CiviCRM Group becomes a Salesforce Campaign with Campaign Member status values representing the original group membership records. We preserve the group hierarchy where it exists using Campaign parent-child relationships. Dynamic (smart) groups that are rebuilt on query conditions cannot be fully reproduced without re-running the query logic in Salesforce; we document each dynamic group definition and recommend Salesforce Reports or Campaign membership filters as the equivalent.

CiviCRM Events map to Salesforce Event records for date-based scheduling, with Price sets, event types, and participant roles requiring custom field mapping. Participant records (individual registrations for an event) migrate to a custom Event_Registration__c object with a lookup to the Contact and the Event. Online registration profiles are reconstructed as Salesforce Web-to-Lead forms or Experience Cloud site forms post-migration; we document the original profile field mapping for the customer's admin. Event status (Registered, Attended, No-show, Cancelled) maps to custom picklist values on the registration object.

CiviCase stores case_id, case_type, status, start_date, and a set of related activities. Case records and their activity chains migrate preserving timeline and assignee history. Case statuses are defined per-case-type within CiviCRM and are not global integers; they are type-scoped, which is a critical migration gotcha. We enumerate every active case_type during scoping, extract its status option values, and map them individually to Salesforce Case Status values or a custom case status set. Without Service Cloud, Cases map to a custom object with equivalent fields.

CiviCRM Tags are flat labels that attach to any entity (contact, activity, contribution, etc.). We map tags to Salesforce Topics with TopicAssignment records, or to a custom multi-select picklist field on the parent object depending on tagging volume. Multi-entity tagging requires separate TopicAssignment records per entity. Tags with high cardinality (over 50 distinct values on a single entity type) are mapped to custom picklist fields for usability in Salesforce reporting.

Grants is an optional CiviCRM extension module that not all instances have installed. Where present, we map grant_type, amount_requested, amount_granted, status, and deadline. Grant data often has tight coupling to Cases (the grant application case) and Contributions (the funded disbursement record), which we resolve through lookup resolution at migration time. Without NPSP Grant management, we create a custom Grant__c object with the standard CiviGrant fields and cross-references to the related Contact and Case.

Single-record custom groups in CiviCRM appear as fields on the parent entity via the custom.* selector in APIv4. Multi-record sets appear as separate entities prefixed Custom_. We query both via API and reconstruct them in Salesforce. Multi-record sets land as custom objects with a lookup to the parent record and a sequence or ordinal field to preserve ordering. The custom group name and field names are translated to valid Salesforce API names with __c suffix. Large numbers of custom groups (exceeding approximately 20) require individual entity-by-entity exports rather than bulk API calls due to MySQL join limits in CiviCRM APIv4.

ECK allows arbitrary custom entity types with user-defined properties and custom field attachments. These are extension-scoped and can reference contacts. We handle them as custom objects requiring explicit destination schema design for each ECK entity type. During scoping, we enumerate every active ECK entity type, its properties, and its contact reference fields. Each ECK entity becomes a Salesforce custom object with __c suffix and a lookup to Contact. We flag ECK entities separately in the migration scope because they represent non-standard schemas with no automatic mapping; the customer reviews and approves each ECK-to-custom-object mapping before migration runs.

CiviCRM stores file attachments either in the database (civicrm_file and civicrm_entity_file) or on the filesystem. We extract files from both sources, convert them to Salesforce ContentVersion binary blobs, and create ContentDocumentLink records linking to the parent Contact, Account, Opportunity, or custom object. The original file name and MIME type are preserved in ContentVersion fields. File size limits from Salesforce (25 MB per ContentVersion for most orgs) are enforced during extraction.

CiviCRM Notes migrate to Salesforce Note records linked via ContentDocumentLink to the parent Contact, Account, or custom object. Note body migrates as rich text with image attachments preserved as separate ContentDocument records. The original note date and author are preserved as custom fields if the NPSP or custom schema supports them.

CiviMail mailing records include subject, body HTML, recipient groups, and delivery statistics. Mailings are tightly coupled to the mailing infrastructure (SMTP configuration, SPF/DKIM domain authentication) and cannot be extracted independently. We do not migrate CiviMail mailing records. We deliver a written inventory of every CiviMail mailing with its subject, recipient group count, send date, and open rate for the customer's admin to use as reference when rebuilding email templates and audience segments in the destination marketing platform.