Migrate from Bright to Salesforce Sales Cloud

Direct map. Salesforce requires AccountId for most Contact records — Bright contacts without a primary company land in Salesforce as standalone Contacts attached to a default 'Unassigned Account' placeholder. We flag any Bright contacts without a company link before migration so your admin can make routing decisions.

Bright lifecycle-stage values that indicate an unqualified or early-stage contact route to Salesforce Lead. Values indicating a converted or active customer (e.g., lifecycle_stage = active, customer) route to Salesforce Contact. The split is applied at migration time based on the source lifecycle value — we surface the routing rule in the mapping plan before the first record loads.

Direct map. Bright company hierarchies (parent/child) translate to Salesforce ParentId on Account. Multi-company contacts in Bright (N:N relationship) collapse to one primary AccountId plus Account Contact Relations in Salesforce — we use the most-recently-modified company as the primary unless you specify a different rule.

Direct map. Bright deal pipelines become Salesforce Sales Processes keyed by RecordTypeId. Each Bright pipeline requires a corresponding Salesforce Record Type so stage pick-list values are scoped correctly — teams with four Bright pipelines end up with four Salesforce Record Types, each with its own page layout and stage values.

A Bright pipeline has no single Salesforce equivalent — it splits into a Sales Process (which governs stage-label naming conventions) and a Record Type (which scopes available stage pick-list values per deal type). We deliver a pipeline-to-RecordType mapping table as part of the migration plan so your Salesforce admin can pre-create the schema before data lands.

Stage names map value-by-value per Record Type — each pipeline stage from Bright becomes a distinct Opportunity StageName value in Salesforce. Probability and forecast category are re-applied based on Salesforce's stage-metrics model. Stage-entered timestamps from Bright are preserved as custom datetime fields (Stage_Entered__c) for reporting continuity.

Salesforce has no native lifecycle_stage equivalent. Bright's lifecycle values migrate as a custom pick-list field (Lifecycle_Stage__c) on both Contact and Lead. Stage-change timestamps migrate as Lifecycle_Stage_Updated__c custom datetime fields. The pick-list values are defined in the migration plan so your admin can create them in Salesforce Setup before the first record loads.

Bright calls and emails map to Salesforce Tasks with Type set to 'Call' or 'Email' respectively. Meetings map to Salesforce Events with original start/end times and owner assignments preserved. Notes map to Salesforce Notes (enhanced format). Original timestamps and owner assignments carry over so activity history in Salesforce reflects the complete record from Bright.

Bright custom objects migrate 1:1 to Salesforce custom objects. Custom object names get the __c suffix in Salesforce. Any Bright custom-object associations that use an N:N model need Salesforce junction objects — we identify these in the pre-migration audit and include junction-object creation in the schema plan.

Bright workflows and automations do not have a Salesforce equivalent that migrates automatically. We export Bright workflow definitions as structured JSON and plain-text documentation so your Salesforce admin can rebuild them in Flow or Process Builder. This is explicitly scoped outside the data migration and priced separately as an advisory service.

Bright file attachments on records re-upload to Salesforce Files. Salesforce's default per-file size limit is 25MB — files exceeding this threshold are flagged for manual handling. Inline images embedded in Bright notes are extracted, downloaded, and re-hosted as Salesforce Files linked to the parent record.