Migrate from HelpDeskZ to Intercom

HelpDeskZ tickets become Intercom Conversations via the Conversations API. The ticket subject maps to Conversation title, and all reply rows in the ticket_replies table are inserted as Message Parts ordered by timestamp. We batch messages per ticket and use the Intercom bulk insert endpoint where supported. Any ticket created_by reference to a HelpDeskZ user resolves to the corresponding Intercom Contact or Admin before the conversation insert.

HelpDeskZ users with role client map to Intercom Contacts. Users with role admin or agent map to Intercom Admins. We extract name, email, and created_at from the users table and insert via the Contacts API and Admins API respectively. The hashed password field is not migrated; Intercom uses its own authentication model. Any user referenced as a ticket requester but missing from the users table is created as a Contact with the email found in the ticket table.

HelpDeskZ departments are a flat id-name lookup table. We map each department id on HelpDeskZ tickets to an Intercom Team. If the customer has created more than one team in Intercom during provisioning, we use the department name as a tag on the conversation and also create a Team record for each distinct department value. If the destination workspace has no pre-created teams, we create them at migration time and assign the Admin records by role.

HelpDeskZ ticket_replies rows become Intercom Message Parts within the corresponding Conversation. We order by the created timestamp column to preserve chronological sequence. The is_client flag on each reply determines whether the message author is the Contact or the Admin side of the conversation. HTML content in the reply body is stripped to plain text unless the Intercom workspace has rich-text message support enabled.

HelpDeskZ custom fields are stored as a PHP serialized string in a single column. We detect the PHP version on the source server, apply the correct unserialization method, and extract each key-value pair. We create corresponding custom attribute definitions in Intercom (string, number, boolean, or date type) via the Attributes API before migration, then insert the values as conversation custom attributes at insert time. Corrupted serialized values are logged and skipped with a warning.

HelpDeskZ stores status as integer codes (Open=0, Pending=1, Resolved=2, Closed=3). We map these to Intercom conversation states: open (HelpDeskZ Open/Pending), resolved (HelpDeskZ Resolved), and closed (HelpDeskZ Closed). Customers with custom status values added to the database are flagged during scoping and mapped to the nearest Intercom state or a custom conversation attribute.

HelpDeskZ attachments live on the filesystem in the uploads/ directory with filenames stored in the tickets and replies tables. We locate the uploads directory via the uploads_path configuration value, validate each file exists, and upload to the Intercom attachments endpoint. The attachment is then associated with the parent message part. If a file is missing from the filesystem, we log a warning and skip it. Intercom restricts certain file types (.exe, .sys, .scr, .shb, .wsf) for security — these are skipped and listed in the migration report.

HelpDeskZ email-to-ticket settings store the source mailbox hostname, port, and credentials. We extract these fields and flag them as configuration metadata rather than migratable data. The email threading identifiers (Message-ID, In-Reply-To, References) stored in HelpDeskZ point to the HelpDeskZ mail system and are not valid in Intercom — we extract the raw email body and attachment filenames but do not preserve threading relationships. The customer configures an Intercom inbound address separately post-migration.

HelpDeskZ priority column holds integer values (Low=0, Normal=1, High=2, Urgent=3). We map these to Intercom conversation priority (urgent=true for High/Urgent values) or apply a priority tag. If the customer uses priority as a routing signal, we also create an Intercom Team assignment rule post-migration based on the migrated priority tag.

HelpDeskZ does not include a built-in knowledge base module. No KB articles exist in the source data to migrate. If the customer has published help content elsewhere, it must be migrated as unstructured content. Intercom Articles can be created manually post-migration, and the customer can populate them with content from any external source or documentation they have assembled.