Migrate from BSI CRM to Salesforce Sales Cloud

BSI CRM stores individual contact records with standard fields (name, email, phone, title) and custom classification properties. We evaluate each BSI Contact against your defined qualification criteria — prospects below the sales-qualified threshold map to Salesforce Lead, and qualified contacts map to Salesforce Contact attached to an Account. The BSI contact role and any custom classification fields migrate to custom fields on both Lead and Contact for audit continuity. If your BSI configuration does not include an explicit qualification flag, we apply the split rule agreed during scoping and document every record placed in each bucket.

BSI Company records map directly to Salesforce Account. BSI's hierarchical company structures — parent-child relationships between companies — map to Salesforce Account hierarchies using the ParentId field. Industry classification fields from BSI migrate to a custom Industry subcategory field or the standard Account Industry picklist depending on the value set. The Company record must import before any Contact records to satisfy the AccountId Lookup on Contact.

BSI Deal records carry pipeline stage, deal value, owner assignment, expected close date, and any custom fields. Pipeline stages require explicit mapping because BSI's stage names and counts vary by industry module configuration. We pre-configure Salesforce Opportunity stages with corresponding probability percentages before migration and map the BSI deal stage to the matching Salesforce StageName. Closed-won and closed-lost dates migrate; any deal notes migrate as Opportunity Notes or as a custom long-text field.

Each distinct BSI deal pipeline becomes a Salesforce Opportunity Record Type with a corresponding Sales Process that scopes available stage values to that pipeline. This prevents a deal from accidentally moving to a stage belonging to a different business line. We create Page Layout assignments per Record Type during schema design so that field visibility aligns with sales team responsibilities.

BSI logged calls map to Salesforce Task with TaskSubtype set to Call. Call duration, disposition, and any notes migrate to custom Task fields. The WhoId on Task points to the migrated Contact or Lead; the WhatId points to the related Account or Opportunity. ActivityDate preserves the original BSI call timestamp so that timeline ordering is maintained after cutover.

BSI email engagements migrate to Salesforce EmailMessage records (the content and headers) linked to a Task record (the activity timeline entry). The WhoId on Task points to the migrated Contact or Lead. BSI's email direction flag (sent vs received) maps to Salesforce EmailMessage direction. Any email attachments migrate as ContentDocument records linked via ContentDocumentLink.

BSI meeting records map to Salesforce Event with StartDateTime, EndDateTime, and Location preserved. Attendee mapping creates EventRelation records pointing to the relevant Contact, Lead, and User records. Subject and description migrate as-is; recurring meeting series are not automatically reconstructed and are flagged for manual scheduling post-migration.

BSI task engagements map to Salesforce Task with Status, Priority, and ActivityDate preserved. Task assignment migrates by resolving the BSI owner reference to the Salesforce OwnerId via the User mapping. Open and completed status migrate directly; any task completion notes become the Task Description.

BSI CRM supports custom objects and fields within its modular architecture, but the schema is not publicly documented in a way that allows automated introspection. We perform a pre-migration discovery phase to enumerate all custom object names, field definitions, data types, and record counts. We then pre-create the equivalent Salesforce custom objects with matching API names (suffix __c), typed custom fields, and Lookup or Master-Detail relationships to parent objects before any data is loaded. Without this step, custom field data is the most common source of silent data loss in BSI CRM migrations.

User and Owner records are migrated first in the load sequence because all other objects reference them as foreign keys. We match BSI users to Salesforce Users by email address. Any BSI user without a matching Salesforce User goes to a reconciliation queue for your admin to provision before record import resumes. Role and permission sets are not migrated as configuration; we document the role assignments for manual rebuild in Salesforce Profiles and Permission Sets.

BSI CRM tagging and custom classification fields may not have direct Salesforce equivalents. We capture these as Salesforce multi-select picklist fields on the relevant object, or as Salesforce Topics with TopicAssignment records if the classification is cross-object. The customer selects the preferred strategy during scoping based on how the tagging data is consumed in reporting.

File attachments associated with Contacts, Deals, or Activities are exported individually and linked back to their parent record in Salesforce via ContentDocumentLink. BSI's file storage structure varies by configuration, so we enumerate all file attachment records during discovery and confirm that each file can be extracted before committing them to the migration plan. Files without a resolvable parent record are flagged for manual re-association post-migration.