Migrate from Cordis CRM to Salesforce Sales Cloud

Cordis CRM Contact records map to Salesforce Contact. The contact's name, email, phone, and address fields map to Salesforce standard fields (FirstName, LastName, Email, Phone, MailingStreet, MailingCity, MailingState, MailingPostalCode, MailingCountry). We resolve the Cordis Company linkage to a Salesforce AccountId using company-name matching against the imported Account records. Any Cordis custom contact properties identified during scoping map to Salesforce custom fields with the __c suffix. Contact Priority or contact type flags from Cordis map to a custom picklist field cordis_contact_type__c for post-migration segmentation.

Cordis CRM does not separate prospects from customers at the object level. We define a split rule during scoping based on Cordis contact properties such as lifecycle stage, last activity date, or deal association. Contacts without any associated Deal or Campaign membership in Cordis are candidates for Salesforce Lead rather than Contact. The original Cordis contact record is preserved in a custom field cordis_original_id__c on the Lead for audit and cross-reference. The customer's admin approves the split rule before migration begins.

Cordis CRM Company records map to Salesforce Account. Company name maps to Account Name, domain or website maps to Website, industry maps to Industry (mapped to the Salesforce standard picklist), and employee count maps to NumberOfEmployees. Account is created before any Contact import so that the AccountId lookup is satisfied at the moment of Contact insert. We use company name as the dedupe key and flag any duplicate Account names in the export for the customer to resolve before migration.

Cordis CRM Deal records map to Salesforce Opportunity. The deal name maps to Opportunity Name, deal value maps to Amount, deal stage maps to StageName, and expected close date maps to CloseDate. We map Cordis pipeline assignments to Salesforce Record Types and Sales Processes during the schema design phase. If Cordis uses multiple pipelines, each becomes a separate Salesforce Record Type on Opportunity with its own stage whitelist and page layout. Owner resolution uses email matching to the imported Salesforce User records.

Each Cordis CRM deal stage value maps to a Salesforce Opportunity StageName entry in a Salesforce Sales Process. Stage probability percentages migrate from Cordis to Salesforce StageProbability, rounded to the nearest integer allowed by Salesforce. Stage order is preserved by setting the sort order in the OpportunityStage metadata. We configure the Sales Process in a Salesforce Sandbox before production migration and validate stage visibility per profile.

Cordis CRM Tasks (both automated and manual) map to Salesforce Task records. Task subject maps to Subject, due date maps to ActivityDate, status maps to Status (Not Started, In Progress, Completed), and priority maps to Priority. Assigned owner resolves via email match to Salesforce User. Task body or description maps to Description. Recurrence rules from Cordis tasks do not transfer; we flag recurring tasks and document the pattern for the customer's admin to reconfigure in Salesforce Flow after migration.

Cordis CRM documents attached to Contact, Company, or Deal records map to Salesforce ContentVersion (file content) and ContentDocumentLink (relationship). The document title maps to Title on ContentVersion and the file extension maps to FileType. ContentDocument is created automatically when ContentVersion is inserted. We link each ContentDocument to the parent record (Contact, Account, or Opportunity) via ContentDocumentLink with link type EntityPermission. Version history is not guaranteed in the Cordis export; we migrate the latest version and flag multi-version documents so the customer can decide whether to restore earlier versions manually post-migration.

Cordis CRM file attachments linked to Contact, Company, or Deal records map to Salesforce ContentVersion and ContentDocumentLink following the same pattern as document migration. We preserve the original filename in Title and the file extension in FileType. Attachments without a recognized parent record go into a holding queue for the customer's admin to assign before finalizing the migration.

Cordis CRM Campaigns map to Salesforce Campaign. Campaign name maps to Name, start date maps to StartDate, end date maps to EndDate, status maps to IsActive, and budgeted cost maps to BudgetedCost. We create the Campaign in Salesforce before importing membership so that the CampaignId is available for ContentDocumentLink resolution on the member records.

Cordis CRM campaign membership records map to Salesforce CampaignMember. The contact or prospect maps to either Salesforce ContactId (if the contact was migrated as Contact) or LeadId (if split to Lead). CampaignMember Status maps from Cordis engagement status (Responded, Sent, Open). We resolve CampaignMember records after Contacts and Leads are fully imported and reconciled, using the cordis_original_id__c cross-reference field to match the correct parent.

Cordis CRM owner references on Contact, Company, Deal, Task, and Campaign records map to Salesforce User via email matching. We extract every distinct owner ID from the export file, match by email address against the destination Salesforce org's User table, and build an owner mapping table. Any Cordis owner without a matching Salesforce User goes to a reconciliation queue; the customer's Salesforce admin provisions missing Users before record import continues. Owner resolution must complete before any phase that assigns OwnerId.

Cordis CRM custom fields are not publicly documented in a schema reference. During scoping, we survey the customer's Cordis instance via screen share to identify all active custom fields, their data types, and the records they are attached to. Each custom field is then pre-created in Salesforce with the equivalent data type (text field for strings, number field for integers, date field for dates, picklist for enums). The __c suffix follows Salesforce naming convention. We map Cordis custom field names to Salesforce API field names and preserve the mapping in our transform configuration for the migration run.

Cordis CRM engagement records (calls, emails, meetings) linked to contacts map to Salesforce Task (for calls and generic activities), Event (for meetings), and EmailMessage (for emails). Call duration and disposition migrate to custom Task fields. Email body and headers migrate to EmailMessage linked to a Task on the timeline. Meeting start and end times migrate to Event StartDateTime and EndDateTime. The WhoId on the Task or Event points to the migrated Contact or Lead; the WhatId points to the related Account or Opportunity. We use the Bulk API 2.0 for large engagement volumes and resolve parent-record IDs at migration time.

If Cordis CRM contains custom object types beyond the standard Contact, Company, and Deal, we migrate them to Salesforce custom objects following the same __c naming convention. We pre-create the destination schema in Salesforce including all custom fields, lookup relationships to standard objects (Account, Contact, Opportunity), and validation rules before any data import. The customer identifies custom objects during scoping; if Cordis does not expose custom object definitions publicly, we request the export file structure during the data audit phase and infer the schema from the export columns.