Migrate from Oncord to Salesforce Sales Cloud

Oncord Contact records map 1:1 to Salesforce Contact. Standard fields (FirstName, LastName, Email, Phone, MailingAddress) transfer directly. Oncord's activity feed maps to Salesforce's Activity timeline as Tasks and Events. Any Owner assignment on the Contact resolves to a Salesforce User by email match during import. We flag Oncord Contacts with no last name (common in sole-trader records) and flag these for manual review before insert because Salesforce requires LastName on Contact.

Oncord Groups function as static segmentation lists and map to Salesforce Campaign records, with the Group membership preserved as CampaignMember records linked to the corresponding Contact. We use Campaign Type = 'Manual' for migrated Groups. If a Contact belongs to multiple Groups, it appears as multiple CampaignMember records. On Lite plans, filters are restricted to Groups only, which means Lite-tier customers may have extensive Group membership that requires bulk CampaignMember inserts.

Oncord CustomFields (text, number, date, dropdown, checkbox, file upload) read via the CustomFields API component map to typed Salesforce custom fields on the Contact object. We pre-create the destination schema in Salesforce before migration, handling type mapping (Oncord text to Salesforce Text, number to Number or Currency, date to Date, dropdown to Picklist or Multi-Select Picklist). File attachment fields on Oncord CustomFields map to Salesforce ContentDocument with ContentDocumentLink to the parent Contact.

Products are only present if the Commerce add-on ($40/month) was active. We export product name, description, price, SKU, inventory count, product images, and any custom product fields. Each Product becomes a Salesforce Product2 record with a Standard Pricebook entry. Products with multiple price tiers map to multiple PricebookEntry records. Commerce gating is confirmed during scoping; customers on Lite or base-only plans have no product data and that phase is skipped.

Oncord Events (part of the Marketing add-on) include event name, date, location, capacity, and an attendee list linked to Contacts. Events map to Salesforce Event records for scheduling data and to a Salesforce Campaign with Type = 'Conference' or 'Webinar' to capture the attendee list as CampaignMember records. We resolve each attendee Contact by email match before creating the CampaignMember. Events without attendees create only the Event record.

Oncord discount rules, coupon codes, eligibility conditions, and usage limits exist only with the Commerce add-on active. We map these to a custom Salesforce object Promotion__c with fields for code, discount type (percentage vs fixed), discount value, eligibility rules, usage limit, and usage count. If the customer requires Salesforce-native promotion tracking, we scope the custom object creation during discovery; otherwise, we deliver a written schema specification for their admin to create.

Oncord web forms grow the contact database and carry custom field-to-property mappings per form. We export form definitions and field mappings, then deliver a written specification for rebuilding in Salesforce Web-to-Lead or a custom form builder. The field-to-contact-property mappings are documented so the customer's admin can configure the equivalent Web-to-Lead field mapping in Salesforce Setup. Form data submissions (the leads themselves) migrate as Contacts.

Oncord user records (name, email, role) map to Salesforce User records. We extract every distinct user referenced on Contact owner fields and resolve by email match against the Salesforce destination org. Users without an active Salesforce User provision go to a reconciliation queue for the customer's admin to address before record import. Role semantics differ between platforms; Oncord admin roles map to Salesforce System Administrator profile assignments handled by the admin post-migration.

Oncord marketing automation workflows (triggers, conditions, actions) are documented in a written inventory we deliver to the customer. Workflows do not migrate as code because Oncord's trigger-based automation model differs structurally from Salesforce Flow's record-triggered, scheduled, and screen flow variants. We capture the workflow name, trigger event, condition logic, action sequence, and active/inactive status for each workflow so the customer's admin or a Salesforce partner can rebuild them in Flow.

Oncord's contact activity feed records timestamps and descriptions of interactions. We map activity entries to Salesforce Task records with ActivityDate set to the original Oncord timestamp and Description carrying the activity body. Phone call activities map to Task with TaskSubtype=Call. Email activities map to Task linked to an EmailMessage record. Each activity's parent Contact resolves by email match before insert.

Oncord email accounts ($5/account/month) are separate from the CRM data and do not migrate into Salesforce as email records. We flag email account count and storage volume during scoping and recommend a strategy for email archival separately from the CRM migration. If email-to-contact threading was active in Oncord, we document the email address associated with each Contact for the customer's admin to configure Salesforce email routing post-migration.

Oncord has no native Account or Company object — Contacts are the primary record. However, contacts with shared domain or organizational affiliation can be grouped. We create Salesforce Account records from Oncord Contact organizations identified by shared domain or explicit company name field, then link the related Contacts to those Accounts via AccountId. If no company data exists in Oncord, we create a single Account named 'Imported from Oncord' and link all Contacts to it, flagging this for the customer's admin to split by organization post-migration.