Migrate from iService to Gorgias

iService Tickets map directly to Gorgias Tickets. The iService ticket status (Open, Pending, Resolved, Closed) maps to Gorgias Ticket status values which we configure during schema setup. iService priority (Low, Normal, High, Urgent) maps to Gorgias priority. The ticket subject and body transfer as-is. Custom Ticket Fields in iService require pre-creation in Gorgias as Custom Fields with matching object_type (ticket) and external_id for cross-system reference, then values are mapped during import. iService ticket ID is preserved as an external_id field for audit trails.

iService Customer records (end-user contacts with name, email, phone, language, timezone, and custom properties) map to Gorgias Customer. The iService email field becomes the Gorgias Customer email for deduplication. Custom properties on iService Customers migrate as Gorgias Custom Fields on the customer object_type. Timezone and language values transfer to the corresponding Gorgias Customer attributes.

iService Company records represent organizations associated with multiple customer accounts. We map Companies to Gorgias Customers and set the company attribute on each related Customer record. Company-level custom properties become Custom Fields on the customer object_type in Gorgias. If iService stores a separate company ID, we preserve it as external_id on the Gorgias Customer record for cross-reference.

Each iService Ticket contains a threaded Conversation history. Messages from the customer and from agents transfer to the Gorgias Ticket as message records preserving the sender (customer vs agent), message body, and timestamp. The Gorgias API creates messages attached to the parent Ticket. We resolve the agent reference by matching iService agent email to the Gorgias user mapping before message import.

iService live chat transcripts are stored as conversation records tied to a Customer. We flag chat sources during the data audit phase because transcript format varies depending on whether the chat originated from the embedded portal widget or a third-party channel integration. Chat sessions transfer to Gorgias as Tickets with channel set to chat, preserving the transcript as message thread content. If the transcript format is unstructured (non-widget source), we map it as a single message with the full transcript body.

iService Custom Ticket Fields vary by tenant configuration and include string, boolean, date, and number field types. We create matching Gorgias Custom Fields before ticket import using the Gorgias CustomField API object, setting external_id to the iService field name for traceability. Field value transformation handles data type differences: iService string fields map to Gorgias text, boolean to boolean, date to date, and number to number. We flag any fields with conditional visibility rules for manual configuration in Gorgias post-migration.

iService stores custom properties on Customer records beyond the standard set. These map to Gorgias Custom Fields on the customer object_type. Creation order matters: we pre-create all customer Custom Fields in Gorgias before importing Customer records so that field values are accepted during insert. Custom field labels are preserved from iService; if a label conflicts with a Gorgias reserved field name, we append a suffix and document the rename.

iService Agent accounts include email, name, role, and team assignment. We map agents to Gorgias Users by email match. Role structures differ — iService roles (Agent, Supervisor, Admin) map to a standard Gorgias agent role, and team assignments map to Gorgias teams that we create before user import. We flag any iService role with permissions that exceed standard Gorgias agent permissions (such as admin-level configuration access) for explicit review during scoping.

Tags in iService label tickets and articles. We migrate tags as Gorgias Tags and remap tag associations to the parent Ticket or article. Tag naming conventions between source and destination may differ, so we preserve the original iService tag name as the tag label in Gorgias and document any naming normalization applied during the transform phase.

File attachments on iService tickets and Knowledge Base articles migrate as binary blobs referenced by the parent record. We preserve attachment filenames and link them to the correct ticket or article in Gorgias. If iService attachments are hosted at URLs accessible during migration, we re-upload to Gorgias storage; if they require extraction from a database export, we include them in the migration package with filename and parent-record reference preserved.

iService KB Articles contain content, categories, and attachments. We export articles as HTML and map iService KB Categories to Gorgias Help Center categories. Article attachments follow the attachment migration logic. Content structure (headers, lists, embedded images) maps to Gorgias article HTML format. We deliver a written inventory of the article hierarchy including category names, article count per category, and any attachment dependencies so the customer's admin can recreate the structure in Gorgias Help Center.

iService Workflows define ticket routing, status changes, and notification triggers. We do not migrate Workflows as code because they are tightly coupled to iService's internal routing engine. During scoping, we document every active Workflow with its trigger conditions, actions, and any dependent custom fields. We deliver this as a written inventory with recommended Gorgias Rules and Macros equivalents so the customer's admin can rebuild the logic post-migration. The customer portal configuration (branding, domain settings, visibility rules) is also excluded and documented as not migratable.