Migrate from SwiftCRM to Salesforce Sales Cloud

SwiftCRM's single client record has no explicit Lead-Contact equivalent in Salesforce. We design a split rule during discovery using SwiftCRM's relationship type and lifecycle indicators: clients flagged as prospects map to Salesforce Lead; active clients with historical appointments map to Salesforce Contact tied to an Account. The original SwiftCRM contact identifier is preserved in an external ID field swiftcrm_id__c on both Lead and Contact for reconciliation. Relationship metadata (family, business) migrates as custom Contact fields or relationship custom objects per the destination schema design.

SwiftCRM Appointments with client links, reminder timestamps, and notification context map to Salesforce Event records. StartDateTime and EndDateTime migrate directly. The WhoId on Event is resolved to the migrated Lead or Contact ID. Reminder flags and notification text migrate to Salesforce Task reminders linked to the Event via TaskWhatId, preserving the SwiftCRM-native notification context as Salesforce-native reminders. Location and description fields transfer directly.

SwiftCRM Reminders tied to clients or appointments map to Salesforce Task records. The reminder timestamp becomes the Task ActivityDate, and the reminder text becomes the Task Subject. We set TaskStatus to Completed for migrated past-due reminders and to Not Started for future reminders. OwnerId is resolved by matching the associated SwiftCRM user to the provisioned Salesforce User. SwiftCRM's notification context (push notification vs email) is preserved as a custom Task field.

SwiftCRM E-Docs export as files and migrate to Salesforce ContentDocument linked via ContentDocumentLink to the parent Contact or Account record. We extract files in their original format, create Salesforce ContentVersion records for the binary, and establish the ContentDocumentLink with a LinkedEntityId pointing to the migrated Contact or Account. File naming conventions from SwiftCRM are preserved in the ContentVersion Title field. File metadata (creation date, size) migrates to ContentVersion fields.

SwiftCRM notification history tied to client interactions migrates as Salesforce Task records with a custom notification_type__c field set to 'SwiftCRM Notification'. The notification text becomes the Task Subject, and the timestamp becomes ActivityDate. For richer notification threads, we create Salesforce Note records with the notification content in the Body field, linked via ContentDocumentLink to the parent Contact. Notification status (read/unread) is preserved as a custom Task field swiftcrm_notification_status__c.

SwiftCRM tracks family and business relationship structures between contacts. We map these to Salesforce Contact Relation records (from the Relationships feature available in Sales Cloud) or to custom Contact fields on the relationship metadata as a picklist. The relationship directionality (SwiftCRM supports asymmetric relationship types) is preserved in a custom field relationship_direction__c. During discovery we confirm whether the destination org has the Relationships feature enabled and choose the appropriate mapping target.

SwiftCRM user accounts map to Salesforce User records. We resolve by email match against the destination Salesforce org's User table. Users without a matching Salesforce User are placed in a reconciliation queue for the customer's admin to provision before the migration runs. Active/inactive status and basic role assignments from SwiftCRM map to Salesforce Role and Profile during provisioning. We do not migrate SwiftCRM permission structures as Salesforce Permission Sets; these are rebuilt in Salesforce by the admin post-migration.

SwiftCRM beta-stage custom fields vary by account tier. We audit all available custom fields during scoping, confirm tier-gated availability directly with SwiftCRM, and map each to a typed Salesforce custom field. Picklist fields migrate to Salesforce Picklist or Multi-Select Picklist. Date fields map to Date or DateTime. Boolean flags map to Checkbox. Custom fields that reference SwiftCRM-specific values without Salesforce equivalents are mapped to Text fields with a migration note in the field description. Salesforce custom fields are pre-created via metadata API before the production migration phase begins.

Beta-stage custom objects in SwiftCRM may be limited or tier-gated. We audit available custom object definitions during scoping and map each to a Salesforce custom object with a matching __c API name. Lookup relationships to Contacts or Accounts are pre-created in Salesforce before migration so that the foreign key references are valid at insert time. Custom object availability is confirmed with SwiftCRM directly during scoping; schema instability due to beta status may affect custom object count and field structure, and we re-validate schema within 30 days of cutover.

SwiftCRM does not have a separate Account or Company object; client records are singular Contact-centric. When migrating to Salesforce, we create Account records for every Contact that represents a business entity. Personal contacts without a company association are mapped to a Household Account or Personal Account type depending on the destination org's account model. Company name fields from SwiftCRM custom fields become Account Name; sole-contact records receive a generated Account Name using the Contact's full name plus a suffix.

SwiftCRM's Face ID protection for client records is a SwiftCRM-specific security mechanism. We cannot replicate Face ID authentication in Salesforce. We create a custom field swiftcrm_faceid_enabled__c (Checkbox) on the Contact record to preserve the metadata indicating which records had Face ID protection enabled in SwiftCRM. Salesforce's own field-level security and sharing rules govern access in the destination org.

All SwiftCRM Appointments, Reminders, and Notifications carry original creation timestamps. We preserve these as ActivityDate on Tasks and CreatedDate on Events to maintain the chronological timeline in Salesforce. Historical timestamps are set at insert time using the Bulk API; this requires disabling Salesforce's default CreatedDate assignment or setting CreatedDate via the API with the appropriate permission. The original SwiftCRM timestamps are also preserved in a custom field swiftcrm_created_date__c for audit purposes.