Migrate from Keeping to Intercom

Keeping Tickets map directly to Intercom Conversations. The Slack thread timestamp becomes the Intercom created_at on the Conversation. Thread messages migrate as Conversation Parts, with the message body, author (agent or customer), and timestamp preserved. Internal notes in Keeping (visible only to agents) migrate as internal Conversation Parts. Closed ticket status maps to Intercom Conversation state with the original close timestamp preserved. We extract the Slack thread ID as an external reference for audit purposes.

Keeping does not store a standalone customer record — the customer is inferred from the Slack thread requester. We reconstruct the Contact by extracting the requester's email, name, and any metadata (company name, plan tier, user ID) from every ticket they opened. Email becomes the Contact email field and dedupe key. Company name, if present in ticket metadata, becomes an Account in Intercom with a Contact-to-Account link. If no company data is present, contacts are created without an Account link and flagged for the customer to enrich post-migration.

Keeping Slack Channels map to Intercom Inbox Teams. We extract the full list of Keeping Slack Channels during scoping and map each to a corresponding Intercom Team. Channel membership (who has access to which channel in Slack) maps to Inbox Team membership in Intercom. If Keeping used channel naming conventions for routing (e.g., #support-tier1, #support-tier2), we create corresponding Teams and configure routing rules in Intercom during schema setup.

Keeping assigns tickets by Slack user (who responded in the thread). We extract the assignee from the first agent response in each thread and map to an Intercom Admin by email lookup. If the assignee has no Intercom account, they go to a reconciliation queue for the customer to provision before migration. Slack bots and automated responders (e.g., Slackbot) without a human owner are flagged as unmapped and excluded from assignee mapping.

Keeping ticket open/closed state maps to Intercom Conversation state (open, closed, snoozed). If Keeping used a multi-status workflow (e.g., pending customer, resolved, escalated), we map those to Intercom Conversation states and create a custom conversation attribute to carry the original Keeping status label for audit. Snooze timestamps from any snooze feature in Keeping migrate as Intercom Snoozed Until timestamps.

If Keeping tickets contained tags (applied manually or by automation), these migrate as Intercom Contact Tags. We extract unique tags across all tickets, create the corresponding tags in Intercom, and apply them to the relevant Contact records. Tags that are purely ticket-level (not customer-level) are applied to the Conversation as tags. The customer chooses during scoping whether to apply tags to Contacts, Conversations, or both.

Slack message attachments (images, PDFs, files) within Keeping threads migrate as Intercom Conversation Part attachments. We flag unsupported file types (.exe, .sys, .scr, .shb, .wsf and others restricted by Intercom) as unmapped and excluded. If Keeping used Slack message reactions as a proxy for satisfaction voting, we do not migrate reactions — satisfaction ratings require Intercom CSAT configuration post-migration. Image attachments within the thread migrate if under Intercom's supported size limits.

If Keeping used priority labels (urgent, high, normal, low) as part of ticket metadata or Slack thread subject prefixes, we create a custom conversation attribute in Intercom called keeping_original_priority__c and populate it from the ticket data. This preserves the original priority for reporting without forcing a priority system redesign during migration.

Keeping supports custom fields on tickets (e.g., product area, plan tier, bug severity). We audit all custom fields during scoping, create matching custom attributes in Intercom (as Contact attributes if the field is customer-scoped, or Conversation attributes if ticket-scoped), and populate them during migration. Field type mapping follows Intercom's supported attribute types: text, number, boolean, date, single-select, and multi-select.

Keeping has no native Company object; company data, if present, lives in ticket metadata (e.g., the customer's company name in a Slack thread or a custom field). We extract unique company names from ticket records, create Intercom Accounts for each, and link the corresponding Contacts. Accounts without a company name in ticket metadata are created as placeholder records or left unlinked based on the customer's preference during scoping. Account creation must precede Contact creation to satisfy the Account-Contact lookup relationship.