CRM migration
Field-level mapping, validation, and rollback between bxp software and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.
bxp software
Source
Salesforce Sales Cloud
Destination
Compatibility
6 of 12
objects map 1:1 between bxp software and Salesforce Sales Cloud.
Complexity
BStandard
Timeline
6-8 weeks
Overview
Moving from bxp software to Salesforce Sales Cloud is a migration from a bespoke, per-client instance to a standard platform schema, which means the first and most critical step is schema enumeration. Every bxp deployment is custom-built around the client's workflows, Forms, and custom fields, so there is no template we can apply without scoping the actual source instance first. We extract data through a combination of the bxp API v6 (where accessible), Form exports, and custom archive parsing of CDA and CCL format files. Contact-centre-specific data such as agent metrics, QA scores, and eLearning records require explicit mapping decisions because no standard Salesforce object receives them natively. We resolve these as structured attachments or Salesforce custom objects after the customer's admin approves the schema design. We do not migrate bxp Workflows or QA rules as code; we deliver a written inventory of every automation and evaluation template requiring rebuild in Salesforce Flow. The migration timeline ranges from six to fourteen weeks depending on archive complexity and the number of custom field objects requiring pre-creation in Salesforce.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a bxp software object lands in Salesforce Sales Cloud, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
bxp software
Forms
Salesforce Sales Cloud
Contact + Custom Objects
lossyForms are bxp's primary data containers, holding arbitrary field configurations per client instance. We enumerate every Form during scoping, identify the contact-linked fields, and map them to Salesforce Contact fields. Non-contact fields (agent metrics, custom attributes) become Salesforce custom fields or a custom object named after the source Form. The Form's own record IDs are preserved as an external ID for relationship resolution.
bxp software
Contact
Salesforce Sales Cloud
Contact
1:1BXP Contacts map directly to Salesforce Contact. Email, phone, and standard identity fields migrate 1:1. Custom fields from the associated Form schema map to Salesforce custom fields on Contact, with type mapping confirmed during enumeration (date fields to Date, numeric fields to Number, dropdowns to Picklist). OwnerId is resolved by email against the Salesforce User table.
bxp software
Activity (Call logs)
Salesforce Sales Cloud
Task (TaskSubtype = Call)
1:1BXP call activity logs migrate to Salesforce Task with TaskSubtype set to Call. Call duration, disposition, and agent ID migrate to custom Task fields. ActivityDate is set to the original BXP timestamp. Parent Contact or Form record is resolved via the BXP record identifier preserved as an external ID.
bxp software
Agent Metrics
Salesforce Sales Cloud
Custom Object (Agent_Metrics__c)
1:1Contact-centre metrics such as average handle time, wrap time, call count, and QA scores stored in BXP do not map to any standard Salesforce object. We create a custom object Agent_Metrics__c with a Lookup to Contact, pre-create all custom fields during Salesforce schema design, and import the metrics as structured records. The customer decides whether to display this in a custom Lightning component or report type.
bxp software
QA Records
Salesforce Sales Cloud
Custom Object (QA_Evaluation__c)
1:1BXP Quality Assurance evaluations tied to specific calls are bespoke per deployment. We export them alongside the associated Contact and Activity, then create a custom object QA_Evaluation__c with a Lookup to the Contact record and custom fields for each evaluation criterion. Evaluation date and score migrate as Salesforce-native Date and Number fields.
bxp software
eLearning Records
Salesforce Sales Cloud
Custom Object (Training_Record__c)
1:1BXP's eLearning module stores training completion records, scores, and module assignments. These have no Salesforce standard equivalent. We create a Training_Record__c custom object with Lookups to the Contact (as trainee) and a module custom object, preserving completion dates, scores, and status. The customer configures a related list on the Contact page layout.
bxp software
Custom Archives (CDA/CCL)
Salesforce Sales Cloud
Structured CSV or JSON (staging)
lossyBXP custom archives in CDA and CCL formats are proprietary and require parsing before loading into Salesforce. We convert CDA/CCL exports into structured CSV or JSON, then load through the Salesforce Bulk API. Any records that cannot be parsed cleanly are held in a reconciliation queue with a sample of 20 records flagged for customer review before we commit to the load.
bxp software
Custom Fields
Salesforce Sales Cloud
Custom Fields (__c)
lossyEvery custom field in the BXP instance is a mapping candidate. During scoping we enumerate all field names, data types, and associated Forms. We pre-create every Salesforce custom field (with __c suffix, matching API name, and correct field type) in a Sandbox org before any data moves. Required fields, validation rules, and picklist values are configured during this phase.
bxp software
Owner (Agent/User in BXP)
Salesforce Sales Cloud
User
1:1BXP agent and user records map to Salesforce User by email match. We extract every distinct owner reference from Contacts, Activities, and Form records and match against the destination org's User table. Missing Users go to a reconciliation queue for the customer's admin to provision before record import proceeds.
bxp software
Form Submissions
Salesforce Sales Cloud
Note or Custom Object
lossyForm submission records that contain bespoke data not attributable to a Contact become Salesforce Note records or a custom object named after the source Form. We flag these during scoping and confirm with the customer's admin which pattern applies to each Form before migration begins.
bxp software
BXP Workflows and QA Rules
Salesforce Sales Cloud
Written inventory only
lossyBXP Workflows and QA evaluation templates do not migrate as code. We document every active automation and QA rule encountered during schema enumeration, describing its trigger, conditions, and actions, and recommend a Salesforce Flow equivalent or Service Cloud QA app from the AppExchange. The customer's admin or a Salesforce partner rebuilds these post-migration.
bxp software
Historical Timestamps
Salesforce Sales Cloud
Custom fields on migrated objects
lossyWhere BXP stores created_date and last_modified_date on Form records and Activities, we preserve these as custom fields (bxp_created_date__c, bxp_modified_date__c) on the corresponding Salesforce objects. This maintains audit trail continuity and allows the customer to query historical data in Salesforce using the original timestamps.
| bxp software | Salesforce Sales Cloud | Compatibility | |
|---|---|---|---|
| Forms | Contact + Custom Objectslossy | Fully supported | |
| Contact | Contact1:1 | Fully supported | |
| Activity (Call logs) | Task (TaskSubtype = Call)1:1 | Fully supported | |
| Agent Metrics | Custom Object (Agent_Metrics__c)1:1 | Mapping required | |
| QA Records | Custom Object (QA_Evaluation__c)1:1 | Fully supported | |
| eLearning Records | Custom Object (Training_Record__c)1:1 | Mapping required | |
| Custom Archives (CDA/CCL) | Structured CSV or JSON (staging)lossy | Mapping required | |
| Custom Fields | Custom Fields (__c)lossy | Mapping required | |
| Owner (Agent/User in BXP) | User1:1 | Fully supported | |
| Form Submissions | Note or Custom Objectlossy | Fully supported | |
| BXP Workflows and QA Rules | Written inventory onlylossy | Fully supported | |
| Historical Timestamps | Custom fields on migrated objectslossy | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
bxp software gotchas
BXP has no published public API documentation
Every BXP instance has a unique data schema
No list pricing creates budget uncertainty
Small review corpus limits due diligence
Salesforce Sales Cloud gotchas
Workflow Rules and Process Builder are retired
Bulk API batch quota exhaustion during large imports
Storage overage billing is non-obvious
Account-Contact many-to-many relationship mapping
Territory and team member import ordering dependencies
Pair-specific challenges
Migration approach
Instance schema enumeration and API access assessment
We request the bxp internal API documentation PDF and access credentials. We enumerate every Form, custom field, activity log, agent metric, QA record, and eLearning record present in the source instance. Where the API is restricted, we fall back to Form exports and CDA/CCL archive extraction. The output of this step is a written Schema Inventory document listing every source object, field name, data type, and record count, plus a recommendation on API vs archive export path. This document is the foundation for the field mapping and Salesforce schema design.
CDA/CCL archive parsing and data conversion
If the migration uses CDA or CCL archive exports, we parse these proprietary formats into structured CSV or JSON. We run a sample conversion on a subset of records and present the output to the customer's admin for field-level validation before committing to a full conversion. Any fields that cannot be cleanly parsed are logged with sample raw data so the customer can confirm whether the field is still in use.
Salesforce schema design and custom object provisioning
We design the destination Salesforce schema in a Sandbox org. This includes creating all custom fields on Contact and Account (matching bxp field names and types), provisioning custom objects for Agent Metrics, QA Records, and eLearning, creating Lookups between them, and configuring Record Types if the migration involves multiple contact-centre pipelines. Validation rules and required field constraints are temporarily relaxed during migration or set with migration-context bypass logic.
Sandbox migration rehearsal and reconciliation
We run a full migration into a Salesforce Sandbox using production-like data volume. The customer's RevOps or contact-centre operations lead reconciles record counts, spot-checks 30-50 records against the source system, and signs off the field mapping before production migration begins. Any field type mismatches, picklist value gaps, or required field gaps are corrected in Sandbox. CDA/CCL parsing output is validated here before full conversion proceeds.
Production migration in dependency order
We run production migration in record-dependency order: User provisioning (validated against Salesforce User table by email), Accounts (if the bxp instance has an account-like object), Contacts (with Form fields mapped to Contact and custom fields), Activities (Tasks and Events via Bulk API 2.0), Agent Metrics and QA Records (custom objects last, with Contact Lookup resolved at insert time), eLearning Records. Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, validation, and automation rebuild handoff
We freeze bxp software writes during the final cutover window, run a delta migration for any records modified during the migration, then enable Salesforce as the system of record. We deliver the Workflow and QA Rule inventory document to the customer's admin team, with a written recommendation for each rebuild in Salesforce Flow or a Service Cloud QA app. We support a one-week hypercare window for reconciliation issues. We do not rebuild bxp automations or QA templates as Salesforce Flow inside the migration scope; that is a separate engagement.
Platform deep dives
bxp software
Source
Strengths
Weaknesses
Salesforce Sales Cloud
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 3 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across bxp software and Salesforce Sales Cloud.
Object compatibility
3 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
bxp software: Not publicly documented.
Data volume sensitivity
bxp software doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during bxp software to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.
Walk through your bxp software to Salesforce Sales Cloud migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave bxp software
Other ways to arrive at Salesforce Sales Cloud
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.