Migrate from Soffront to Salesforce Sales Cloud

Soffront Contacts represent both unqualified prospects and qualified buyers in a single object with lifecycle stage tracked via custom properties. We define the split rule during discovery: contacts with prospect-type lifecycle values map to Salesforce Lead; contacts with customer-type lifecycle values map to Salesforce Contact linked to an Account. The original Soffront lifecycle stage property migrates to a custom field hs_original_lifecycle__c on both Lead and Contact for historical audit. Any Group assignments on Contact migrate to Salesforce Group membership or a custom sharing field.

Soffront Accounts map directly to Salesforce Account. Account-Contact relationships are preserved via the AccountId lookup on Contact after Account is created first in the dependency chain. Industry, size, and custom properties map to typed Salesforce fields. The Account Name becomes the Name field and is used as the dedupe key during import.

Soffront Deals map to Salesforce Opportunity. The custom pipeline stages in Soffront map to Salesforce StageName, and each Soffront pipeline maps to a Salesforce Record Type with a corresponding Sales Process that whitelists the relevant stage values. Deal amount, close date, owner, and custom fields migrate directly. Stage probability percentages transfer from Soffront to Salesforce StageProbability, rounded to the nearest integer.

Soffront Activities link to Contacts or Deals. Call activities map to Salesforce Task with TaskSubtype=Call and CallDurationInSeconds preserved. Email activities map to Salesforce EmailMessage records linked to Tasks. Meeting activities map to Salesforce Event with StartDateTime, EndDateTime, and Location preserved. Tasks map directly to Salesforce Task with Status, Priority, and ActivityDate. Activity timestamps preserve the original Soffront created date for historical timeline ordering.

Soffront Tickets migrate to Salesforce Case if the destination org includes Service Cloud. Ticket status, priority, assignee, and conversation history migrate as Case Status, Priority, Owner, and EmailMessage records linked to the Case. Ticket type from Soffront maps to Case Record Type or a custom ticket_type__c field depending on the destination org's configuration.

Soffront Projects include status, milestones, assigned managers, resources, and due dates. Salesforce does not have a native Project object in Sales Cloud; projects migrate to a custom Project__c object that we provision in the destination org before import, including all custom fields for status, milestone, manager, resource, and due date. The customer chooses whether to use a custom object or the Project Management app from the AppExchange during scoping.

Soffront Knowledge Base articles store solutions by category and link to ticket types. We export articles with their category assignments, create the equivalent category structure in Salesforce Knowledge (Data Category Groups and Categories) before article import, then import articles linked to the matching categories. If the destination uses a flat KB structure, articles map to existing categories or new ones are created. Article body, title, and url_name migrate directly.

Soffront supports custom object types beyond the standard data model. We inspect the custom object schema at the start of each migration and provision equivalent custom objects in Salesforce with __c API names. All custom fields, data types, picklist values, and lookup relationships are pre-created in the destination sandbox before any data moves. Schema validation happens in sandbox before production migration.

Soffront's customization-first design means two organizations on the same platform may have entirely different custom field names and picklist values for the same object. We perform a field inventory during discovery that pairs each source custom field name to its destination equivalent, including data type mapping (text to text, number to number, picklist to picklist). Picklist values undergo a separate value-mapping exercise to align with the destination picklist options.

Soffront Groups organize records for access control and segmentation. We map group memberships to Salesforce Groups and replicate group-based permissions using the destination's sharing model. If the customer's Soffront groups map to territory or team structures, we create equivalent Group records and assign Account and Contact sharing rules during the migration. Group membership is preserved as a custom field if a Salesforce-native sharing model does not apply.

Attachments linked to Contacts, Deals, Tickets, and Projects are exported from Soffront and re-uploaded to Salesforce as ContentDocument (Salesforce Files) or Attachment records depending on the destination org's file storage strategy. File size limits are respected during extraction. ContentDocumentLink records are created to attach files to the parent record (Contact, Opportunity, Case, or custom Project object). File metadata (name, created date, owner) is preserved.

Soffront workflows are anchored to a Main Object and generate dependent Tasks with IF-THEN-ELSE conditions. We export workflow definitions as structured records during discovery, documenting the trigger object, conditions, actions (field updates, email alerts, task generation), and sequence. This export becomes the handoff document for the customer's Salesforce admin to rebuild in Flow. Workflow recreation is not a 1:1 import because Salesforce Flow uses a different action model and trigger architecture than Soffront's Main Object workflow engine.