Migrate from Rubi CRM to Twenty CRM

Rubi CRM Contacts map directly to Twenty People. Standard fields (name, email, phone, address) migrate 1:1. We preserve any Rubi CRM custom contact properties as custom fields in Twenty's Data Model (Settings → Data Model). The People record is created before any related Membership or Event booking import so that lookup relationships resolve at the moment of insert.

Rubi CRM Company records map directly to Twenty Company. The Company-Contact relationship migrates as a name-matched lookup: we use Rubi CRM's company name as the dedupe key during Twenty Company import and link it to the related People record by email domain match where no explicit foreign key exists in the export.

Rubi CRM's Member record type has no direct Twenty equivalent — it is a distinct entity tied to the membership module. We create a custom object named Member in Twenty (API name Member__c) with custom fields for member_id (text), membership_status (select), membership_tier (select), and renewal_date (date). The custom object must be created in Settings → Data Model before the CSV import runs, per Twenty's import requirement.

Rubi CRM Membership records track individual subscriptions against Member profiles. We map start_date, end_date, and tier_name to custom fields on a Member_Subscription__c custom object in Twenty with a lookup to Member__c. Rubi CRM does not export full subscription history in a single pass — we request separate export runs from the Membership module for each renewal period and combine them during the transform phase.

Rubi CRM Events and Training bookings are objects with seat-level attendance data. We create an Event__c custom object in Twenty with fields for event_name, event_date, booking_status, and a lookup to the originating Rubi CRM Contact or Member. Rubi CRM requires a separate export run from the Events module for seat-level attendance data — we request this explicitly during scoping. Events are imported after People so that the Contact lookup resolves correctly.

Rubi CRM uses a Kanban-style pipeline view with user-defined stage names stored as custom fields against deal records, not as a native pipeline object. We extract the distinct stage values from Rubi CRM during the scoping call, create a custom Opportunity stage field in Twenty (e.g., opportunity_stage__c as a select), and populate it from the Rubi CRM deal export. The pipeline Kanban view itself must be re-created manually in Twenty's view builder post-migration.

Rubi CRM deal records (the underlying records under the Kanban view) map to Twenty Opportunity. Deal name, amount, expected close date, and owner migrate 1:1. The stage value migrates to the custom opportunity_stage__c field described above. Owner resolution is by email match against Twenty Members.

Email interactions logged via the Rubi CRM Outlook plugin are stored as Activities linked to Contacts. We export activity timestamps, subject, and body text as a flat export. These map to Twenty Task records linked to the related People record. Thread-level email threading from the original message is not preserved in the flat export. We flag this limitation in the migration report.

Rubi CRM Tasks (owner, due date, status) migrate directly to Twenty Task. Owner assignment migrates by resolving Rubi CRM username to Twenty Member by email match. Completed status maps directly; open tasks retain their original due date and priority.

Rubi CRM allows custom fields per record type but does not expose a schema endpoint. We discover custom field names during the export scoping phase by requesting the full field list from the Rubi CRM export interface. We then pre-create matching custom fields in Twenty's Data Model (Settings → Data Model) before any CSV import begins. Type mapping is done by inspecting the Rubi CRM export data: date fields become date fields, select options become select fields, and text fields become text fields.