Migrate your HelpDeskZ data
Self-hosted PHP help desk for small teams who want full ownership and zero SaaS subscription costs.
In its favor
Why people choose HelpDeskZ
The signal that keeps HelpDeskZ on the shortlist. Sourced from G2, Capterra, and customer scoping calls.
Free and open-source with no per-agent or per-ticket licensing fees, making it attractive to bootstrapped teams and solo operators.
Full source-code access means complete data ownership and the ability to self-host on any PHP-capable server without vendor lock-in.
Minimal infrastructure requirements — runs on shared hosting with MySQL, making it accessible for non-technical teams with limited IT budgets.
Straightforward ticket workflow covering the basics: ticket creation, status updates, replies, and file attachments for support teams with simple needs.
The feature set has stagnated — without active development, teams outgrow the platform as support volume and complexity increase.
Limited to no native integrations with modern tools like Slack, Salesforce, or Zapier, forcing teams to manually bridge workflows or abandon the platform.
No public REST API means third-party automation, reporting, and data extraction all require direct database queries, which most non-technical teams cannot maintain.
As the vendor (EvolutionScript) has scaled to other products, documentation and community support for HelpDeskZ have thinned, leaving self-hosted customers without guidance for troubleshooting.
Reasons to switch
Why people leave HelpDeskZ
The recurring reasons buyers give for replacing HelpDeskZ. Presented as facts, not knocks.
Platform scorecard
Strengths, weaknesses, and where HelpDeskZ fits
Grades across six dimensions, plus a SWOT-style view of where the platform shines and where it falls short.
SWOT — strengths, weaknesses, and use-case fit
Strengths
Weaknesses
Where it works
Where it struggles
Pricing tiers
HelpDeskZ pricing overview
HelpDeskZ is distributed under the GPL, meaning there is no paid tier and no subscription. All costs are infrastructure-related (server hosting, domain, SSL) and are paid directly by the customer to their hosting provider. The ViktorNova GitHub fork adds OAuth and email-to-ticket improvements but remains free.
Community (Self-Hosted)
Tier 1 of 1
Free (GPL)
What's included
Need help selecting your Helpdesk?
Book a free 30 minute consultationPricing is informational. FlitStack AI does not bill on HelpDeskZ's schedule — see our quote-based pricing →
What gets migrated
HelpDeskZ object support
Object-by-object support for HelpDeskZ migrations. Per-pair details surface during scoping.
Tickets
Fully supportedTickets are the primary object in HelpDeskZ, stored in a single MySQL table with a status column and a priority column. All conversation threads (customer replies, agent responses) live in a separate replies table linked by ticket_id. We read both tables in order and reconstruct the full thread for each ticket before writing to the destination.
Users
Fully supportedHelpDeskZ maintains a users table with name, email, role (admin/agent/client), and a hashed password field. We extract all user records and map them to corresponding contacts or agents in the destination system. Password hashes are not migrated since they are not portable.
Departments
Mapping requiredDepartments are stored as a simple lookup table with id and name. We map department assignments on tickets to Teams or Groups in the destination. Some platforms use hierarchical department trees, which requires flattening before import.
Attachments
Mapping requiredAttachments are stored on disk in the uploads/ directory with filenames referenced in the tickets and replies tables. We extract the file paths, validate that each file exists, and upload them to the destination's attachment store, remapping the reference to the new URL or file ID.
Custom Fields
Mapping requiredCustom fields in HelpDeskZ are stored in a serialized PHP array column on the tickets table. We unserialize, extract each key-value pair, and create corresponding custom properties in the destination. The naming and data type of custom fields must be confirmed with the customer during scoping.
Ticket Statuses
Mapping requiredHelpDeskZ ships with default statuses (Open, Pending, Resolved, Closed) stored as integer codes in the database. We map these integers to the destination's status vocabulary. Customers who have added custom status labels via database edits require explicit value mapping.
Email Pipelines (Email-to-Ticket)
Mapping requiredHelpDeskZ supports email-to-ticket via POP3/IMAP polling. The source email address and mailbox settings are stored in the database. We flag whether email threading identifiers (Message-ID, References headers) were used, since these may not transfer cleanly to a new platform.
Knowledge Base Articles
Not in this platformHelpDeskZ does not include a built-in knowledge base module. If the customer has published KB content elsewhere, it must be migrated as separate unstructured data rather than as a native KB object.
| Object | Support | Notes |
|---|---|---|
| Tickets | Fully supported | Tickets are the primary object in HelpDeskZ, stored in a single MySQL table with a status column and a priority column. All conversation threads (customer replies, agent responses) live in a separate replies table linked by ticket_id. We read both tables in order and reconstruct the full thread for each ticket before writing to the destination. |
| Users | Fully supported | HelpDeskZ maintains a users table with name, email, role (admin/agent/client), and a hashed password field. We extract all user records and map them to corresponding contacts or agents in the destination system. Password hashes are not migrated since they are not portable. |
| Departments | Mapping required | Departments are stored as a simple lookup table with id and name. We map department assignments on tickets to Teams or Groups in the destination. Some platforms use hierarchical department trees, which requires flattening before import. |
| Attachments | Mapping required | Attachments are stored on disk in the uploads/ directory with filenames referenced in the tickets and replies tables. We extract the file paths, validate that each file exists, and upload them to the destination's attachment store, remapping the reference to the new URL or file ID. |
| Custom Fields | Mapping required | Custom fields in HelpDeskZ are stored in a serialized PHP array column on the tickets table. We unserialize, extract each key-value pair, and create corresponding custom properties in the destination. The naming and data type of custom fields must be confirmed with the customer during scoping. |
| Ticket Statuses | Mapping required | HelpDeskZ ships with default statuses (Open, Pending, Resolved, Closed) stored as integer codes in the database. We map these integers to the destination's status vocabulary. Customers who have added custom status labels via database edits require explicit value mapping. |
| Email Pipelines (Email-to-Ticket) | Mapping required | HelpDeskZ supports email-to-ticket via POP3/IMAP polling. The source email address and mailbox settings are stored in the database. We flag whether email threading identifiers (Message-ID, References headers) were used, since these may not transfer cleanly to a new platform. |
| Knowledge Base Articles | Not in this platform | HelpDeskZ does not include a built-in knowledge base module. If the customer has published KB content elsewhere, it must be migrated as separate unstructured data rather than as a native KB object. |
Gotchas
What to watch for in HelpDeskZ migrations
Issues we've hit on past HelpDeskZ migrations, tagged by severity. FlitStack AI handles every one — surfacing them up front because buyer engineering teams want to know.
No REST API — migration requires direct database reads
Custom fields are stored as serialized PHP arrays
Email-to-ticket threading does not migrate cleanly
Attachment files are stored on disk, not in the database
| Severity | Issue |
|---|---|
| High | No REST API — migration requires direct database reads |
| Medium | Custom fields are stored as serialized PHP arrays |
| Medium | Email-to-ticket threading does not migrate cleanly |
| Low | Attachment files are stored on disk, not in the database |
Leaving HelpDeskZ?
Where HelpDeskZ customers move next
7 destinations HelpDeskZ can migrate to.
How a HelpDeskZ migration works
Four steps, HelpDeskZ-specific
Connect
None — no public REST API into HelpDeskZ. Scopes limited to read-only on the data we move.
Map
We translate HelpDeskZ-specific structures (custom fields, objects, value lists) to the destination's model.
Sample
Test with a 50–200 record subset to validate HelpDeskZ quirks before production.
Migrate
Full migration with HelpDeskZ rate-limit handling. Rollback available throughout.
FAQ
HelpDeskZ migration FAQ
Answers to the questions buyers ask most during HelpDeskZ migration scoping. Not seeing yours? Book a call.
Can't find your answer?
Walk through your HelpDeskZ migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationOther helpdesks we support
Ready when you are
Migrate HelpDeskZ.
Without the rebuild.
Free scoping call with a migration engineer. Tell us about your HelpDeskZ setup and destination — written quote back within a business day.