Helpdesk migration
Field-level mapping, validation, and rollback between Chatwoot and Salesforce Service Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Service Cloud.
Chatwoot
Source
Salesforce Service Cloud
Destination
Compatibility
8 of 11
objects map 1:1 between Chatwoot and Salesforce Service Cloud.
Complexity
BStandard
Timeline
3-6 weeks
Overview
Moving from Chatwoot to Salesforce Service Cloud is a structural migration from a developer-friendly support tool into an enterprise CRM with service built in. Chatwoot organizes support around Inboxes and Conversations; Salesforce Service Cloud uses Cases with OmniChannel routing and a 360-degree customer view that pulls service data alongside sales, marketing, and ERP records. We resolve that schema difference by mapping Chatwoot Conversations to Salesforce Cases, Inboxes to OmniChannel Work Item Types, and preserving the full message thread as Case Thread Entries linked to the correct Contact. Chatwoot custom attributes attach to Conversations or Contacts and require pre-creation of matching custom fields in Salesforce before any data lands. Automation Rules, SLA Policies, and Help Center articles do not migrate as code; we deliver a written inventory of each for the customer's admin to rebuild in Salesforce Flow, Entitlement Processes, and Knowledge Base.
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
Chatwoot platform overview
Scorecard, SWOT, gotchas, and pricing for Chatwoot.
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 Chatwoot 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.
Chatwoot
Contact
Salesforce Service Cloud
Contact
1:1Chatwoot Contact records map directly to Salesforce Contact. We use email as the dedupe key. Custom attributes stored on Chatwoot Contacts require pre-creation of matching custom fields on the Salesforce Contact object before import. The Chatwoot contact name, email, phone, and any identifier fields map to the equivalent Salesforce Contact fields. The customer's Account must exist before Contact import so that the AccountId Lookup relationship is satisfied at insert time.
Chatwoot
Conversation
Salesforce Service Cloud
Case
1:1Chatwoot Conversations are the primary migration unit and map to Salesforce Cases. The Chatwoot conversation status (open, resolved, pending) maps to Salesforce Case Status values that we configure in the destination org during schema setup. Priority, assignee, and team assignments transfer to Case Priority, OwnerId, and Queue membership respectively. Closed-at timestamp from Chatwoot maps to Salesforce Case ClosedDate.
Chatwoot
Message
Salesforce Service Cloud
EmailMessage + Case Thread
1:1Chatwoot Messages belong to a Conversation and carry content, sender_type (agent or customer), created_at timestamp, and attachments. We preserve message order by created_at timestamp and insert them as Case Thread Entries in Salesforce, which renders them as a chronological message log inside the Case. Attachments migrate as ContentDocument records linked via ContentDocumentLink to the Case. Private notes from Chatwoot (agent-only visibility) map to Case internal comments using Salesforce CaseComment with IsPublished=false.
Chatwoot
Label
Salesforce Service Cloud
Case Tag or Custom Picklist
lossyChatwoot Labels are string tags applied to Conversations. We export the full label taxonomy and re-apply them to migrated Cases. In Salesforce, labels can map to a Case Tag (if the destination org has Tags enabled) or to a custom multi-select picklist field on Case that we create during schema setup. The customer's admin chooses the strategy during scoping based on whether they use Tags or prefer a structured picklist.
Chatwoot
Agent
Salesforce Service Cloud
User
1:1Chatwoot Agents map to Salesforce Users by email match. Role and availability status from Chatwoot transfer to Salesforce UserRole and IsActive. We resolve every Chatwoot agent email against the destination org's User table before migration. Any agent without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision. Chatwoot role names (agent, administrator) map to the closest Salesforce profile or permission set equivalent.
Chatwoot
Inbox
Salesforce Service Cloud
OmniChannel Work Item Type + Channel
lossyChatwoot Inboxes represent channels (Website Live Chat, Email, WhatsApp, Facebook, Twitter, API). Channel configuration credentials (webhook URLs, page tokens, WhatsApp template IDs) are platform-bound and do not transfer. We create corresponding OmniChannel Work Item Types in Salesforce and document which Chatwoot channel maps to which Salesforce Channel for the customer's admin to reconnect during post-migration setup. This is a mapping documentation exercise, not a data migration.
Chatwoot
Team
Salesforce Service Cloud
Queue or Group
lossyChatwoot Teams are available on Business and Enterprise tiers and group agents for routing. If the source is on Hacker or Startups tier, no Teams exist and this step is skipped. Teams that exist migrate as Salesforce Queues (for case routing) or Groups (for reporting). We create matching Queue structures in Salesforce and assign the migrated Agent-User records to the correct Queue based on the Chatwoot team membership.
Chatwoot
Custom Attributes (Conversation-scoped)
Salesforce Service Cloud
Custom Fields on Case
1:1Chatwoot custom attributes attached to Conversations map to custom fields on the Salesforce Case object. We pre-create each Chatwoot custom attribute in Salesforce during schema setup, matching the Chatwoot type (text, number, dropdown, checkbox) to the nearest Salesforce field type. Values migrate as raw data during the Case import phase. Any attribute with a dropdown source of values must have its picklist values created in Salesforce before migration begins.
Chatwoot
Custom Attributes (Contact-scoped)
Salesforce Service Cloud
Custom Fields on Contact
1:1Chatwoot custom attributes attached to Contacts map to custom fields on the Salesforce Contact object. We pre-create the schema in Salesforce before Contact import and migrate values directly. Downstream automations in Salesforce that reference these custom fields must be configured by the customer's admin post-migration; we document the field names and data types in the field inventory deliverable.
Chatwoot
Canned Responses
Salesforce Service Cloud
Quick Text or Email Template
1:1Chatwoot Canned Responses with shortcut codes map to Salesforce Quick Text (for agent-side suggestions during case resolution) or Email Templates (for outbound case communication). The migration approach is chosen during scoping based on how the customer uses Canned Responses. Content and shortcut triggers migrate directly; the customer's admin assigns keyboard shortcuts in Salesforce post-migration.
Chatwoot
Help Center Articles
Salesforce Service Cloud
Knowledge Article
1:1Chatwoot Help Center Articles (available on Startups tier or above) migrate to Salesforce Knowledge Base articles. We export the full article tree including title, body (markdown converted to Salesforce rich-text format), category, and locale. Knowledge Article types must be created in Salesforce before import. Articles with draft or archived status in Chatwoot migrate with the equivalent publish status in Salesforce. Locale mapping requires admin confirmation of the destination Salesforce org's supported languages.
| Chatwoot | Salesforce Service Cloud | Compatibility | |
|---|---|---|---|
| Contact | Contact1:1 | Fully supported | |
| Conversation | Case1:1 | Fully supported | |
| Message | EmailMessage + Case Thread1:1 | Fully supported | |
| Label | Case Tag or Custom Picklistlossy | Fully supported | |
| Agent | User1:1 | Fully supported | |
| Inbox | OmniChannel Work Item Type + Channellossy | Fully supported | |
| Team | Queue or Grouplossy | Fully supported | |
| Custom Attributes (Conversation-scoped) | Custom Fields on Case1:1 | Fully supported | |
| Custom Attributes (Contact-scoped) | Custom Fields on Contact1:1 | Fully supported | |
| Canned Responses | Quick Text or Email Template1:1 | Fully supported | |
| Help Center Articles | Knowledge Article1:1 | Mapping required |
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.
Chatwoot gotchas
Hacker plan 30-day data retention permanently deletes conversations
Free plan limits silently block new inboxes and agents
Captain AI credits bill at $20 per 1,000 beyond the monthly allocation
Database schema inconsistencies on stable tags v4.2–v4.4
Automation Rules and SLA Policies are tier-gated and cannot export from lower plans
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 plan-tier audit
We audit the source Chatwoot account across plan tier, Inbox count, conversation volume, agent count, custom attribute definitions (with their types), label taxonomy, Teams presence, Help Center article count, and whether Automation Rules and SLA Policies exist. We check account creation date to confirm whether 30-day Hacker retention has already deleted historical conversations. This output is a written migration scope with record counts per object, a list of objects that will not migrate, and a confirmation of which Chatwoot plan the customer needs to be on before export begins.
Schema design and Salesforce field pre-creation
We design the destination schema in Salesforce. This includes pre-creating all Chatwoot custom attributes as custom fields on Case and Contact with matching field types, creating Case Status values that mirror Chatwoot conversation status, building OmniChannel Work Item Types for each Chatwoot Inbox, creating Queue structures for Chatwoot Teams, configuring the Account-Contact hierarchy decision, and setting up Knowledge Article types for Help Center articles. Schema is deployed into a Salesforce Sandbox first for validation. No data loads until schema is confirmed by the customer's admin.
Sandbox migration and reconciliation
We run a full migration into a Salesforce Sandbox using production-like data volume. The customer's support operations lead reconciles record counts (Cases in, Contacts in, Messages in, Labels in), spot-checks 25-50 random Cases against the Chatwoot source for message thread completeness and chronological ordering, and validates that custom attribute values landed in the correct Salesforce fields. Sign-off on the sandbox migration is required before production migration begins.
Account-Contact hierarchy resolution
We resolve the Account-Contact hierarchy before any Contact import. If Chatwoot Companies exist, we migrate them as Salesforce Accounts using domain or name as the dedupe key. Chatwoot Contacts without a Company association are either linked to a default Account (customer-confirmed during scoping) or held in a reconciliation queue for the admin to assign an Account. This step must complete before Contact insert because Salesforce requires AccountId on Case creation when Entitlements are in use.
Production migration in dependency order
We run production migration in record-dependency order: Accounts (from Chatwoot Companies if present), Contacts (with AccountId resolved), Cases (with ContactId, OwnerId, and Queue membership resolved), Message threads (Case Thread Entries preserving chronological order by created_at timestamp, with attachments as ContentDocument), Labels (applied to migrated Cases), Canned Responses (as Quick Text or Email Templates), Agents (as Salesforce Users with role mapping), Teams (as Queues), Help Center Articles (as Knowledge Articles), and custom attribute values (last, because they reference Case and Contact IDs resolved in prior phases). Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, validation, and automation rebuild handoff
We freeze Chatwoot writes during cutover, run a final delta migration of any records modified during the migration window, then enable Salesforce as the system of record. We deliver the Automation Rules and SLA Policies inventory document to the customer's admin team with recommended Salesforce Flow and Entitlement Process equivalents. We support a one-week hypercare window where we resolve reconciliation issues raised by the support team. We do not rebuild Chatwoot Automation Rules as Salesforce Flow inside the migration scope; that is a separate engagement or an internal admin task.
Platform deep dives
Chatwoot
Source
Strengths
Weaknesses
Salesforce Service Cloud
Destination
Strengths
Weaknesses
Complexity grading
Standard Helpdesk migration. 1 of 7 objects need a manual workaround.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Chatwoot 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
Chatwoot: Not publicly documented.
Data volume sensitivity
Chatwoot 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 Chatwoot to Salesforce Service Cloud migration scoping. Not seeing yours? Book a call.
Walk through your Chatwoot 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 Chatwoot
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.