Helpdesk migration

Migrate from Kustomer to Salesforce Service Cloud

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 logo

Kustomer

Source

Salesforce Service Cloud

Destination

Salesforce Service Cloud logo

Compatibility

58%

7 of 12

objects map 1:1 between Kustomer and Salesforce Service Cloud.

Complexity

CModerate

Timeline

4-7 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Kustomer logo

Kustomer

What's pushing teams away

  • Performance degrades under high volume or when the platform handles large datasets, with agents reporting lag, slow loading, and occasional outages that disrupt daily operations.
  • Steep learning curve and complexity: reviewers describe the tool as confusing in some areas, requiring significant training investment before teams become productive.
  • Annual-only billing with an 8-seat minimum makes Kustomer uneconomical for small teams, and forces mid-market teams into a 12-month commitment before validating fit.
  • Separate AI pricing ($0.60 per conversation, $40/user/month for copilot) on top of the base seat cost creates billing surprises that inflate the effective per-agent price.
  • Technical issues on the back end occur regularly according to reviews, and while Kustomer support resolves most, the frequency of backend instability frustrates enterprise teams expecting reliability.

Choosing

Salesforce Service Cloud logo

Salesforce Service Cloud

What's pulling them in

  • Deep Salesforce ecosystem integration with Sales Cloud, Marketing Cloud, and custom Apex apps creates a single pane of glass for enterprise customer data and cross-functional workflows.
  • Omnichannel case routing — email, chat, phone, social, and messaging — unified under one case object means agents do not lose context when customers switch channels mid-interaction.
  • AI for customer service (Einstein AI / Agentforce) offers automated case classification, suggested replies, and chatbot routing that reduces Tier-1 ticket volume without manual rule authoring.
  • Entitlement and milestone tracking enforces SLA compliance natively, automatically calculating breach windows and surfacing violations to supervisors in dashboards.
  • Salesforce's massive AppExchange ecosystem provides pre-built connectors, industry-specific managed packages, and third-party tools that extend Service Cloud beyond its out-of-box capabilities.

Object mapping

How Kustomer objects map to Salesforce Service Cloud

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

maps to

Salesforce Service Cloud

Contact or Lead (split required)

1:many
Fully supported

Kustomer 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

maps to

Salesforce Service Cloud

Case

1:1
Fully supported

Kustomer 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

maps to

Salesforce Service Cloud

EmailMessage or CaseComment

1:1
Fully supported

Kustomer 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

maps to

Salesforce Service Cloud

Account

1:1
Fully supported

Kustomer 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)

maps to

Salesforce Service Cloud

User

1:1
Fully supported

Kustomer 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

maps to

Salesforce Service Cloud

Queue or Group

lossy
Fully supported

Kustomer 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

maps to

Salesforce Service Cloud

Email-to-Case, Web-to-Case, or Omni-Channel Channel

lossy
Fully supported

Kustomer'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)

maps to

Salesforce Service Cloud

Custom Object (__c)

1:1
Fully supported

Kustomer 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

maps to

Salesforce Service Cloud

Lookup or Master-Detail

lossy
Fully supported

Kustomer'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)

maps to

Salesforce Service Cloud

Custom Field

1:1
Fully supported

Kustomer 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

maps to

Salesforce Service Cloud

Multi-Select Picklist or Topic

lossy
Fully supported

Kustomer 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

maps to

Salesforce Service Cloud

ContentDocument (Files)

1:1
Fully supported

Files 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.

Gotchas + challenges

What specifically takes care here

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 logo

Kustomer gotchas

High

Annual billing with 8-seat minimum inflates entry cost

High

30-day CSV export cap limits conversation history

Medium

API rate limits vary by pricing tier

Medium

Custom KObject schemas must be manually recreated in the destination

Low

UTF-8 CSV encoding requirement can silently corrupt non-ASCII data

Salesforce Service Cloud logo

Salesforce Service Cloud gotchas

High

Data Export 512MB file size cap breaks large org exports

High

API Daily Request Limits vary by license edition

High

No automatic data backup in base Salesforce

Medium

Picklist dependencies silently break records when unmapped

Medium

Workflow rules fire unexpectedly during data load

Pair-specific challenges

  • 30-day CSV export cap limits conversation history

    Kustomer's built-in CSV export covers at most 30 days of data per run. Teams using Kustomer as a long-term knowledge base with years of conversation history will lose historical records unless a separate events-stream export contract is negotiated with Kustomer before migration. We discuss the events-stream option during discovery, recommend exporting in rolling 30-day tranches as a workaround, and document the 30-day window constraint clearly in the scope so the customer can make an informed decision on data completeness versus contract cost.

  • KObject schema must be manually recreated in Salesforce

    Kustomer's KObjects are defined per-organization with custom field schemas, relationships, and validations that have no direct Salesforce equivalent. We discover all KObject definitions during the pre-migration audit, document the field types and relationship graph, and recreate them as Salesforce Custom Objects with custom fields before any KObject records import. The destination schema must be validated and deployed to a Sandbox before production migration begins. Skipping this step results in schema mismatch errors and orphaned relationship records.

  • Salesforce validation rules and field-level security block bulk import

    Salesforce orgs commonly enforce required format validations, conditional required fields, and picklist whitelists that the migration user must bypass during data load. We coordinate with the customer's Salesforce admin to grant the migration user the Bulk API permission set and temporarily suspend validation rules using a migration-context check, or we extend validation rules with a bypass flag. Skipping this step results in 5-30 percent record rejection on the first import pass, requiring a retry cycle that extends the migration timeline.

  • Conversation-to-Case threading requires parent-record resolution

    Kustomer Messages must be linked to the correct Salesforce Case record using the CaseId lookup, and the ContactId must resolve to the Salesforce Contact record that corresponds to the original Kustomer Customer. We resolve these parent-record references during a pre-import mapping pass, building a cross-reference table of Kustomer IDs to Salesforce IDs before any child records (Messages, Attachments) are inserted. Without this resolution step, Messages land as orphaned records with no Case association.

  • Kustomer UTF-8 CSV encoding requirement can silently corrupt non-ASCII data

    Kustomer's CSV import requires files in UTF-8 encoding. Source systems frequently export in Windows-1252 or Latin-1, especially when Kustomer was integrated with older databases or legacy CRMs. We run encoding validation on every CSV before upload and re-encode to UTF-8 if we detect non-ASCII characters in customer names, company names, and message content. This prevents silent data corruption that would otherwise surface as garbled characters in Salesforce after migration.

Migration approach

Six steps for a successful Kustomer to Salesforce Service Cloud data migration

  1. 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).

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Context on both ends of the pair

Kustomer logo

Kustomer

Source

Strengths

  • Customer timeline unifies all interactions across every channel into one chronological record per customer.
  • KObject architecture is genuinely extensible, letting enterprises model any business event as a first-class object.
  • Automation handles ticket routing, SLA tracking, and customer tagging out of the box without code.
  • Deep Shopify integration (5.0-rated) lets agents act on orders, refunds, and cancellations inside the platform.
  • AI layer includes both customer-facing agents and rep copilot, available as a standalone enterprise platform.

Weaknesses

  • Annual-only billing with an 8-seat minimum creates a high-commitment entry point unsuitable for small or fast-scaling teams.
  • Performance issues under high data volumes or concurrent load reported across multiple enterprise reviews.
  • Steep learning curve and non-intuitive areas mean significant training investment is required for full team adoption.
  • AI capabilities are priced separately from the base platform, inflating the effective per-seat cost.
  • No public bulk API endpoint—migration relies on CSV export limited to 30 days of data unless a separate events-stream contract is in place.
Salesforce Service Cloud logo

Salesforce Service Cloud

Destination

Strengths

  • Enterprise-grade security, compliance certifications, and audit logging available across all paid editions with Shield offering enhanced event monitoring.
  • Scalable multi-tenant cloud architecture supporting orgs from 5 users to 150,000+ seat enterprises without infrastructure management overhead.
  • Omnichannel contact center unifying email, live chat, phone, messaging, and social into a single Case timeline per customer interaction.
  • Rich workflow automation via Salesforce Flow, Process Builder, and Apex triggers enabling complex case escalation, routing, and field updates.
  • Native AI capabilities (Agentforce / Einstein) for case auto-routing, classification, suggested responses, and chatbot escalation without third-party add-ons.

Weaknesses

  • Per-seat pricing model with no contact limits creates unpredictable cost scaling for large organizations adding many agents over time.
  • No automatic data backup — organizations must purchase a third-party backup solution or build manual Data Loader exports to protect against data loss from human error, failed deployments, or integrations overwriting records.
  • Steep learning curve for non-technical users requiring dedicated admin resources and formal training investment before teams reach productive velocity.
  • Annual contract requirements and limited pro-ration on exit create significant switching cost friction, especially for organizations evaluating alternatives mid-cycle.
  • Add-on licensing (CPQ, Einstein Activity Capture, Shield, Data Cloud) can double effective per-seat cost without clear documentation of which features are included in base tiers.

Complexity grading

How hard is this migration?

Moderate Helpdesk migration. 1 of 7 objects need a manual workaround.

C

Overall complexity

Moderate migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Kustomer and Salesforce Service Cloud.

  • Object compatibility

    C

    1 of 7 objects need a manual workaround.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    7-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    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

    B

    Kustomer doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Kustomer to Salesforce Service Cloud migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Kustomer to Salesforce Service Cloud data migrations

Answers to the questions buyers ask most during Kustomer to Salesforce Service Cloud migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most migrations land between four and seven weeks for accounts under 20,000 customers and 50,000 conversations with no custom KObjects or events-stream export. Migrations with multiple KObject schemas, large message histories (over 300,000 records), or complex conversation threading requiring parent-record resolution move to ten to sixteen weeks because of Bulk API time, KObject schema translation, and routing configuration rebuild scope.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Kustomer.
Land in Salesforce Service Cloud, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day