Migrate from HelpDeskZ to Salesforce Service Cloud

HelpDeskZ tickets map to Salesforce Case records. The ticket id, subject, description, status, priority, and created/updated timestamps migrate directly. We resolve the ticket's assigned agent to a Salesforce User by email lookup, and the submitting user to a Contact by email on the Case. The flat HelpDeskZ ticket-to-reply thread is preserved as sequential EmailMessage records and CaseComments ordered by the created timestamp, with the original HelpDeskZ ticket_id stored in a custom external ID field hdz_ticket_id__c.

Each HelpDeskZ reply row maps to a Salesforce EmailMessage (for agent-customer exchanges) or CaseComment (for internal notes). We detect the reply type from the is_customer column and assign IsIncoming=true or false accordingly. Attachment filenames from the replies table are linked to the corresponding Salesforce Files. The created timestamp preserves chronological ordering in the case timeline.

HelpDeskZ users with role=admin or role=agent map to Salesforce User records by email match. We extract the username, email, and role from the users table. If a matching Salesforce User does not exist, the record is held in a reconciliation queue and the customer provisions the User before migration resumes. Hashed passwords do not migrate and must be reset in Salesforce.

HelpDeskZ users with role=client map to Salesforce Contact records. Multiple HelpDeskZ client accounts with identical email addresses are merged into a single Contact. The Contact receives the hdz_user_id__c external ID and the original HelpDeskZ username and registration date as custom fields. If the customer uses Salesforce Person Accounts, we map to that record type instead.

HelpDeskZ departments map to Salesforce Queues (for Case assignment) or Groups (for reporting segmentation). We extract the department id and name from the departments table and create corresponding Queues with the Cases object enabled. Department assignment on tickets becomes the Case.Origin or a custom department__c field linked to the Queue by name. If the customer uses Salesforce Territories or Omni-Channel, we coordinate department mapping with the routing configuration during scoping.

HelpDeskZ stores files on disk in the uploads/ directory. We resolve each filename from the tickets and replies tables against the configured uploads_path, validate the file exists, and upload it to Salesforce as a ContentVersion with the IsMajorVersion flag set. The ContentDocumentLink associates the file with the parent Case by linking via LinkedEntityId. Files without a valid on-disk presence are logged as warnings and skipped to allow migration to continue.

The custom_fields column on HelpDeskZ tickets holds a PHP serialized string. We unserialize it using the detected PHP version on the source server (falling back to regex extraction for corrupted data), extract each key-value pair, and create corresponding custom fields on the Salesforce Case object before migration. Field types are inferred from value format: numeric strings become Number fields, ISO dates become Date fields, and remaining values become Text fields. Custom field names are prefixed with hdz_ to avoid naming collisions.

HelpDeskZ ships with integer-coded statuses (typically 0=Open, 1=Pending, 2=Resolved, 3=Closed). We map these integer codes to Salesforce Case Status values (New, Working, Escalated, Closed) in the status field during import. If the customer has added custom status labels in the database, we document them and either create custom Status values or map to the nearest standard value during scoping.

HelpDeskZ priority values (Low, Normal, High, Urgent) map directly to Salesforce Case Priority values (Low, Medium, High, Highest). The mapping is straightforward because both platforms use equivalent vocabulary for urgency levels.

HelpDeskZ stores POP3/IMAP mailbox credentials and email-to-ticket rules in the database. We extract the source email address, mailbox type, and thread identifier settings. Email threading identifiers (Message-ID, In-Reply-To) are extracted as raw text only and do not reconstruct into Salesforce thread relationships, because Salesforce assigns its own thread IDs at Email-to-Case insertion time. We document the original mailbox settings for the customer to configure Salesforce Email-to-Case post-migration.