Migrate from BoldTrail BackOffice to Salesforce Sales Cloud

BoldTrail contacts split by status: active transaction contacts land as Salesforce Contacts linked to an Account. Prospects without a closed transaction may route to Salesforce Lead based on last_activity_date. This split happens during migration so each record lands on the correct Salesforce object.

Each BoldTrail transaction maps to one Salesforce Opportunity. The BoldTrail transaction ID is stored as Opportunity.Transaction_ID__c (external ID) for traceability and delta-run de-duplication. Transaction stage maps to Opportunity StageName via a value-mapping pass per pipeline. Listing and selling commission amounts transfer to custom currency fields on the Opportunity record for reporting continuity.

BoldTrail transaction line items (listing side, selling side, split amounts) map to Salesforce Opportunity Products. Each product carries price, quantity, and a custom fee_type__c field distinguishing commission types. Requires PricebookEntry creation before Opportunity Products insert. The commission split values also populate custom fields on the Opportunity for visibility.

BoldTrail agents are matched to Salesforce Users by email address — resolved before migration so OwnerId fields populate correctly on Opportunities. Unmatched agents are flagged and assigned to a fallback OwnerId. Agent profile data (license number, hire date) migrates to a custom Agent_Profile__c object linked to the User record.

BoldTrail commission plans have no native Salesforce equivalent. We create a Commission_Plan__c custom object with fields for plan_name__c, agent_tier__c, split_percentage__c, and trigger_condition__c. Plans attach to Opportunities via a lookup relationship. Salesforce CPQ can override these with approval workflows if your brokerage uses CPQ for quote-to-contract.

BoldTrail accounting entries (chart of accounts, debits/credits, ACH disbursement records) have no Salesforce equivalent. We preserve them as custom Financial_Record__c entries for historical reference. Reconciliation against QuickBooks or your ERP post-migration is a separate step — Salesforce is not an accounting system.

The BoldTrail brokerage entity maps to a Salesforce Account record — typically the root-level Account representing the brokerage itself. Branch offices and teams become Salesforce Account records under a parent Account hierarchy if your Salesforce org uses Account hierarchies. The mapping preserves the organizational structure across the migration.

BoldTrail property data merges into an Account record (using a custom Account record type Property) plus a custom Property__c object for listing-specific fields (MLS number, property type, list price). This prevents property records from polluting your Salesforce contact-account model and keeps listing data organized in its own object structure.

BoldTrail transaction documents (contracts, disclosure forms, eSignature logs) migrate to Salesforce Files (ContentVersion/ContentDocument). Each document links to its parent Opportunity via ContentDocumentLink. BoldTrail eSignature metadata (signer, timestamp, status) maps to a custom Signature_Log__c field on the document record for audit trail purposes.

BoldTrail agent onboarding checklists are proprietary workflow constructs with no Salesforce native equivalent. We export checklist definitions as JSON. Your Salesforce admin can rebuild these as Salesforce Flow with task assignments to the agent's User record, or use a third-party onboarding app from AppExchange.

BoldTrail's QuickBooks sync configuration (chart of accounts mapping, sync direction, frequency) does not migrate directly to Salesforce. Since Salesforce lacks a native QuickBooks connector, your team must establish a new integration via MuleSoft Composer, the native QuickBooks connector, or an AppExchange solution. We export the BoldTrail mapping configuration as a reference document for your integration team to use during setup.

BoldTrail transaction pipelines map to Salesforce Sales Processes keyed by Record Type. Each BoldTrail pipeline stage becomes an Opportunity StageName value with its own probability and forecast category. Stage-transition timestamps are preserved as custom datetime fields on the Opportunity for historical stage-entry reporting.