Migrate from Opal CRM to Twenty CRM

Opal CRM Leads are the primary record for field-sales prospects captured from forms, campaigns, and manual entry. They map directly to Twenty's Person object, preserving contact fields (name, phone, email, address) and any source attribution. If Opal Lead records include point-based performance data (a feature in the Basic plan), we carry it to a custom number field in Twenty rather than discarding it.

Opal CRM team members with roles (Sales Rep, Manager, Admin) migrate as Twenty Workspace Members. Role permissions in Opal (role-based access tiers) do not export as structured data, so we capture the role assignment per user and document the mapping so the customer's Twenty admin can configure equivalent access levels in Twenty's workspace settings during setup.

Opal CRM Tour Plans store itinerary data (dates, locations, assigned rep) plus expense line items. If Opal exports Tour Plans as a flat record, we decompress the expense entries from any available structured export and reconstruct them as individual TourPlanExpense records linked to the parent TourPlan. Twenty does not have a native Tour or Visit object, so we pre-create a custom object schema in Twenty via the Settings UI and the metadata API before migration.

Opal CRM Quotations are financial sales-closure records with line items and workflow approval state. They map to Twenty Opportunities, with Quotation header fields (total amount, status, dates) as Opportunity fields and line items as related OpportunityLineItem-equivalent records in Twenty's custom object structure. The approval workflow state from Opal is a platform-specific field with no direct Twenty equivalent; we preserve it as a custom picklist field workflow_state__c and document it in the handover notes.

Opal CRM tracks lead progress through pipeline stages tied to its lead engagement workflow. Stage names and order are preserved as a custom picklist field (pipeline_stage__c) on the migrated Person record, and the customer configures matching stage values in Twenty's pipeline view settings post-migration. We do not assume a fixed number of stages; we extract the actual stage set from the source data during discovery.

Opal CRM interaction logs (calls, emails, meetings) attached to Leads migrate as Twenty Task records with a custom activity_type__c field (call, email, meeting) and ActivityDate set to the original Opal timestamp. If the interaction has notes or a disposition, these land in the Task body and the customer configures Twenty's timeline view to surface the relevant fields per activity type.

Opal CRM supports custom fields on Leads, but the custom field schema is not publicly documented. We identify custom fields during discovery by inspecting the Opal export file, infer field types (text, number, date, picklist, checkbox), and pre-create matching custom fields in Twenty via the settings UI before migration. Any custom field that cannot be typed from the export lands as a text field with a flag for the admin to re-type post-migration.

Opal CRM captures leads from website forms, offline events, marketing campaigns, and manual entry. We preserve the source attribution as a custom lead_source__c field on the Person record so the customer's sales team can report on pipeline origin in Twenty without rebuilding the source-tracking logic.

Opal CRM's Basic plan includes sales performance tracking using a point/rewards system. This does not have a standard CRM equivalent in Twenty. We migrate any visible point totals or reward flags as custom number fields on the Person (for lead-level scores) or WorkspaceMember (for rep-level performance) and document the field in handover notes so the admin can configure reporting or remove it if the tracking model changes.

Opal CRM role assignments (Admin, Manager, Sales Rep) are attached to team member records but do not export as structured permission data. We list every user's assigned role during discovery and produce a role-mapping table that the Twenty admin uses to configure workspace-level access in Twenty's member settings post-migration. We do not set permissions programmatically because Twenty's permission model operates at the workspace and object level rather than role-based groups.