Migrate from HelpDeskZ to Gorgias

HelpDeskZ tickets map to Gorgias tickets. We extract ticket_id, subject, priority (mapped to Gorgias priority), status (integer code remapped to Gorgias state), created datetime, and updated datetime. Each HelpDeskZ ticket's reply thread (stored as sequential rows in a separate replies table) is reconstructed in chronological order and inserted as individual message records in the Gorgias conversation via the /tickets/{id}/messages endpoint. We preserve the original ticket_created timestamp as a custom property for audit.

HelpDeskZ users with role=admin or role=agent map to Gorgias agents. We extract user_id, name, email, and role from the users table. We create the corresponding agents in Gorgias using the /agents endpoint with the same email as the identifier. HelpDeskZ admin users get Gorgias admin privileges; agent users get standard agent permissions. We set a temporary password for each migrated agent; the customer resets credentials during onboarding.

HelpDeskZ users with role=client map to Gorgias customers. We extract name, email, and created datetime. Gorgias deduplicates customers by email, so if a customer already exists from a previous import or live ticket, we update rather than duplicate. Phone and language data from HelpDeskZ map to the corresponding Gorgias customer fields if present in the source database.

HelpDeskZ departments (stored as a simple id-name lookup table) map to Gorgias Teams. We extract all distinct department assignments from tickets and create Teams in Gorgias with matching names. Tickets are then tagged with the appropriate Team via the ticket's dst_team_id field during import. Some HelpDeskZ setups use hierarchical departments; we flatten these to single-level Teams since Gorgias does not support nested team hierarchies.

HelpDeskZ stores ticket status as integer codes (e.g., 1=Open, 2=Pending, 3=Resolved, 4=Closed). We map these integer codes to Gorgias ticket states (open, pending, solved, closed) based on the customer's status configuration. If the customer has added custom status values beyond the defaults, we flag these during scoping and create a custom mapping table. Non-standard integer values are logged as warnings and mapped to the nearest Gorgias state.

HelpDeskZ stores custom field values in a PHP serialized string column on the tickets table (custom_fields). We detect the PHP version on the source server (PHP 7 vs PHP 8) and apply the correct unserialize method. For each ticket, we extract key-value pairs, create the corresponding custom property in Gorgias (string, number, date, or boolean type based on the extracted value), and attach it to the ticket at insert time. If a serialized value is corrupted or incompatible, we log it and skip that field.

HelpDeskZ saves uploaded files to the uploads/ directory on the filesystem with only the filename stored in the database. We verify the uploads directory path from the HelpDeskZ configuration, locate each referenced file, and upload it to Gorgias via the POST /upload endpoint before creating the ticket or message. The Gorgias attachment URL is then embedded in the appropriate message. Missing attachment files are logged as warnings and skipped; migration does not block on a single lost file.

When HelpDeskZ converts incoming emails to tickets, it stores Message-ID and In-Reply-To email headers in the database. These references are source-local and not valid in Gorgias. We extract the sender email address, subject, and body content from the raw email data stored in HelpDeskZ, but do not attempt to preserve the email threading relationships. The migrated ticket is attributed to the email channel in Gorgias with a note that the original threading context was not transferred.

HelpDeskZ does not include a built-in knowledge base module. If the customer has published KB content in a separate system, we can migrate it as unstructured text for manual re-creation in Gorgias Help Center. We do not count HelpDeskZ KB migration as a standard scope item because no KB object exists in the source database. The customer creates Help Center articles in Gorgias post-migration using the migrated ticket content as source material.

HelpDeskZ email-to-ticket relies on POP3/IMAP polling configured on the self-hosted server. This mailbox configuration is a server-level infrastructure setting that does not migrate to Gorgias. We document the source mailbox addresses and polling settings during scoping, but the customer configures a new connected inbox or SMTP integration in Gorgias Settings post-migration. The email address ownership must be updated in DNS to point to Gorgias instead of the HelpDeskZ server.

HelpDeskZ does not support workflows, automations, or sequences as a platform feature, so there are no automation records to migrate. Gorgias automations (Rules, Macros, Gorgias Automate) are created post-migration by the customer's admin using Gorgias's built-in editors. We deliver a written requirements document describing what automations the team should build based on the ticket patterns and team workflow observed in the migrated data.

HelpDeskZ does not include a built-in reporting dashboard. Historical ticket metrics (volume by status, response time, resolution time) are extracted from the tickets table as part of migration scoping. We deliver a data export of these metrics as a CSV for the customer to use as a baseline in Gorgias's built-in reporting. Gorgias's Support Performance Statistics and Live Statistics dashboards are configured post-migration by the customer's admin.