Migrate from Kustomer to Gorgias

Kustomer Customer records map directly to Gorgias Customer records. Standard fields (name, email, phone, company) transfer as typed fields. Kustomer custom properties on Customer migrate to Gorgias Custom Fields on Customer, respecting Gorgias's limit of four active customer fields at a time. If the source has more than four customer-level custom properties, we work with the customer during scoping to determine which four carry the highest operational priority; excess fields are documented in the custom field inventory for the admin to manage post-migration.

Kustomer Conversation records map to Gorgias Ticket records. The conversation subject becomes the ticket subject; conversation status (Done, Open, Snoozed) maps to Gorgias Ticket status (Closed, Open, Pending). We preserve the original conversation timestamp as the ticket created_at value. A Kustomer Conversation may span multiple Channels (email, chat, SMS); in Gorgias, each channel is typically a separate Ticket, so we split the conversation by channel during import and create individual tickets linked to the same Customer record.

Kustomer Messages within a Conversation map to Gorgias Message records attached to the corresponding Ticket. Message content, author attribution, timestamp, and message type (customer, agent, internal note) transfer directly. Kustomer Notes on a Conversation map to Gorgias Messages with type = internal note, preserving the note content and timestamp against the correct ticket.

Kustomer's Channel model (email, phone, chat, SMS, WhatsApp, Facebook Messenger, Twitter) maps to Gorgias's supported channel types. We validate each active Kustomer channel against Gorgias's channel availability at the customer's plan tier. Non-standard or custom channels built via Kustomer's app framework require case-by-case review and may map to a generic channel type or be flagged for manual recreation in Gorgias.

Kustomer Users map to Gorgias Users by email address as the match key. Agent display names, roles (admin, agent), and team memberships transfer. Active and inactive status carries over; inactive Kustomer users are provisioned as inactive Gorgias users so that historical assignment records reference valid users.

Kustomer Teams map to Gorgias Teams for routing and queue management. We preserve team membership assignments on agent records during import. Kustomer's team-based routing rules do not migrate (Gorgias routing is rule-based rather than queue-based) and are documented as a separate rebuild item.

Kustomer Companies are business accounts linked to multiple Customers. Gorgias Customers can hold company information as a field on the Customer record. We map the primary Company name to the customer_company field on each Gorgias Customer and link secondary company associations through a custom text field if multiple affiliations exist.

Kustomer KObjects are user-defined schemas with custom field types and inter-object relationships. We discover all active KObject definitions during the pre-migration audit, document the field type, relationship cardinality, and any validation rules. We recreate KObject fields as Gorgias Custom Fields on the relevant entity (Ticket or Customer). One-to-many KObject relationships map to custom fields that hold reference identifiers; many-to-many relationships require custom field design review with the customer's admin before schema deployment.

Kustomer Tags applied across Conversations and Customers migrate to Gorgias Tags. Tags are preserved as-is with their original names, so historical tag-based filtering in Gorgias works identically to Kustomer after migration. Kustomer tag counts transfer without limit; Gorgias has no hard tag count ceiling.

Files attached to Kustomer Messages and Notes are extracted from the export, re-uploaded to Gorgias via the REST API, and linked to the parent Message record using Gorgias's attachment schema. File type, original filename, and MIME type are preserved. We flag any attachment exceeding Gorgias's file size limits for manual handoff.

Kustomer Routing Rules determine queue assignment based on conversation attributes. These are platform-specific configuration files that do not have a meaningful equivalent in Gorgias's rule-based routing model. We do not migrate them as code. We deliver a written inventory of every active Kustomer Routing Rule with its trigger conditions, assignment logic, and SLA policy, annotated with a recommended Gorgias Rule configuration. The customer's admin rebuilds routing rules in Gorgias during the post-migration setup phase.

Kustomer SLA Policies define first response and resolution time commitments per queue or conversation priority. Gorgias SLAs are configured at the rule or plan level and track time to first response and time to resolution. We do not migrate SLA definitions as code. We document the existing SLA policy matrix (priority level, first response SLA, resolution SLA) and deliver it as a configuration guide for the customer's admin to implement in Gorgias Settings.