Migrate from openCRX to HighLevel

openCRX LegalEntity records (organisations) map to GHL Contacts. The LegalEntity's legalName becomes the Contact's Company Name field. postalAddress and phoneNumber sub-objects map to GHL's address and phone fields. We use Company Name as the dedupe key during import. LegalEntity accounts are imported before any Contact records so that the lookup relationship is satisfied at insert time. Note that GHL has no separate Account object, so all organisation-level data lives on the Contact record.

openCRX Contact records (individuals) map to GHL Contacts. We use email as the dedupe key. GivenName, Surname, and formalName map to GHL's name fields; PhoneNumber sub-objects map to phone1 and phone2. The Contact's link to its parent LegalEntity is resolved at migration time so that the GHL Contact carries the correct Company Name. openCRX Contacts without an email address are flagged for manual review because GHL's API uses email as the primary identifier.

openCRX Opportunities (contract-derived objects with stage, amount, and expected close date) map directly to GHL Opportunities. The openCRX opportunity rating and contract class attributes transfer to GHL pipeline stage and custom fields. openCRX's multi-segment opportunity model maps to GHL's pipeline concept. Amount fields transfer as-is; multi-currency amounts use the base currency if the migration customer does not require multi-currency tracking.

openCRX Quotes inherit from the contract hierarchy and contain line items (contract positions) with pricing rules and currency context. Quotes map to GHL Opportunities in a dedicated quote pipeline stage. Line items are extracted as a text summary or custom field block on the GHL Opportunity because GHL does not natively support Opportunity Product line items in the same structured way. We preserve the quote amount, currency, and creation date.

openCRX Sales Orders map to GHL Opportunities in the Won stage. Order header data and contract position line items are migrated as a structured note or custom field block. The original openCRX order number is preserved in a custom field for audit traceability. openCRX's pricing logic rules are not transferable and are documented for manual rebuild in GHL.

openCRX Invoices (terminal contract objects) map to GHL Invoices if the destination GHL account includes the Payments add-on. Invoice headers, line positions, and payment status transfer as structured records. openCRX's multi-currency invoice amounts transfer using the base currency unless the customer has configured GHL for multi-currency handling. Unpaid invoice status maps to GHL's outstanding invoice state.

openCRX Products (including bundle and design-to-order variants) map to GHL Products. The openCRX SKU (hs_sku equivalent) becomes the GHL Product SKU field. openCRX price lists and run-time pricing rules are not transferred as live configuration; we map the current active price to the GHL Product price field and document the pricing rule structure for manual GHL Price List rebuild if needed.

openCRX Activities map to GHL Activity records of the corresponding type. openCRX Activity Trackers (grouping containers) are not native GHL objects; we preserve tracker names as a custom field tag on the enclosed activities. Activity timestamps and duration fields transfer directly. Activity assignments resolve the openCRX owner to the corresponding GHL user by email match.

openCRX custom fields added via DataBinding PropertySet require schema discovery during scoping. We identify all active custom fields bound to Account, Contact, and Opportunity, then pre-create equivalent GHL Custom Fields before data import. GHL Custom Field naming follows its own conventions and has type limitations; text, number, date, and dropdown fields map directly; complex nested PropertySet structures may require flattening into multiple GHL fields. We validate field type compatibility during scoping.

openCRX Users with active logins are mapped to GHL team members by email. openCRX role-based security assignments (segment-scoped) are not transferable to GHL's permission model; we document the role structure during scoping and recommend a GHL role and access configuration for the customer's admin to apply post-migration.