Migrate from Keeping to Zendesk

Keeping tickets exist as Slack channel threads. We parse each thread into a Zendesk Ticket, mapping thread timestamps to ticket created_at and updated_at, Slack channel name to a Zendesk Tags value, and any Slack user mentions to the requester or assignee fields. Thread messages become Ticket comments in chronological order. If the Slack export includes reply metadata, internal-only messages map to Zendesk internal comments (visible to agents only). We set ticket Status based on thread resolution state inferred from Slack reaction emoji or closing language.

Keeping reconstructs customers from ticket metadata: the Slack user who opened the ticket provides email and display name. We map the requester to a Zendesk User record (role: end-user), and attempt to extract company domain from the requester email or from thread context to create a Zendesk Organization. If no company data exists in Keeping, we create the User without an Organization link and document this gap for the customer's admin to enrich post-migration.

Keeping uses a Slack Channel to represent a support queue or topic area. We map Slack Channel name to Zendesk Tags (for reporting and filtering) and optionally to Zendesk Group if the customer wants agent-level channel assignment replicated. The mapping choice is confirmed during scoping based on whether agents currently monitor channels directly or rely on Keeping's routing.

Keeping stores priority (low/medium/high), assignee (Slack user), and status (open/resolved) as thread metadata. We map these to Zendesk Ticket priority (low/normal/high/urgent), the assignee to a Zendesk User lookup (resolved by email match), and status to Zendesk ticket_status (new/open/pending/on-hold/solved/closed). If Keeping uses custom status labels, we map them to the closest Zendesk status and document deviations.

We preserve original ticket creation time and last modification time from Slack thread metadata as Zendesk created_at, updated_at, and last_activity_at. This ensures SLA calculations in Zendesk can reference accurate historical timestamps. If Slack export truncates timestamps to dates only, we flag the granularity reduction for the customer's admin to adjust SLA policy thresholds accordingly.

Files attached to Slack thread messages may or may not survive Keeping's export depending on export format completeness. We attempt to extract attachment URLs and re-upload to Zendesk as ticket comments with file attachments. Any attachments that cannot be recovered from the export are logged in a separate asset reconciliation document with original Slack message links and filenames for manual retrieval from Slack's native file storage.

Keeping has no Knowledge Base. Zendesk Guide is activated during migration prep so that articles can be created post-migration. We do not migrate knowledge base content because none exists in Keeping. We document the Zendesk Guide setup steps (activating Help Center, creating sections and categories) for the customer's admin to populate after migration. If the customer has external documentation (Notion, Google Docs, Confluence), we can provide a content import mapping template for manual article creation.

Keeping has no triggers, macros, or automated workflows. Zendesk triggers, macros, and SLA policies do not migrate because they are configuration objects, not data. We deliver a written inventory template listing every recommended Zendesk trigger (auto-assign based on keywords, auto-tag based on channel, SLA escalation notifications), macro (common response templates), and SLA policy (first reply time, next reply time, resolution time) for the customer's admin to configure post-migration based on their operational requirements.

Keeping provides no reporting or analytics. Zendesk Explore (included from Suite Growth) provides pre-built CX dashboards for ticket volume, response time, CSAT, and agent performance. We do not migrate reports because none exist in Keeping. We configure the Explore workspace post-migration and provide a setup guide for the pre-built dashboards aligned to standard support KPIs.

Each Slack message in a Keeping thread becomes a Zendesk Ticket comment. The message author maps to the Zendesk User (requester for customer messages, agent for support responses). We preserve message timestamps and content verbatim where the Slack export supports it. Rich text, emoji reactions, and thread replies nested deeper than one level are flattened into the main comment thread with attribution preserved.