Migrate from Rubi CRM to Microsoft Dynamics 365 Sales

Rubi CRM Contacts migrate directly to Dynamics 365 Contact records. Standard fields (FullName, Email, Phone, Address) map 1:1. We preserve any Rubi CRM custom contact properties as custom fields on the Contact entity in Dataverse before import. Owner resolution uses email matching against the destination Dynamics 365 User table; unresolved owners are held in a reconciliation queue for your admin to provision.

Rubi CRM Company records map to Dynamics 365 Account. The company name becomes Account Name, and any domain or website stored in Rubi CRM becomes the Account Website field. We use company name as the dedupe key during import. Account is created before Contact import so that the Parent Account lookup is satisfied at the moment of Contact insert.

Rubi CRM's Member record type has no native Dynamics 365 equivalent. We map Member to Contact and preserve Member ID as a custom field rubi_member_id__c, membership tier (Gold, Silver, Bronze, or custom) as a picklist field rubi_membership_tier__c, and renewal date as rubi_renewal_date__c. Membership status (Active, lapsed, Cancelled) maps to rubi_membership_status__c. The customer chooses whether to create a separate Member custom entity or use Contact with these custom fields during scoping.

Individual Membership records in Rubi CRM track subscription start date, end date, and tier against Member profiles. We map start_date and end_date to custom date fields on Contact or to a custom Membership entity if the customer requires a separate record for multi-subscription tracking. Rubi CRM does not export full subscription history in a single export pass; we flag this and run a separate extraction for renewal cycle data during scoping.

Rubi CRM Events and Training bookings map to Dynamics 365 Event records with custom fields for event type (Event vs Training), booking status (Registered, Attended, No-show, Cancelled), and seat count. The originating Contact or Member is linked via the Regarding (regardingobjectid) lookup. Seat-level attendance data requires a separate export run from the Events module; we include this as a second export pass and map attendance records to Event attendees or a custom attendance entity.

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 during the scoping call, map them to Dynamics 365 Opportunity Stage values, and create a Sales Process that matches the original Kanban column sequence. We deliver a written pipeline rebuild guide for your Dynamics 365 admin to configure the Opportunity Sales Process, Record Types, and stage probabilities post-migration.

Email interactions logged via Rubi CRM's Outlook plugin are stored as Activities linked to Contacts. We export Activity timestamps, subject, and body text and map them to Dynamics 365 Task records. Thread-level threading from the original email is not preserved as Rubi CRM does not store the email thread identifier. The Regarding field on Task points to the migrated Contact. Outbound sequences and automation are not supported in Rubi CRM and have no migration scope.

Rubi CRM Tasks map directly to Dynamics 365 Task records with Status, Priority, Due Date (scheduledend), and Owner preserved. Owner resolution uses email match against the Dynamics 365 User table. Tasks are imported after Contacts so that the Regarding (regardingobjectid) lookup is satisfied.

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, infer field types from sample data values, and create matching custom fields in Dynamics 365 before migration. The customer approves field names and types during a schema sign-off step before any data loads begin.