Migrate your openCRX data

Account is the primary person or organisation object, split into Contact (individuals) and LegalEntity (companies). All account-related data including PostalAddress and PhoneNumber are standard fields. We migrate both subtypes and preserve the full address structure as structured fields.

openCRX models opportunities as part of the contract hierarchy, inheriting from abstract contract classes. Deal fields, ratings, and associated notes are standard. We map stage transitions and timestamp history to the destination CRM's equivalent pipeline object.

Quotes inherit from the same contract hierarchy as Opportunities and Sales Orders. Quote positions are modelled as contract positions. We preserve line items, pricing rules, and currency context during migration.

Sales Orders follow the contract hierarchy and can be transformed from Quotes. Order positions are contract positions. We capture order headers and all position details, including pricing logic applied at order time.

Invoices are terminal contract objects in the sales process chain, inheriting from contract classes. We migrate invoice headers, line positions, and payment status as structured records.

openCRX supports complex product structuring including bundles and design-to-order scenarios. Multi-currency price lists and run-time pricing rules are stored as configuration. We map products, pricing tiers, and currency associations to the destination catalog structure.

Activities are core openCRX objects with rich attributes including time-tracking and activity trackers for grouping. Activity subtypes and custom feature definitions require field-level mapping. We extract all activity records and map tracker groupings to the destination's task or activity equivalent.

openCRX includes a Workflow Controller and topic-based event subscription system. Workflow processes are segment-specific and not carried as standard records. We can export workflow process definitions and topic subscriptions but they require significant reconfiguration in most destination systems.

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, extract their values, and map them to custom fields in the destination CRM.

openCRX stores binary attachments linked to objects. We extract attachment metadata and file content where accessible via the data export, and re-attach them to the corresponding migrated records in the destination system.

Topics drive email notifications and alerts based on object lifecycle events (creation, modification, removal). These are infrastructure configuration objects tightly bound to the running openCRX instance. We do not migrate alert subscriptions as they require reconfiguration in the destination platform.

openCRX uses role-based security with segment-scoped user assignments. User records, roles, and access permissions require mapping to the destination's user and permission model. Active users are migrated; historical role configurations are documented for manual re-creation.