Helpdesk migration
Field-level mapping, validation, and rollback between Kustomer and Salesforce Service Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Service Cloud.
Kustomer
Source
Salesforce Service Cloud
Destination
Compatibility
7 of 12
objects map 1:1 between Kustomer and Salesforce Service Cloud.
Complexity
CModerate
Timeline
4-7 weeks
Overview
Moving from Kustomer to Salesforce Service Cloud is a platform-type migration: Kustomer is a conversation-first customer service platform centered on a unified customer timeline, while Salesforce Service Cloud is a full CRM that puts Cases alongside Accounts, Contacts, and Opportunities in a single data model. Kustomer's Customer maps to Contact (or Lead for unconverted contacts), Kustomer's Conversation maps to Case with full Message history, and Kustomer's KObjects (custom extensible schemas) map to Salesforce Custom Objects after we pre-create the destination schema. Kustomer's 30-day CSV export window is a hard constraint on conversation history; we address this during discovery and recommend the events-stream export or rolling 30-day tranches. Routing rules, SLA policies, and automation workflows do not migrate because they are platform-specific configurations; we deliver a written inventory for the customer's admin to rebuild in Salesforce Flow. We use the Salesforce Bulk API 2.0 for large conversation histories and resolve parent-record lookups (CaseId, ContactId, AccountId) at migration time.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Source platform
Kustomer platform overview
Scorecard, SWOT, gotchas, and pricing for Kustomer.
Destination platform
Salesforce Service Cloud platform overview
Scorecard, SWOT, gotchas, and pricing for Salesforce Service Cloud.
Data migration guide
The complete Salesforce Service Cloud migration guide
Data model, import mechanisms, field mapping strategy, pitfalls, and cutover — by the engineers running it.
Destination checklist
Salesforce Service Cloud migration checklist
Pre- and post-cutover tasks for moving onto Salesforce Service Cloud.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Kustomer object lands in Salesforce Service Cloud, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Kustomer
Customer
Salesforce Service Cloud
Contact or Lead (split required)
1:manyKustomer Customers map to Salesforce Contact for converted customers and Salesforce Lead for contacts that have not yet been qualified into an Account relationship. We apply a split rule based on Kustomer's customer_type property and any associated Company link. Customers with a linked Company record become Contacts attached to an Account; unlinked Customers become Leads. The original customer_type and any lifecycle stage properties migrate as custom fields on both Lead and Contact for audit and reporting continuity.
Kustomer
Conversation
Salesforce Service Cloud
Case
1:1Kustomer Conversations are the primary ticket record and map directly to Salesforce Case. The Conversation status (Open, Done, Snoozed) maps to Salesforce Case Status with custom values preserving the original Kustomer state. The primary Customer record becomes the Case ContactId. Conversation priority maps to Case Priority. We preserve the conversation's created_at timestamp as the Case CreatedDate and replay all Messages against the Case.
Kustomer
Message
Salesforce Service Cloud
EmailMessage or CaseComment
1:1Kustomer Messages within a Conversation migrate to Salesforce EmailMessage records (for external channel messages: email, chat, social) or CaseComment records (for internal notes). The message author resolves to a Salesforce User (for agent messages) or Contact (for customer messages) by email match. The original message timestamp becomes the EmailMessage CreatedDate to preserve the chronological conversation timeline within the Case.
Kustomer
Company
Salesforce Service Cloud
Account
1:1Kustomer Companies map to Salesforce Account. The Company name becomes Account Name, and the Company domain becomes the Account Website field. We use the domain as a dedupe key during import. Account is created before any Customer-to-Contact migration so that the AccountId lookup is satisfied at Contact insert time.
Kustomer
User (Agent)
Salesforce Service Cloud
User
1:1Kustomer Users (agents) map to Salesforce User records by email match. Team memberships from Kustomer map to Salesforce Groups or Queues depending on whether the customer uses Salesforce Omni-Channel for routing. Any Kustomer User without a matching Salesforce User is held in a reconciliation queue for the customer's admin to provision before record import proceeds.
Kustomer
Team
Salesforce Service Cloud
Queue or Group
lossyKustomer Teams map to Salesforce Queues (for case assignment routing) or Groups (for organizational grouping). We configure the Queue with the Case object and all relevant record types during the schema setup phase. If the customer uses Kustomer's team-based SLA policies, we document the SLA thresholds for rebuild in Salesforce Entitlement Processes and Milestones.
Kustomer
Channel
Salesforce Service Cloud
Email-to-Case, Web-to-Case, or Omni-Channel Channel
lossyKustomer's Channel object (email, phone, chat, SMS, social) is a first-class record type. We map each Kustomer channel type to the equivalent Salesforce channel configuration: email maps to Salesforce Email-to-Case, chat maps to Embedded Chat or Experience Cloud, phone maps to Open CTI or a connected telephony integration. Any non-standard or app-added channels in Kustomer are flagged as requiring a custom Salesforce integration rebuild.
Kustomer
KObject (Custom Object/Klass)
Salesforce Service Cloud
Custom Object (__c)
1:1Kustomer KObjects are user-defined schemas with custom fields, relationships, and validations. We enumerate all KObject definitions during discovery, map field types to Salesforce equivalents (text fields to Text, numbers to Number, dates to Date, relationships to Lookup), and pre-create the destination custom object schema in Salesforce. KObject relationships (parent-child, many-to-many) map to Salesforce Lookup or Master-Detail fields as appropriate. Validation rules defined in Kustomer are documented for rebuild as Salesforce Validation Rules. The __c API name convention is applied per Salesforce standard.
Kustomer
KObject Relationship
Salesforce Service Cloud
Lookup or Master-Detail
lossyKustomer's custom relationships between Klasses (for example, Orders to Line Items) map to Salesforce Lookup fields if the related object can exist independently, or Master-Detail if the child record cannot exist without the parent. We map the relationship graph during discovery, configure the appropriate field type in Salesforce, and ensure referential integrity is maintained by sequencing the parent-object import before the child-object import.
Kustomer
Custom Attribute (Property)
Salesforce Service Cloud
Custom Field
1:1Kustomer custom attributes attached to any standard or KObject map to Salesforce custom fields. We enumerate all custom properties during discovery, map field types to Salesforce field types, and flag any unsupported field types (for example, validation-rule-constrained picklists or regex-validated text fields) for manual configuration review before migration. Custom fields are created in the destination schema before any data import begins.
Kustomer
Tag
Salesforce Service Cloud
Multi-Select Picklist or Topic
lossyKustomer tags applied across Conversations and Customers migrate to Salesforce multi-select picklist fields on the respective object. If the customer uses tags for content classification across many records, we evaluate Topic and TopicAssignment as an alternative, which supports cross-object tagging in Salesforce. The customer chooses the tag strategy during scoping based on their post-migration tagging workflow.
Kustomer
Attachment
Salesforce Service Cloud
ContentDocument (Files)
1:1Files attached to Kustomer Messages and Notes migrate to Salesforce ContentDocument records linked via ContentDocumentLink to the parent Case. We extract attachments from the Kustomer export, upload to Salesforce using the Connect API, and create ContentDocumentLink records pointing to the migrated Case and the relevant Message record. Attachments exceeding Salesforce file size limits (25 MB per file) are flagged for chunked upload or external storage.
| Kustomer | Salesforce Service Cloud | Compatibility | |
|---|---|---|---|
| Customer | Contact or Lead (split required)1:many | Fully supported | |
| Conversation | Case1:1 | Fully supported | |
| Message | EmailMessage or CaseComment1:1 | Fully supported | |
| Company | Account1:1 | Fully supported | |
| User (Agent) | User1:1 | Fully supported | |
| Team | Queue or Grouplossy | Fully supported | |
| Channel | Email-to-Case, Web-to-Case, or Omni-Channel Channellossy | Fully supported | |
| KObject (Custom Object/Klass) | Custom Object (__c)1:1 | Fully supported | |
| KObject Relationship | Lookup or Master-Detaillossy | Fully supported | |
| Custom Attribute (Property) | Custom Field1:1 | Fully supported | |
| Tag | Multi-Select Picklist or Topiclossy | Fully supported | |
| Attachment | ContentDocument (Files)1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Kustomer gotchas
Annual billing with 8-seat minimum inflates entry cost
30-day CSV export cap limits conversation history
API rate limits vary by pricing tier
Custom KObject schemas must be manually recreated in the destination
UTF-8 CSV encoding requirement can silently corrupt non-ASCII data
Salesforce Service Cloud gotchas
Data Export 512MB file size cap breaks large org exports
API Daily Request Limits vary by license edition
No automatic data backup in base Salesforce
Picklist dependencies silently break records when unmapped
Workflow rules fire unexpectedly during data load
Pair-specific challenges
Migration approach
Discovery and data export assessment
We audit the source Kustomer account for standard objects (Customers, Conversations, Messages, Companies, Users, Teams, Channels), all KObject definitions (schema, relationships, custom fields), custom attributes, tags, and attachment volume. We assess the data export method: if the customer has an events-stream contract with Kustomer, we plan a full historical export; if not, we document the 30-day window constraint, recommend rolling exports, and scope the gap in the written migration plan. The discovery output is a complete object inventory, data volume estimate, and a Salesforce edition recommendation (Digital Engagement starting at $25/user or Service Cloud with Full CRM at higher tiers).
Schema design and KObject translation
We design the Salesforce destination schema based on the Kustomer object inventory. This includes provisioning custom fields on Contact, Case, and Account; creating Salesforce Custom Objects to match each KObject schema; configuring Lookup and Master-Detail relationships to match the KObject relationship graph; setting up Record Types and Case Status values to map Kustomer conversation states; configuring Omni-Channel routing if the customer uses Kustomer's team-based routing; and documenting SLA policy thresholds for rebuild as Salesforce Entitlement Processes. Schema is deployed to a Sandbox first for validation before any data moves.
Sandbox migration and reconciliation
We run a full migration into a Salesforce Sandbox using production-like data volume. The customer's service operations lead reconciles record counts (Customers in, Contacts and Leads in, Cases in, Accounts in, Messages in), spot-checks 25-50 random Cases against the Kustomer source for field-level accuracy, and validates that the conversation timeline appears correctly in Salesforce. Any mapping corrections, schema gaps, or validation rule conflicts are resolved here before production migration begins.
Owner and User provisioning reconciliation
We extract every distinct Kustomer User referenced on Conversations, Messages, and routing rules and match by email against the Salesforce destination org's User table. Any Kustomer User without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision (active or inactive depending on whether the original agent is still employed). Team memberships map to Salesforce Queues and Groups. This step must complete before the production migration because Case OwnerId and UserId references are required on standard Salesforce Case fields.
Production migration in dependency order
We run production migration in record-dependency order: Accounts (from Kustomer Companies), Contacts (with AccountId resolved from the Company mapping), Leads (for unlinked Customers), Cases (with ContactId and OwnerId resolved), Messages (via Bulk API 2.0 with parent CaseId resolution), Custom Object records (after standard object import because KObjects often have Lookup fields to standard objects), Tags (applied after parent records exist), and Attachments (uploaded via Connect API and linked via ContentDocumentLink). Each phase emits a row-count reconciliation report before the next phase begins. We monitor Salesforce API rate limit headers continuously and throttle batch sizes to avoid 429 responses.
Cutover, delta sync, and automation rebuild handoff
We freeze Kustomer writes during cutover, run a final delta migration of any records created or updated during the migration window, then enable Salesforce Service Cloud as the system of record. We deliver a written inventory of all Kustomer routing rules, SLA policies, and automation configurations for the customer's admin to rebuild in Salesforce Flow, Entitlement Processes, and Omni-Channel Skills-Based Routing. We support a one-week hypercare window to resolve any post-migration reconciliation issues raised by the service team. We do not rebuild automations as code inside the migration scope.
Platform deep dives
Kustomer
Source
Strengths
Weaknesses
Salesforce Service Cloud
Destination
Strengths
Weaknesses
Complexity grading
Moderate Helpdesk migration. 1 of 7 objects need a manual workaround.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Kustomer and Salesforce Service Cloud.
Object compatibility
1 of 7 objects need a manual workaround.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Kustomer: Tier-based and not publicly documented; visible in response headers (x-ratelimit-limit, x-ratelimit-remaining) and Settings > Platform > Platform Usage.
Data volume sensitivity
Kustomer doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Kustomer to Salesforce Service Cloud migration scoping. Not seeing yours? Book a call.
Walk through your Kustomer to Salesforce Service Cloud migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Kustomer
Other ways to arrive at Salesforce Service Cloud
Same-Helpdesk migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.