Migrate from Keeping to HubSpot Service Hub

Keeping Tickets map directly to HubSpot Tickets. We map ticket subject to hs_ticket_subject, ticket body to the conversation thread, and Keeping ticket status (open/pending/closed) to HubSpot hs_ticket_status. Any Keeping priority field maps to HubSpot hs_ticket_priority. Pipeline and pipeline stage are reconstructed from Keeping's Slack Channel assignment or manually assigned labels during scoping if no formal pipeline existed in Keeping.

Keeping has no independent contact table; every ticket requester is stored as metadata on the ticket itself. We extract all distinct requester email addresses and names from ticket records and create HubSpot Contact records. Each Contact is associated with the corresponding Ticket after the Contact import completes. Email address serves as the dedupe key.

Keeping routes tickets to Slack Channels. We map each distinct Keeping Slack Channel to a HubSpot Ticket Pipeline (if formal stage routing existed) or to a HubSpot Team for routing-based assignments. The customer defines the target pipeline structure during scoping. Slack Channel names are preserved as ticket tags for audit.

Keeping stores all conversation history inside Slack threads. We extract thread messages via Slack API or export and reconstruct them as HubSpot Help Desk conversation feed entries. Each message maps to a conversation message record with the original Slack timestamp preserved as the activity date. Agent vs customer message attribution is reconstructed from the Slack message sender.

Keeping ticket creation date, last update date, and any SLA milestone timestamps migrate to HubSpot Ticket standard properties. Original timestamps are preserved exactly to avoid breaking SLA reporting in HubSpot.

Keeping agents are Slack workspace members who have claimed or been assigned tickets. We extract agent email addresses from ticket assignment metadata and match against HubSpot Users by email. Any agent without a HubSpot User is placed in a reconciliation queue for the customer admin to provision before ticket import begins.

Keeping tickets may reference files attached in Slack threads. These assets are exported via Slack API and reattached to HubSpot Tickets as ContentDocument records linked via ContentDocumentLink. If a file is inaccessible via Slack API (message deleted, workspace archived), we flag it in the migration report for manual reattachment by the customer admin.

Keeping supports ticket tags or labels for categorization. These migrate to HubSpot Ticket tags. If Keeping uses labels inconsistently (a common data quality issue in small-team setups), we flag the variance during scoping and recommend a cleanup pass before migration.

Requester email addresses extracted from Keeping tickets map directly to HubSpot Contact email. This is the primary dedupe key. If a customer appears across multiple tickets, we create one Contact and link all associated Tickets.

Keeping has no Company object. During scoping, if the customer wants company-level reporting in HubSpot (tickets per customer account, CSAT per company), we enrich the Contact records by resolving email domain to a Company record in HubSpot. This step is optional and customer-driven.

Keeping does not have a native SLA engine. If the customer has informally tracked SLA via Slack thread timestamps, we document the existing response-time benchmarks and help configure HubSpot SLA policies during the post-migration setup phase. SLA configuration is not migrated; it is built fresh in HubSpot.

Keeping has no Knowledge Base. HubSpot Knowledge Base articles do not exist in Keeping and therefore cannot be migrated. We deliver a written content gap analysis that compares existing support documentation to the new HubSpot Knowledge Base schema and recommends an article structure for the customer admin to populate post-migration.