Migrate from Khoros Service to Salesforce Service Cloud

Khoros Customer maps to Salesforce Contact as the primary profile object. Standard fields (screen name, email, location) map to Contact.Name, Contact.Email, and Contact.MailingCity. Custom searchable and non-searchable customer fields declared in the Khoros meta/object endpoint are discovered during scoping, then typed and mapped to Salesforce custom fields (with __c suffix) on the Contact object. Brand associations from Khoros Brands migrate as Salesforce Teams or a custom multi-select picklist field depending on the customer's reporting structure.

Khoros Case maps to Salesforce Case as the primary ticket object. Title, status, priority, and customId migrate to Case.Subject, Case.Status, Case.Priority, and a custom Case.KhorosId__c field for cross-reference. The Case.Origin field is set based on the Khoros channel identifier (social, community, messaging, email) stored in the Case customId metadata. OwnerId is resolved by matching the Khoros agent email to a Salesforce User.

Khoros Author represents the social identity of a customer engaging on a channel. Author profile data (screen name, brandOwned flag, properties metadata) is appended to the mapped Contact as custom fields. Where an Author does not have a corresponding Khoros Customer record, we create a Contact record with the Author data and tag it with a custom field author_only__c to indicate it is a social identity without a full CRM profile.

Khoros Interactions are an ordered array within each Case representing individual messages, notes, and status changes. We explode this array into discrete Salesforce activity records: inbound messages become EmailMessage records (Body, FromName, FromAddress, ToAddress, Incoming=true) linked to the Case via ParentId; outbound messages become EmailMessage with Incoming=false; notes and status changes become Task records with TaskSubtype set appropriately. The original Khoros Interaction timestamp preserves ActivityDate for thread ordering.

Khoros Conversation is the real-time messaging object. We treat each Conversation as a Case, extracting metadata and participants as a Case record with the Khoros Conversation ID stored in KhorosId__c. Message history within the Conversation is migrated as Interaction records following the same EmailMessage and Task pattern as Case Interactions. The rate limit of 60 req/min on the Khoros Conversation API requires chunked export with exponential backoff.

Khoros Agent records (email, name, role assignment) map to Salesforce User. We resolve agents by email match. Any Khoros agent without a matching Salesforce User is held in a reconciliation queue for the customer's admin to provision before Case import resumes. Role assignments map to Salesforce Permission Sets or a custom role hierarchy field depending on the customer's security model.

Khoros Initiatives group Case workflows under a specific business objective and have no direct Salesforce equivalent. We export initiative membership on records and map it to Salesforce Case Tags (a standard tagging feature) or a custom multi-select picklist field on Case, depending on which approach the customer's reporting structure requires. Initiative-level reporting requires a separate rebuild using Salesforce Reports and Dashboards.

Khoros Campaigns track marketing and social care campaign attribution on Cases and Conversations. We export campaign association as a Campaign record (Name, StartDate, Type) plus a tag on the Case linking to the Campaign. If Salesforce already has a Campaign object with overlapping data, we use CampaignMember to associate the Case or Contact with the existing Campaign record.

Khoros Knowledge Base articles export with structured content, categories, and visibility settings. Article body, title, and category hierarchy map to KnowledgeArticle.Title, KnowledgeArticle.UrlName, and DataCategoryGroupAssignment. Embedded image assets in KB content are downloaded from Khoros CDN and re-uploaded to Salesforce Files (ContentDocument) with the Article ID stored in the ContentDocument's Description field for re-linking. We do not migrate KB article configuration or visibility rules as Salesforce Knowledge settings; we document the source settings for the admin to rebuild.

Both Khoros Customer and Case objects support custom field declarations via the meta/object API, with schema varying by tenant. We call GET /meta/object/{type} for both customer and case during discovery, validate the discovered fields against a sample of records, then pre-create the Salesforce custom fields (with appropriate field types) before any data import begins. Custom fields that have no suitable Salesforce type are stored as text and documented for the customer to re-type post-migration.