Migrate from HelpDeskZ to Zendesk

HelpDeskZ tickets map directly to Zendesk tickets. We extract ticket id, subject, status (integer code), priority (integer code), created date, updated date, and assigned agent id from the MySQL tickets table. The Zendesk API creates tickets via POST /tickets with the requester mapped from the ticket's client_id to a Zendesk user. Historical ticket IDs are preserved in a custom field hdz_original_id__c for cross-reference after cutover.

HelpDeskZ stores each reply as a separate row in the ticket_replies table linked by ticket_id. We extract rows in chronological order by the created timestamp, distinguish agent replies from client replies using the role column, and insert them as Zendesk ticket comments via POST /tickets/{id}/comments. The Is-Public flag on each comment is set based on the HelpDeskZ reply visibility setting.

HelpDeskZ agents from the users table with role=admin or role=agent map to Zendesk Users with the agent role. We match by email address and set the user name, email, and role. If a Zendesk user with the same email already exists, we link the HelpDeskZ agent to the existing Zendesk user rather than creating a duplicate. Agents without an email in HelpDeskZ receive a placeholder email during migration for the customer's admin to correct.

HelpDeskZ clients (role=client) map to Zendesk end-users. We extract name and email from the users table and create Zendesk users via POST /users. The hdz_client_id__c custom field stores the original HelpDeskZ user ID for reconciliation. If the email is blank or generic (e.g., noreply@), we flag the record and the customer decides whether to create a placeholder or skip the user.

HelpDeskZ departments exist as a simple id-name lookup table. We map each HelpDeskZ department to a Zendesk Group via the Groups API. If Zendesk Groups do not yet exist at migration time, we create them first so that ticket assignments can reference valid group IDs during import. Teams that use Zendesk Groups for routing will need to reassign tickets to the correct groups post-migration if department-to-group mapping is not one-to-one.

HelpDeskZ stores uploaded files on disk in the uploads/ directory with only filenames referenced in the tickets and replies tables. We locate the uploads directory via the uploads_path configuration value, validate that each referenced file exists, and upload files to Zendesk via POST /tickets/{id}/attachments for ticket-level attachments or POST /users/{id}/avatar for user avatars. Files that cannot be located are logged as warnings and skipped to allow migration to proceed without blocking on a single missing attachment.

HelpDeskZ custom fields are stored as a PHP serialized string in the custom_fields column of the tickets table. We detect the PHP version on the source server, apply the correct unserialize() call, extract each key-value pair, and map each to a corresponding Zendesk custom field created via POST /tickets/{id}/fields or POST /users/{id}/tags. Zendesk custom field IDs must exist in the destination before tickets are imported, so we create the Zendesk custom field schema first, then populate values during ticket import. Multi-select and checkbox values from HelpDeskZ migrate as Zendesk tags on the ticket.

HelpDeskZ stores status as integer codes (typically 0=Open, 1=Pending, 2=Resolved, 3=Closed) in the database. We map these integer codes to Zendesk ticket status values (open, pending, solved, closed). Customers who have added custom status values via the HelpDeskZ admin panel will have those integer codes flagged and remapped per a status mapping document agreed upon during scoping. Non-standard status values that cannot map to a Zendesk status default to open and are flagged for admin review.

HelpDeskZ stores priority as integer codes (typically 0=Low, 1=Normal, 2=High). We map these to Zendesk priority values (low, normal, high, urgent). If HelpDeskZ has fewer than four priority levels, the unused Zendesk priority values remain unmapped and the customer's admin sets a default priority during Zendesk configuration.

HelpDeskZ email-to-ticket routing is configured via POP3/IMAP mailbox settings stored in the database. We extract the source email address and mailbox configuration but do not migrate these settings to Zendesk because Zendesk's email routing is configured in the Zendesk Admin panel and involves domain verification and email forwarding rules. We deliver a written note identifying the HelpDeskZ source mailbox address so the customer's Zendesk admin can configure the corresponding Zendesk email endpoint. Message-ID and In-Reply-To threading references stored in HelpDeskZ are not valid in Zendesk and are not migrated; the raw email body content is preserved in the ticket comment.

HelpDeskZ does not include a built-in knowledge base module. If the customer has published help content elsewhere (a separate wiki, a document on the filesystem, or a third-party tool), that content does not migrate as part of the HelpDeskZ-to-Zendesk standard scope. We flag the absence of KB content during scoping and deliver a written recommendation that the customer export any external knowledge content and import it to Zendesk Guide separately using Zendesk's CSV article importer or API.