Migrate from Rubi CRM to Salesforce Sales Cloud

Rubi CRM Contact records map directly to Salesforce Contact. Standard fields (Name, Email, Phone, MailingAddress) migrate 1:1. We map any Rubi CRM custom contact properties as Salesforce custom fields, discovered during the scoping export by analysing field names in the raw payload. The Rubi CRM Contact's related Company record provides the AccountId lookup on the Salesforce side, resolved by company name match during import.

Rubi CRM Company records map to Salesforce Account. Company name becomes Account Name; business address maps to BillingAddress. The Rubi CRM Company-Contact relationship is preserved as the Account-Contact lookup. We use company name as the dedupe key during import to avoid duplicate Accounts. Account is created before Contact import so that AccountId is satisfied at Contact insert time.

Rubi CRM Member is a distinct record type tied to the membership module. We map Member records to Salesforce Contacts with a set of custom fields: membership_status__c (Active, Lapsed, Cancelled), membership_tier__c (mapped from Rubi CRM tier name), and membership_start_date__c. Rubi CRM does not expose a schema endpoint, so we discover tier field names during the scoping export and create matching picklist fields in Salesforce before migration. If a Member record has no corresponding Contact (person-only membership), we create a Contact first and attach the membership fields.

Membership records track individual subscriptions against Member profiles. We map start date, end date, and tier name to the Contact-level custom fields created during the Member mapping. Rubi CRM does not export full subscription history in a single pass, so we pull the most recent active or most-recently-ended Membership record per Member. Renewal date and auto-renew flags become membership_renewal_date__c and membership_auto_renew__c custom fields on Contact.

Rubi CRM Events map to Salesforce Event. Event Name maps to Subject, Event Date maps to StartDateTime, and booking status maps to a custom picklist event_booking_status__c. Seat-level attendance data requires a separate export run from the Events module after the initial event-metadata migration. We import attendee records as Salesforce EventRelation records linking the Event to the related Contact or Member. Event duration and location map to EndDateTime and Location fields.

Rubi CRM Training records are treated as a sub-type of Event with the same mapping rules. Training-specific fields (instructor, session code, CPD hours) migrate as custom fields on the Salesforce Event record. Training attendance, like Event attendance, requires a second export run for seat-level records.

Rubi CRM uses a Kanban-style pipeline view, but stage names are user-defined custom fields stored against deal records rather than a native pipeline object. We extract all distinct stage values during the scoping call by reviewing Rubi CRM deal records, then configure corresponding Opportunity StageName values in Salesforce before migration. Each Kanban stage becomes a Salesforce Opportunity Stage with probability, closed-won, and closed-lost flags. If the customer uses multiple Kanban boards, we map each to a Salesforce Record Type with its own Sales Process.

Rubi CRM Tasks map directly to Salesforce Task. Owner assignment migrates by resolving the Rubi CRM owner email to the Salesforce User record via the owner reconciliation queue. Due date, status (Open, Completed), and priority map 1:1. Tasks with no assigned owner are held until the admin provisions the User in Salesforce.

Emails logged via the Rubi CRM Microsoft Outlook plugin are stored as Activities linked to Contacts. We export Activity timestamps, subject, and body text and map them to Salesforce Task records for the activity timeline entry, with the email body and thread preserved as an EmailMessage record linked to the Task. Thread-level threading from the original email is not preserved because the Outlook plugin does not export thread IDs. Rubi CRM does not support outbound email sequences or automation, so there is no equivalent cadence data to migrate.

Rubi CRM allows custom fields per record type but does not expose a schema endpoint. We discover custom field names and types during the scoping export by analysing the raw JSON payload of exported records. Before production migration, we provision matching Salesforce custom fields (with correct field types: text, picklist, date, checkbox, number) in a Salesforce Sandbox for validation, then deploy to production org. This step adds one to two weeks to the migration timeline and must complete before any record import begins.

Rubi CRM Reports module exports flat snapshots rather than relational data and its Audit Log tracks user actions without containing CRM records. Neither is a viable migration source. We do not migrate these objects. We deliver a written inventory of all Saved Reports with their field selections, filters, and chart configurations so the customer's admin can recreate them in Salesforce's reporting engine. Audit Log exports should be retained as CSV files on the customer's own storage for compliance purposes.

Rubi CRM allows Members to be linked to Companies. We resolve this relationship by matching the Rubi CRM company reference against the Company name in the export, then map to the Salesforce Account-Contact relationship. If a Member is linked to a Company that has no corresponding Contact in Rubi CRM, we create the Contact record first and attach the Account lookup to preserve the business relationship in Salesforce.