Migrate from OplaCRM to Twenty CRM

OplaCRM Accounts map directly to Twenty CRM Companies. The Account name maps to Company name; address fields map to the standard address compound in Twenty. We use the OplaCRM external_id as a reference field during import for deduplication. If OplaCRM Accounts have no external_id, we generate a deterministic hash from the account name and address for matching.

OplaCRM Contacts map to Twenty CRM Person records. We deduplicate by email address and resolve the contact-to-account link by matching the OplaCRM account external_id to the Twenty Company record created in the preceding phase. Role fields map to a custom text field in Twenty if no native role equivalent exists on Person.

OplaCRM Opportunities map to Twenty Opportunities. The sale_process_stage field (stored as a string enum) maps by display label rather than internal enum to ensure CLOSE_WON and CLOSE_LOST land in the correct terminal stage in Twenty. Close date, close reason, and win/loss status migrate directly. Stage probability percentages do not transfer automatically — we surface the original stage probabilities in a custom field so the customer can configure Twenty stage probabilities post-migration.

OplaCRM Products map to Twenty Products. Product name and SKU migrate directly; pricing is reviewed during scoping because OplaCRM's list-price model may differ from Twenty's price book structure. We create Standard Price Book entries in Twenty during the product phase if the source includes pricing data.

OplaCRM Invoices (created via CreateOpportunityInvoiceDto) map to a custom Invoice object in Twenty CRM. We map invoice amount, date, and status. Invoice numbering schemes do not auto-sync between systems — we prefix migrated invoice numbers with 'opla_' during import and flag a remapping step in the pre-flight review so the customer's admin can assign the correct numbering prefix before go-live.

The OplaCRM healthscore is a composite numeric value per account with no documented algorithm. We preserve the current value as a custom numeric field on the Twenty Company record (e.g., opla_healthscore__c). Teams should treat this as a reference metric — the underlying signal components (activity frequency, engagement signals, deal velocity) do not migrate because they are behavioral inputs, not stored values. A separate scoping session covers whether to rebuild healthscore logic as a calculated field in Twenty.

OplaCRM links joint or co-selling Opportunities using a UUID field (opportunities_joint_id) that is not a standard linked-opportunity pattern. We resolve each UUID by querying the related Opportunity record in OplaCRM's export, then write an explicit linked-opportunity relationship in Twenty if the destination version supports it natively. If the destination Twenty instance does not yet expose a linked-opportunities UI, we create a custom text field (opla_joint_opportunity_id__c) on each linked Opportunity and surface the full mapping table in the post-migration handoff for manual relationship recreation.

The 'locked' boolean on OplaCRM records prevents editing in the source system. We replicate this flag as a custom boolean field (opla_locked__c) on the relevant Twenty object. Twenty's field-level permissions (introduced in version 1.4.0) allow the admin to restrict edit access on records where this flag is true. We flag locked records in the pre-flight reconciliation report so the customer can review before the permission is applied.

OplaCRM Custom Fields are stored as CustomFieldValueDto key-value pairs per record. We preserve all pairs as custom fields in Twenty. Field names that collide with existing Twenty properties are prefixed with 'opla_' and surfaced in the mapping table for the customer to rename before final cutover. Custom field types map to their nearest Twenty equivalents: text fields, numbers, dates, and checkboxes map directly; multi-select values split into individual entries or map to a Twenty multi-select field if available.

OplaCRM Tags stored as label arrays on records migrate to Twenty Tags. Comma-delimited tag strings in custom fields are split into individual tag entries during transform. Tags that cannot be represented as Twenty native tags are written to a custom text field (opla_tags__c) on the parent object.

OplaCRM Users (owners) map to Twenty Workspace User records by email address match. Any OplaCRM Owner without a matching email in the Twenty workspace is held in a reconciliation queue for the customer's admin to provision before record import resumes. Owner assignments on Opportunities and Contacts resolve through this User mapping.