Migrate from OTRS to Gorgias

OTRS Tickets map to Gorgias Tickets as the primary object. We extract Title, State, Priority, Queue (mapped to Team), Owner (mapped to Agent), CustomerID (mapped to Customer), and created/updated timestamps. OTRS ticket number becomes the Gorgias external_id for reference. Article history (email, notes, external replies) migrates as message threads attached to the ticket conversation.

OTRS Articles (email, internal notes, external replies) map to Gorgias Messages inside each Ticket conversation. We preserve the article body content, content-type (text/plain or text/html), sender type (agent or customer), and timestamp. HTML articles are converted to plain text with link preservation where possible. Attachments associated with each article are extracted as binary blobs and reattached to the corresponding Gorgias message.

OTRS Customer records (stored separately from tickets in the customer_user table) map to Gorgias Customers. We extract name, email, phone, language, and customer type. OTRS customers without tickets are included in the export pass. Email address serves as the dedupe key during Gorgias import. Timezone and language preference migrate to the corresponding Gorgias customer fields.

OTRS Dynamic Fields are stored as entity-attribute-value rows across separate tables (dynamic_field and dynamic_field_value). We enumerate all defined field names, data types (Text, Date, Dropdown, Checkbox, Multiselect, Integer, Decimal), and current values during scoping. Each Dynamic Field becomes a typed Gorgias Custom Field on the Ticket or Customer object. Dropdown fields in OTRS require pre-creating the corresponding option list in Gorgias before import. Multiselect fields migrate to Gorgias as multi-value custom fields where supported.

OTRS Queues (defining ticket routing and access boundaries) map to Gorgias Teams. We export queue names, assignment rules, and linked SLA configurations. Multi-queue hierarchies in OTRS (queues inside queues) are flattened into a single team list in Gorgias. Queue-based access controls (which agents can see which queues) map to Team membership in Gorgias, where agents belong to one or more teams and ticket assignment follows team routing rules.

OTRS SLA definitions (response time and solution time linked to queues and ticket types) become Gorgias Rules with time-based triggers. We export SLA names, first response thresholds, update thresholds, and solution time thresholds as metadata. Each SLA becomes a Gorgias Rule that applies a priority level or assigns the ticket to a specific team based on the SLA condition. Complex multi-step escalation paths in OTRS SLA are documented as a multi-rule chain in Gorgias for admin rebuild.

OTRS CMDB Configuration Items (class-based assets with attributes, linked to tickets via the link_item table) do not have a native equivalent in Gorgias. We export CI data (name, class, serial number, attributes) and the CI-to-Ticket linking table. CIs migrate as Customer records with custom fields capturing CI attributes (serial number, asset tag, product category). The CI-to-Ticket relationship is preserved as a custom field on the Gorgias Ticket referencing the external CI identifier. If the customer requires a full CMDB in the destination, we document the CI schema for rebuild in a dedicated IT asset management tool.

OTRS Process Management stores multi-step ITSM workflows as XML definitions with activity nodes, transition rules, and conditional branching. These are not migratable to Gorgias Macros and Rules because Gorgias automation operates on single-ticket triggers rather than multi-step state-machine processes. We export the full workflow XML, replay the state transitions as they occurred on each historical ticket, and deliver a written inventory of every Process Management definition with its activity nodes, transition conditions, and recommended Gorgias Rule equivalent. The customer's admin rebuilds these post-migration.

OTRS Agents (tied to roles, groups, and queues via separate permission tables) map to Gorgias Agents. We export the agent user record and reconstruct ownership and assignment relationships. Agents are matched to Gorgias users by email address. Any OTRS agent without a corresponding Gorgias user goes to a reconciliation queue for the admin to provision. Role-based access controls (which roles grant which permissions) are documented separately because Gorgias uses a simpler team-based permission model without OTRS-style granular role and group scoping.

OTRS Attachments are stored as binary blobs linked to ticket articles in the database. We extract each blob with its filename, MIME type, and article association. Attachments are re-uploaded to the corresponding Gorgias message record during import. Large attachments (exceeding Gorgias API upload limits) are flagged during scoping for manual re-upload or alternative storage (S3 presigned URL) with the link preserved in the message body.

OTRS Services define available offerings linked to SLAs and queues. We export service definitions and their SLA associations. Gorgias does not have a native service catalog; service offerings are handled through Rules that categorize tickets by type and apply the corresponding SLA or routing. We map each OTRS Service to a Gorgias Rule condition set (ticket tag, subject keyword, or custom field value) for admin rebuild.

OTRS reporting stores report definitions and rendered output in the database. These are proprietary to OTRS and cannot be directly imported into Gorgias. We export report names, column definitions, and filter configurations as a written inventory for the customer's admin to recreate in Gorgias Reports or a third-party BI tool (Gorgias connects to native reporting and can export to Google Sheets, Amplitude, or a data warehouse for advanced analytics).