Migrate from Opera 3 to Twenty CRM

Opera 3's built-in CRM Contact records export via CSV with name, email, phone, address, and account link. We map these to Twenty People records using the display name, primary email, and phone fields. Opera 3's CRM Contact to Company link maps to the Twenty People.organizationId relationship resolved after Company import. If Opera 3 stores contact role or type in a separate field, we map it to a custom field on People or to the Twenty workInformation block.

Opera 3's CRM company records export as a separate CSV from the Sales Ledger accounts. We map company name, address, website, industry, and employee count to Twenty Company fields. The Opera 3 account code becomes a reference field we preserve in a custom field for audit. Companies are imported before People so that the organizationId lookup is satisfied at the moment of People insert.

Opera 3 stores CRM activities as free-text notes without structured event type, date, or duration fields. We parse each activity note for date mentions, action verbs (call, email, meeting), and outcome keywords, then map qualifying entries to Twenty Task records (for action items with a due date or status) or Note records (for contextual history). Date-stamped activity notes migrate with the parsed date; undated notes migrate with the record creation timestamp. This transformation is the most technically significant step in the migration because Opera 3 does not enforce activity structure.

Opera 3 Sales Ledger accounts can represent organisations or sole traders with individual contact details stored in the same record. We analyse each account for organisation name, individual name, and contact fields to determine whether it maps to a Twenty Company, a Twenty People record, or both. Accounts flagged as individual (sole trader) map to People; accounts with a company name and multiple contacts map to a Company with linked People records. Payment terms, credit limits, and multi-currency settings from Opera 3 are preserved as custom fields on the target record.

Opera 3 Sales Order headers and line items export via CSV with order number, customer reference, order date, status, and totals. We map these to Twenty Opportunity records with the order total mapped to the Opportunity amount field, order date mapped to Opportunity createdAt, and status mapped to an Opportunity stage custom field. Line items map to Opportunity line items if Twenty's Opportunity supports product associations, or are preserved as Note records attached to the Opportunity.

Opera 3 stock codes, descriptions, unit prices, and reorder levels export via the stock CSV. We map stock code to Product code, description to display name, and standard selling price to the standard price field. Customer-specific product variants from the OPUS add-on (stored in a separate CSV with base stock code and customer reference) map to Product variants or are preserved as custom Product records with a customer association field. We flag OPUS variant records for manual review if the variant mapping requires price-list entry creation in Twenty.

Opera 3 employees export via the HR/Payroll CSV with name, address, bank details, start date, and P45 data. We map employees flagged as sales or CRM users to Twenty People records (with a team membership field to identify them as internal staff rather than external contacts). Non-CRM employees are archived as an output file rather than loaded into Twenty. RTI FPS and EPS XML files are not processed as CRM data; they remain in the HR/payroll scope for a dedicated payroll system migration if required.

The OPUS add-on stores customer-specific stock code variants outside the main product schema. Each OPUS record contains a base stock code, a customer account reference, and a customer-specific description and price. We join OPUS records to the main product export using the base stock code, then map each variant to a Twenty Product record with a custom customer association field or to a Custom Object (if the customer's variant model is complex). The customer chooses the strategy during scoping based on how they use the variant data.

Opera 3 stores PDF invoices, statements, and remittance advices as binary files in document folders, with filenames containing the invoice or account reference. We extract the PDF, parse the reference, and attach it to the corresponding Twenty Company or Opportunity record as a Note with a file attachment. PDF filenames that do not match a migrated record are flagged in a separate reconciliation list for manual assignment.

Opera 3 supports multiple company codes under one installation with inter-company transactions stored as standard invoices with a counterparty code. We extract each company as a separate Opera 3 company entity, map each to a Twenty Company record, and set a custom field for the source company code and inter-company flag. Inter-company debtor and creditor balances are preserved as Notes on the relevant Company records for the customer's finance team to reconcile in their accounting platform.

Custom fields added via the OPUS add-on or bespoke modifications to the Visual FoxPro schema are not standardised and vary by installation. We do not automatically migrate bespoke fields. During discovery we document every named custom field found in the Opera 3 schema, classify each as either a standard field mapping (if the data type is compatible with a Twenty standard field) or a custom field (mapped to a Twenty custom field on the relevant object or to a Custom Object). The customer reviews the inventory and approves which custom fields enter the migration scope.