Migrate from Keeping to Zoho Desk

Keeping Tickets map directly to Zoho Desk Tickets. The Keeping ticket subject becomes Ticket Subject, ticket status (Open, Pending, Resolved, Closed) maps to Zoho Desk Status values (Open, Pending, On Hold, Resolved, Closed), and priority maps to Priority (Low, Medium, High, Urgent). The Keeping ticket ID is preserved as zohodesk_external_id__c for reconciliation. Because Keeping has no standalone database, we reconstruct ticket timestamps from Slack thread metadata during scoping, which requires pre-processing before Zoho Desk import.

Keeping Customers are flat records without separate Contact and Account separation. We split during migration: the primary customer name and email become a Zoho Desk Contact record, and we create an Account record for organizational context. If the Keeping Customer record includes company affiliation, that value maps to the Account Name field on Zoho Desk Account. The Contact is linked to the Account via the Account Lookup. Customer email is the dedupe key on Contact.

Keeping's Slack Channel-to-ticket mapping has no direct Zoho Desk equivalent. We map each distinct Slack channel referenced in Keeping ticket metadata to a Zoho Desk Department. Department creation happens before ticket import so that the Department ID is available for ticket assignment during migration. If a Keeping team used a single channel for all tickets, we create a single Department and configure agent-to-ticket routing within that scope. Multiple channels become multiple Departments with department-specific email addresses for incoming routing.

Keeping ticket thread history maps to Zoho Desk Ticket Comments. Each Slack message in the thread becomes a Comment record with the author identified as either a Contact (customer) or an Agent. We preserve message timestamp, message body, and any file attachment URLs from Slack. Thread direction is reconstructed from Slack message sender: messages from the customer email address become Zoho Desk Incoming comments; messages from the assigned agent email become Outgoing comments. This direction flag is critical for Zoho Desk reporting on first-response time.

Keeping attachments stored in Slack are file references (links) rather than embedded files. We extract Slack message attachment URLs (images, PDFs, files shared in thread) and re-attach them to the corresponding Zoho Desk Ticket Comment during migration. Slack-hosted files require the customer's Slack workspace to remain accessible post-migration, or we recommend downloading attachments to a temporary cloud storage bucket before migration to avoid link rot. Zoho Desk's 10 MB per-attachment limit applies.

Keeping Agents map to Zoho Desk Agents. We match by email address: the agent email on Keeping ticket assignment becomes the Agent email in Zoho Desk. We pre-create the Agent records in Zoho Desk before ticket import because Agent ID is required on ticket submission. If a Keeping agent email does not have a corresponding Zoho Desk user account, we place the ticket in a reconciliation queue for the customer's admin to provision the agent before import resumes.

If Keeping tickets reference products (from the Keeping Products module if used), those map to Zoho Desk Products. The Product Name and SKU fields transfer directly. Product records must exist in Zoho Desk before Tickets that reference them are imported, so we migrate Products first in the dependency order.

Internal tasks tracked in Keeping (if the team used a task-tracking layer separate from tickets) map to Zoho Desk Tasks. The task title, due date, assigned agent, and status transfer to the corresponding Zoho Desk Task fields. Tasks without a due date map to Zoho Desk Tasks with no Due Date.

Keeping has no native Knowledge Base module; any articles or shared resources were stored as Slack messages, Google Docs links, or Confluence pages. We do not migrate these as code. We deliver a written inventory of any Slack-stored articles with their URLs, last-modified date, and category, along with a Zoho Desk Knowledge Base article creation guide so the customer's admin can rebuild them as Zoho Desk articles with the proper folder structure and portal assignment.

Keeping ticket tags and labels map to Zoho Desk Tags on the Ticket record. Tags are preserved as comma-separated values imported into the Tag field on each Zoho Desk Ticket. Tag strategy (flat vs hierarchical) is decided during scoping. Zoho Desk's tag autocomplete behavior is maintained post-migration.

Keeping has no native canned response library; teams using them store them as Slack snippets or external documents. We do not migrate these as records. We deliver a written inventory of any identified canned responses with their text content, trigger conditions, and recommended Zoho Desk Macro equivalent, with the customer rebuilding them as Macros under Setup > Macros post-migration.

Keeping does not expose a formal custom field schema API; any custom attributes on tickets are stored as key-value metadata within the Slack thread or as ticket properties. We audit these during scoping, map them to Zoho Desk Custom Fields on the Ticket layout (using text, number, date, picklist, or checkbox types as appropriate), create the fields via Zoho Desk's Layouts and Fields interface before migration, and import values during ticket migration. Fields with no clear Zoho Desk type are flagged in the scoping report for the customer's admin to resolve.