Migrate from Keeping to Salesforce Service Cloud

Keeping Tickets map directly to Salesforce Case. The Keeping ticket subject becomes Case Subject, ticket body or first Slack message becomes Case Description, and Keeping's status (Open, Pending, Resolved, Closed) maps to Salesforce Case Status values we configure in the destination org during scoping. Ticket priority maps to Case Priority. We preserve the original Keeping ticket ID in a custom field keeping_ticket_id__c for reconciliation and cross-reference during the delta-migration window.

Keeping has no standalone Customer object — customer identity is stored as metadata inside each Ticket (typically email address, full name, and optionally company name). We extract all distinct customer email addresses across the ticket corpus, deduplicate, and create Salesforce Contact records. The Contact email field becomes the dedupe key. Where Keeping tickets have a company name but no email, we flag those records for manual review during scoping. Each Contact is created before the parent Case import so that the ContactId lookup is satisfied on Case insert.

Keeping tickets may carry a company name field that we extract to create Salesforce Account records as the Contact parent. Account.Name derives from the Keeping company field; Account.Website is derived from the email domain where present. Not all Keeping setups populate the company field consistently — we audit this during discovery and decide with the customer whether to create Accounts for every Contact or to allow Contacts without an Account (orphan-in-Salesforce permitted only if the customer's Service Cloud use case is pure support with no sales CRM overlap).

Keeping ticket conversation history lives as Slack messages inside a Slack channel thread. We export the full thread via Slack API, parse agent versus customer messages, and write them to Salesforce CaseComment records (visible in the Case's comments feed) or to EmailMessage records (if the conversation originated from or was threaded to email). Slack-attached files (images, PDFs, documents) cannot be exported via Slack API and are flagged in the scoping report as at-risk assets requiring manual retrieval before cutover. We do not migrate Slack messages as Salesforce Tasks because the sender-recipient model in Slack does not map cleanly to Task WhoId.

Keeping status values (typically Open, Pending, On Hold, Solved/Closed) map to Salesforce Case Status values we configure in the destination org's Case Status picklist during scoping. We recommend a direct mapping table agreed upon by the customer's admin before production migration. If Keeping uses custom status values beyond the defaults, we create corresponding Case Status values in Salesforce so no status is lost during import.

Keeping priority (Low, Normal, High, Urgent) maps to Salesforce Case Priority (Low, Medium, High, High) with a direct field-level mapping. No transformation required. We flag any Keeping priority value that has no direct Salesforce equivalent for admin review.

Keeping ticket assignees are Slack users. We resolve Slack user email addresses to Salesforce User records by email match during migration scoping. Any assignee without a matching Salesforce User is held in a reconciliation queue for the customer's admin to provision before the Case migration phase begins. Inactive Salesforce Users can receive Case ownership if the customer prefers to preserve historical assignment.

If Keeping uses tags or labels on tickets, we map these to a Salesforce custom multi-select picklist field on Case (keeping_tags__c) so that categorization is preserved for reporting and routing. The customer confirms tag strategy during scoping — if tags represent SLA tiers, we recommend mapping them to Salesforce Entitlement Processes instead.

Keeping's Slack channel for each ticket (e.g., #support-urgent, #support-billing) carries routing and team-scope context. We map Slack channel name to a Salesforce custom picklist field on Case (keeping_channel__c) or to Case Origin if the customer consolidates multiple Slack channels into a single Slack-integrated channel origin. This field is useful for historical segmentation in Service Cloud reports after migration.

Keeping ticket created_at and updated_at timestamps migrate to Salesforce Case CreatedDate and LastModifiedDate respectively. We use the Bulk API for Case insert with Datetime values in Salesforce ISO 8601 format. Timezone handling is documented — all timestamps are treated as UTC and converted to the destination org's timezone at import. We flag any timezone ambiguity in the Keeping source for admin review before migration.