Migrate from openCRX to Twenty CRM

openCRX LegalEntity accounts (organisations) map to Twenty Companies. We extract the legal name, postal address, phone numbers, website, and industry classification. openCRX multi-segment deployments may contain duplicate legal entity names across segments; we deduplicate by legal name during scoping and document conflicts for the customer to resolve. The LegalEntity subtype flag is preserved as a custom Company field if the customer needs to distinguish organisational types.

openCRX Contact accounts (individuals) map to Twenty People. We extract name fields, email addresses, phone numbers, job title, and department from the Contact's primary attribute set. PostalAddress and PhoneNumber children linked to the Contact are mapped to the corresponding People address and phone fields, with multi-address support handled by concatenating into a single address string or splitting into custom address fields.

openCRX Opportunities inherit from the abstract contract class and include deal fields, ratings, stage assignments, and associated notes. We map the openCRX contract state (draft, negotiated, confirmed, fulfilled) to a Twenty Opportunity stage value set we create during workspace preparation. The original openCRX contract class hierarchy (Opportunity vs Quote vs Sales Order) is preserved as a custom Opportunity field so the customer retains the distinction without needing a separate Quote or Invoice object.

openCRX Quotes inherit from the same contract hierarchy as Opportunities and include line items modelled as contract positions. Twenty does not ship a native Quote object. We offer two options: (1) store Quote headers and line items as a Twenty Note with structured body text, or (2) create a Quote custom object with line item fields before import and map contract positions to Quote line records. The customer chooses during scoping; option 2 preserves more structured data but requires pre-creating the custom object schema before import.

Same constraint as Quote. Sales Orders in openCRX follow the contract hierarchy with position-level detail. We treat Sales Orders identically to Quotes: either as structured Notes or as a custom object created before import. If the customer uses Sales Orders for fulfilment tracking rather than billing, we recommend a custom object with fulfilment status fields.

openCRX Invoices are terminal contract objects with line positions and payment status. Twenty has no native Invoice object. We follow the same approach as Quotes and Sales Orders: structured Note or pre-created custom Invoice object. If the customer uses openCRX for billing integration with an ERP, we recommend keeping invoices in the ERP and linking them via URL or external ID as a custom field rather than duplicating billing data into Twenty.

openCRX Products map to a Product custom object or to Opportunity line items in Twenty. If the customer uses products primarily for pricing during the sales cycle, we recommend creating a Products object in Twenty and linking via custom Opportunity product fields. openCRX's multi-currency price lists and run-time pricing rules cannot be reproduced in Twenty's current multi-currency model (single default currency); we document the active price list values and advise the customer to enter key products manually or via a secondary CSV import after the initial migration.

openCRX Activities (calls, emails, meetings, tasks) are core objects with rich attributes and time-tracking linked to Activity Trackers for grouping. We map each activity subtype to the closest Twenty equivalent: openCRX task-type activities map to Twenty Tasks; meeting-type activities map to Twenty Tasks with a custom meeting flag; email-style activities map to Notes. Activity Tracker groupings that span multiple objects do not have a direct Twenty equivalent and are captured as custom tags or as a Note with a structured body that preserves the tracker context.

openCRX custom fields added via DataBinding PropertySet are stored as feature definitions in the UI customising layer and bound to CrxObject at runtime. We identify all active custom fields during scoping, map them to their openCRX target objects (Account, Contact, Opportunity, etc.), and pre-create them as Twenty custom fields in Settings → Data Model before import begins. This is a prerequisite step that must complete before any CSV import starts; Twenty's import creates records, not fields.

openCRX stores binary attachments linked to objects. We extract attachment metadata (filename, MIME type, linked object, link timestamp) and re-attach file content to the corresponding migrated records in Twenty where the file is accessible. Note that openCRX's WebDAV-based attachment storage is known to have Windows client quirks; we run exports on Linux or macOS to avoid silent file access failures. Large binary attachments may require separate download and re-upload workflows.

openCRX role-based security assigns users to segments with specific access permissions. We extract active users (name, email, active/inactive status) and map to Twenty Members. openCRX role permissions do not migrate; we document the permission matrix during discovery and provide a written role design recommendation for the customer's admin to configure in Twenty's workspace permissions post-migration.

openCRX Workflow Processes are segment-scoped and not standalone records that export and re-import into another system. We document every active Workflow Process definition (trigger conditions, steps, assigned roles) during discovery and deliver a written inventory with recommended rebuild steps in Twenty's workflow builder. The customer rebuilds workflow logic post-migration; this is not included in the migration scope per FlitStack AI standard policy.