Migrate from OplaCRM to Salesforce Sales Cloud

OplaCRM Accounts map directly to Salesforce Account. The Account Name, external_id, and address compound fields migrate 1:1. We preserve the OplaCRM healthscore as a custom numeric field (opla_healthscore__c) on Account since Salesforce has no native equivalent. Joint or co-selling relationships held in OplaCRM's opportunities_joint_id field are resolved here as well—each joint deal gets a custom lookup property (opla_linked_opportunity__c) pointing to the related Opportunity if the destination org does not support native linked opportunities.

OplaCRM Contacts map to Salesforce Contact with email as the deduplication key. The contact-to-account link resolves via Account external_id matching. Role fields on OplaCRM Contacts map to Salesforce Contact Role on the Opportunity if the customer uses that association pattern. Custom Field key-value pairs on Contacts migrate as typed Salesforce custom fields; any naming collision is prefixed with opla_ and surfaced in the pre-flight mapping table for the customer to rename before final load.

OplaCRM Opportunities map to Salesforce Opportunity by external_id with stage, close date, close reason, and win/loss status preserved. The sale_process_stage string enum maps to the Salesforce StageName in the target Sales Process. We resolve the opportunities_joint_id UUID into the opla_linked_opportunity__c custom lookup if native linked opportunities are not available in the destination org. Closed-Won and Closed-Loss terminal stages land in the correct bucket based on display label matching rather than internal enum ordinals.

OplaCRM Products migrate as Salesforce Product2 records with Standard Pricebook entries created at migration time. The OplaCRM product pricing model is reviewed against Salesforce's price book structure; if OplaCRM stores list price differently from the destination's price book default, we flag the discrepancy for the customer to confirm before final import. ProductCode maps from the OplaCRM sku field where present.

OplaCRM Invoices created via CreateOpportunityInvoiceDto map to Salesforce Invoice if the destination org has Invoice enabled (Salesforce Billing or Order Management). If Invoice is not provisioned in the destination, we map to a custom Invoice object with fields for invoice number, amount, date, and status. Invoice numbering schemes between OplaCRM and Salesforce may require explicit remapping; we flag this in the pre-flight review and preserve the OplaCRM invoice number in a custom field if Salesforce's auto-numbering is enabled.

OplaCRM CustomFieldValueDto key-value pairs migrate as typed Salesforce custom fields. We create the custom field schema in Salesforce before migration, using type inference from the value data (string, number, boolean, date) to assign the correct field type. Name collisions with existing Salesforce fields are prefixed with opla_ and listed in the pre-flight mapping table. The customer reviews and renames or merges these before final cutover. All key-value pairs are preserved so no OplaCRM data is lost even if the naming decision is deferred.

OplaCRM stage names stored in sale_process_stage map to Salesforce StageName values within a Sales Process that we configure during schema design. Each OplaCRM pipeline maps to a Salesforce Record Type on Opportunity, with a corresponding Sales Process that whitelists the correct stage values. Stage probability percentages migrate from OplaCRM to Salesforce StageProbability, rounded to integer values.

OplaCRM's opportunities_joint_id UUID field links co-selling or joint opportunities. We resolve each UUID to an explicit Opportunity record during migration. If the destination Salesforce org supports native linked opportunities (Opportunity Partner or Opportunity Competitor object), we write the relationship natively. Otherwise, we create a custom lookup field (opla_linked_opportunity__c) on Opportunity and surface the full joint-opportunity mapping in the post-migration handoff so the customer's admin can decide whether to use Salesforce's native linked-opportunity pattern.

OplaCRM's locked boolean flag prevents edits on every record type. We replicate this as a restricted-permission flag in Salesforce: records with locked=true are assigned to a permission set that revokes Edit and Delete access at migration time. If the destination org does not support this pattern, we write opla_locked__c as a custom boolean and flag it in the post-migration handoff for the customer to implement a Salesforce Flow or permission-set-based restriction post-cutover.

OplaCRM Users map to Salesforce User records by email address match. Owner assignments on Opportunities, Contacts, and Accounts resolve via this User mapping. Any OplaCRM Owner without a matching Salesforce User goes into a reconciliation queue; the customer's Salesforce admin provisions the missing User before record import resumes. Owner role and permission-level data from OplaCRM does not migrate; Salesforce permission sets and roles are configured post-migration.

OplaCRM tags stored as label arrays on records migrate to Salesforce multi-select picklist fields on the corresponding object. Comma-delimited tag strings are split into individual entries. The customer chooses during scoping whether tags map to multi-select picklist fields (immediate filterability in Salesforce) or Salesforce Topics (cross-object taxonomy).

OplaCRM attachments referenced by URL or file ID are downloaded and re-uploaded to Salesforce's ContentDocument library via ContentVersion insert. The ContentDocumentLink associates the file with the parent record (Account, Contact, Opportunity). Large binary attachments may require extended migration windows and are flagged in the pre-flight volume assessment. Files over 25 MB require chunked upload handling.