Migrate from openCRX to Salesforce Sales Cloud

openCRX LegalEntity records (companies, organisations, and any Account with business-entity semantics) map directly to Salesforce Account. We use the LegalEntity's primary PostalAddress as the Billing Address, the primary PhoneNumber as Phone, and the LegalEntity name as Account Name. Account Type is set to Customer - Direct or Customer - Channel based on the customer's openCRX segment configuration. Dedupe is performed on Account Name and Website domain.

openCRX Contact records (individuals) map to Salesforce Contact. Each Contact is linked to its parent LegalEntity Account via the AccountId lookup. Primary PostalAddress migrates to Contact MailingAddress, primary PhoneNumber to Phone, and primary EmailAddress to Email. The Contact's full name fields are parsed from the openCRX FullName attribute.

openCRX Opportunities inherit from the abstract contract class and represent sales pipeline entries. We map openCRX contract status (requested, submitted, won, lost) to Salesforce StageName values, map the estimated value to Amount, and preserve the openCRX contract rating as a custom Opportunity field. Probability percentages are mapped to Salesforce StageProbability. Owner resolution is by email match against the Salesforce User table.

openCRX Quotes inherit from the same contract hierarchy as Opportunities. We map Quote records to Salesforce Quote objects linked to the parent Opportunity, preserving quote dates, expiration dates, line-item pricing, and currency context from the openCRX contract. Quote PDFs stored in openCRX migrate as ContentDocument attached to the Quote record.

openCRX Sales Orders inherit from the contract hierarchy and represent confirmed purchase commitments. We map them to Salesforce Order records, with the status field (pending, approved, in progress, completed, cancelled) mapping to Salesforce Status values. Order products map to OrderProductRecords. The parent Account and Opportunity are resolved at migration time through lookup resolution.

openCRX Invoices are the terminal contract objects in the sales cycle. If the destination org has Salesforce Billing enabled, we map invoices directly. Otherwise, invoices migrate as custom Invoice__c records with the invoice number, date, line items, and payment status preserved. Payment status, invoice total, and currency are retained as structured fields.

openCRX contract positions (line items on Opportunities, Quotes, Sales Orders, and Invoices) are modelled as abstract contract position subclasses. We map each position to Salesforce OpportunityLineItem when the parent is an Opportunity, OrderProductRecord when the parent is an Order, and QuoteLineItem when the parent is a Quote. Quantity, unit price, and pricing rule references are preserved as custom fields if the customer's pricing logic requires it.

openCRX Products (including bundles and design-to-order scenarios) map to Salesforce Product2 records. ProductCode, Name, Description, and Family migrate directly. Standard Pricebook entries are created during migration. Bundle structures are preserved as parent-product relationships in Salesforce.

openCRX multi-currency price lists map to Salesforce PricebookEntry records. Each PricebookEntry ties a Product2 to a Pricebook2 and includes a UnitPrice in the relevant currency. If the customer uses multiple currencies in openCRX, we create multiple PricebookEntry records per product, one per currency, or a single pricebook with custom currency fields.

openCRX Activity Trackers group related Activities. Individual Activities within a Tracker are split into Salesforce Task (for calls, tasks, and notes) and Event (for meetings and calendar entries). Activity Tracker grouping is preserved as a custom field tracker_id__c on the migrated Task or Event so that related activities remain associated. Activity timestamps and duration are preserved on the Salesforce records.

openCRX Activities with activity type CALL map to Salesforce Task with TaskSubtype=Call. Activity type MEETING maps to Salesforce Event with StartDateTime and EndDateTime. Emails map to Salesforce EmailMessage records linked to a Task entry on the activity timeline. The parent Contact or LegalEntity lookup is resolved at migration time, and activity history ordering is preserved by ActivityDate.

openCRX custom fields added via DataBinding PropertySet are identified during scoping as feature definitions bound to CrxObject at runtime. We extract all active custom field definitions, map them to typed Salesforce custom fields (Text, Number, Date, Picklist, or Checkbox) on the corresponding standard or custom object, and include them in the Salesforce metadata deployment before data import begins.

openCRX binary attachments linked to Accounts, Contacts, or Opportunities are extracted via the export process (on a Linux or macOS client to avoid Windows WebDAV client quirks) and re-uploaded as Salesforce ContentVersion records. ContentDocumentLink records attach each file to the migrated parent record with the appropriate sharing setting (V - Viewer). File metadata (filename, content type, size) is preserved from the openCRX attachment record.

openCRX segments are quasi-independent sub-installations within a single deployment, each with its own data space and configuration. Multi-segment openCRX instances require a mapping strategy: either separate Salesforce orgs (for strict data isolation), Salesforce Divisions (for reporting segregation within one org), or Record Type and custom segment__c fields (for lightweight segmentation within a single org). The customer selects the strategy during scoping, and we apply it consistently across all object imports.

openCRX users and role assignments are mapped to Salesforce Users and Profiles. We extract active openCRX users, match them by email to Salesforce Users, and map openCRX role names to Salesforce Profiles or Permission Sets based on the closest functional match. Segment-scoped role assignments are mapped to Salesforce Role Hierarchy positions. Active user records are migrated; inactive users are noted for the admin to provision manually.