Migrate from HelpDeskZ to Zoho Desk

HelpDeskZ users table (name, email, role, hashed password) maps to Zoho Desk Agents. Role mapping: HelpDeskZ admin maps to Zoho Desk Administrator profile; HelpDeskZ agent maps to Zoho Desk Agent profile; HelpDeskZ client role maps to a Zoho Desk Contact if the customer uses Zoho's contact-facing portal, or is flagged for admin decision. We extract email as the primary match key and resolve against Zoho's Agent email field during import. HelpDeskZ password hashes do not transfer; agents receive Zoho Desk onboarding invitations at insert time.

HelpDeskZ departments table (id, name) maps to Zoho Desk Departments. Zoho Desk supports hierarchical sub-departments; if the HelpDeskZ instance uses a flat department list, we create top-level Departments in Zoho. If the ViktorNova fork has been used to create nested departments, we map to Zoho's sub-department hierarchy by parsing the parent_id column. Department-specific SLAs in Zoho Desk are flagged for the customer to configure post-migration as SLA policies require ZohoDesk Enterprise or the Service Plus bundle.

HelpDeskZ tickets table maps to Zoho Desk Tickets. The ticket subject maps to Subject, ticket content maps to Description, status (Open/Pending/Resolved/Closed as integer codes) maps to Zoho Desk Status using a remapping table defined at scoping, priority maps to Priority, and the ticket created timestamp maps to Created Time. We extract the department_id foreign key and map it to the corresponding Zoho Department via the department lookup established in the previous step.

HelpDeskZ stores ticket conversation history as sequential rows in a separate replies table linked by ticket_id. Each row has a type field (customer reply, agent response) and a message field. We extract these rows in chronological order and insert them into Zoho Desk as Ticket Comments with the author resolved to the corresponding Agent or Contact by email match. The direction (incoming/outgoing) is preserved using the type field mapped to Zoho's Comment direction. Thread ordering is preserved by setting the comment timestamp to the original HelpDeskZ reply timestamp.

HelpDeskZ stores custom fields as a PHP serialized string in a single column on the tickets table. We detect the PHP version on the source server (PHP 7 vs PHP 8) and apply the correct unserialization method, falling back to regex extraction for corrupted serialization. Each key-value pair is extracted, the field type is inferred from the value format (string, integer, date), and a corresponding custom field is pre-created in the Zoho Desk layout via the Custom Fields API before the ticket insert phase. Non-standard field names are normalized to Zoho's field naming constraints.

HelpDeskZ stores attachments on disk in the uploads/ directory with filenames referenced in the tickets and replies tables. We verify the uploads directory path via the uploads_path configuration value, extract file paths for each attachment reference, validate file existence, and upload each file to Zoho Desk via the Attachments API linked to the corresponding Ticket Comment. Missing files are logged as warnings and skipped to allow migration to proceed without blocking on a single lost file. Inline images within ticket content are extracted and re-uploaded separately.

HelpDeskZ email-to-ticket via POP3/IMAP is stored as mailbox configuration in the database. We extract the source email address and IMAP/POP3 settings and flag them for the customer to reconfigure as Zoho Desk Email Channels (Setup > Channels > Email > Add Email Account). The Message-ID and In-Reply-To threading relationships stored in HelpDeskZ tickets are not valid in Zoho Desk and are not preserved; the raw email content and attachment filenames are migrated but the email threading context is re-established by Zoho Desk's own thread assignment.

HelpDeskZ ships default statuses as integer codes (0=Open, 1=Pending, 2=Resolved, 3=Closed) stored in the status column. We build a remapping table at scoping: HelpDeskZ Open maps to Zoho Open, Pending maps to Pending, Resolved maps to Resolved, and Closed maps from both Resolved and Closed (combined in the remap). Customers who have added custom status values via ViktorNova fork or database patches have those statuses flagged for manual Zoho Desk status creation before the ticket insert phase.

The upstream HelpDeskZ does not have a native Account or Company object. If the customer has been using ViktorNova fork with account support or has extended the database schema with a companies table, we map that to Zoho Desk Accounts. Accounts in Zoho Desk link to Contacts and Tickets, providing the organizational context that HelpDeskZ lacks. We flag this as a lookup mapping: if no companies table exists, we skip the Account object and link Tickets directly to Contacts.

HelpDeskZ client-role users map to Zoho Desk Contacts when ticket submitter records exist. We extract the client email, name, and phone (if populated) from the HelpDeskZ users table for users who have submitted tickets, and create Zoho Desk Contact records. Contacts are resolved as parent records for Tickets before the ticket insert phase begins. If the customer also uses Zoho CRM, Contacts are looked up against the CRM API to avoid duplication.

The upstream HelpDeskZ distribution does not include a knowledge base module. Customers running the ViktorNova fork who have built KB content in a separate table must provide the schema details during scoping. We flag Knowledge Base migration as out-of-scope for the standard migration unless the customer supplies the exact table structure and we can verify the data model is stable. Zoho Desk Knowledge Base attachments do not migrate via any available method (Zoho's own Zwitch notes this limitation explicitly).

HelpDeskZ does not have a built-in reporting dashboard. Any custom reports the customer has constructed via direct SQL queries against the HelpDeskZ database must be translated to Zoho Desk's report builder (available from Standard tier) or Zoho Analytics. We do not migrate reports as code or SQL queries. We deliver a written inventory of all identified custom SQL reports with the equivalent Zoho Desk report type and field references for the customer's admin to rebuild.