Migrate from Khoros Service to Zoho Desk

Khoros Customer records map to Zoho Desk Contact (for external customers) or End User (for internal support requesters). Standard fields (id, screen name, email, location) migrate directly. Custom searchable and non-searchable customer fields are discovered via Khoros GET /meta/object/customer before migration; Zoho Desk custom field labels are capped at 50 characters and alphanumeric plus underscore/dash/dot/at/question/comma/colon/single-quote/slash/exclamation characters only. Any Khoros custom field exceeding 50 characters is truncated and deduplicated. The Customer ID is stored in a Zoho Desk custom field khoros_customer_id__c for cross-reference.

Khoros Author represents the social identity of a customer engaging on social and community channels. We export Author screen name, brandOwned flag, and properties metadata as a linked record, then resolve Author references against the exported Customer table by email or screen name. If an Author cannot be matched to a Customer record, we create a Contact with the Author data and flag it in a custom field author_unmatched__c. This prevents orphan social identity records from being silently dropped during import.

Khoros Case maps directly to Zoho Desk Ticket. The Case title, status, customId, and priority migrate to Zoho Ticket subject, status, Ticket Number, and Priority. Custom case property fields discovered via Khoros meta/object endpoint migrate to Zoho Desk custom fields on the Ticket module. The Case Owner maps to Zoho Desk Agent via email resolution. Khoros case IDs are preserved in a custom field khoros_case_id__c.

Khoros nests Interactions as an ordered array within each Case, representing individual messages, notes, and status changes in a conversation thread. We flatten this structure into Zoho Desk Thread records (one per Case) with individual Comment entries preserving the original timestamp, direction (inbound/outbound), and author reference. Thread direction is preserved using Zoho's Incoming/Outgoing classification. All interactions are exported with the original Khoros interaction ID for audit continuity.

Both Customer and Case objects support custom field declarations in Khoros via the meta/object endpoint. We query GET /meta/object/{type} for both objects at the start of discovery, validate against a sample of records, then pre-create Zoho Desk custom fields with compatible types. Zoho Desk Professional and Enterprise editions support multi-select picklists, currency fields, and date fields that map cleanly from Khoros equivalents. Field labels exceeding 50 characters are truncated per Zoho Desk constraint.

Khoros agent records (email, name, role assignment) export as Zoho Desk Agents. Agent resolution is by email match. Khoros Initiative-based scoping has no direct Zoho Desk equivalent; we map initiative membership to department membership in Zoho Desk, and if no matching department exists we create one named after the Initiative. Any agent without a matching Zoho Desk user is held in a reconciliation queue for the customer's admin to provision before record import.

Khoros Brands define multi-tenant scoping for enterprise deployments managing multiple product or regional communities. Zoho Desk has no native Brand object, so we export Brand associations as tags on the Contact and Ticket records. The original Khoros Brand ID is preserved in a custom field khoros_brand_id__c. The customer selects whether Brands map to a single tag field or split across department assignment during scoping.

Khoros Initiatives group Campaigns and Case workflows under a specific business objective. We export Initiative membership as a tag on the Case record, and optionally create Zoho Desk departments named after each Initiative to preserve the organizational layer. Department-level ticket routing is enabled in Zoho Desk during configuration if the Initiative-to-department mapping is selected.

Khoros Campaigns track marketing and social care campaign attribution on Cases and Conversations. We export campaign association as a tag on the Ticket record in Zoho Desk. If the customer has licensed Zoho CRM alongside Zoho Desk, campaign attribution can alternatively map to the Zoho CRM Campaign object via cross-application linking, though this requires additional configuration outside standard migration scope.

Knowledge base articles in Khoros have structured content, category hierarchy, and visibility settings. We export article body, title, and category hierarchy to Zoho Desk Articles organized under Sections and Root Categories. Image assets embedded in KB content are downloaded from Khoros CDN infrastructure and re-uploaded to Zoho Desk. Zoho Desk KB article creation dates are preserved from the Khoros source; the Zwitch documentation notes that KB dates may reset during vendor-led migration, but our custom export uses the original Khoros timestamp to maintain audit continuity.

Khoros Conversation is the real-time messaging object for direct messaging channels. We export conversation metadata, participants, and message history, then create a corresponding Zoho Desk Ticket with the conversation thread populated as Thread and Comment records. Since the Care API rate limit is 60 req/min, large conversation exports are chunked in batches with exponential backoff to avoid 429 errors that would invalidate session tokens.

Khoros stores attachments on separate CDN infrastructure, not within the Case or Customer API response. We fetch attachments referenced by Case and Author records separately, then re-upload them to Zoho Desk as Ticket or Contact attachments. The Zoho Desk API handles attachment upload via multipart form-data within the Zoho-API credit-based quota. KB article attachments similarly require separate download-and-reupload handling since Zoho Desk does not accept external CDN URLs during import.