Migrate from Rubi CRM to HighLevel

Rubi CRM Contact records map directly to GoHighLevel Contact records. Standard fields (name, email, phone, address) migrate 1:1. We preserve any Rubi CRM custom contact properties as GoHighLevel Contact custom fields, which must be pre-created in GoHighLevel under Settings > Custom Fields > Contacts. Rubi CRM custom field names are discovered during the export scoping phase because Rubi CRM does not expose a schema endpoint.

Rubi CRM Company records map to GoHighLevel Company records. The Company-Contact relationship in Rubi CRM is explicit via a linked field; GoHighLevel Company-Contact linking is resolved by name-matching during import. We run a name-dedupe pass before inserting Companies to avoid duplicates, then map Contacts to the resolved Company record by company name string match.

Rubi CRM Member is a distinct record type tied to the membership module. We map Member ID and membership status directly, but tier names and renewal dates require field-value mapping against GoHighLevel Opportunity custom fields rather than Contact fields. Member ID is stored in a Contact custom field rubi_member_id__c and the membership status maps to a Contact custom field rubi_membership_status__c.

Rubi CRM Membership records track individual subscriptions against Member profiles. We map start dates, end dates, and tier names to Opportunity custom fields on a membership Opportunity record linked to the Contact. Rubi CRM does not export full subscription history in a single pass, so for accounts with multi-year or lapsed memberships we run separate export queries from the Membership module per account. We create a custom object named Membership_Record in GoHighLevel if the customer has more than 10 active membership types and needs full renewal history.

Rubi CRM Events with bookings tied to Contacts or Members map to GoHighLevel Opportunities with event name, date, and booking status. Seat-level attendance data requires a separate export run from the Events module because it is not included in the standard Contacts export. We configure a custom object named Event_Booking in GoHighLevel for customers with complex event attendance records, linking each booking to the Contact attendee via a lookup field.

Rubi CRM uses a Kanban-style pipeline view where stage names are user-defined custom fields stored against deal records, not a native pipeline object. We extract stage values and their ordering during the scoping call, then configure GoHighLevel Pipeline stages to match the source stage names. Stage probability mapping follows the customer's source data. This is a configuration step, not a data migration step.

Email interactions logged via the Outlook plugin are stored as Activities linked to Contacts. We export Activity timestamps, subject, and body text, but thread-level threading from the original email chain is not preserved in the export. These migrate as individual activity log entries on the Contact record in GoHighLevel. Outbound sequences and automation-triggered emails are not in scope because Rubi CRM does not support outbound sequences.

Rubi CRM Tasks are standard records with owner, due date, and status. We map these directly and re-assign ownership by username lookup in GoHighLevel. Any Rubi CRM Owner without a matching GoHighLevel User is placed in a reconciliation queue for the customer's admin to provision before task import resumes.