Zammad vs osTicket: which helpdesk fits your support team
Choose Zammad if your support team works across several channels and needs strong search and reporting, and choose osTicket if your queues are smaller and you want a classic PHP and MySQL ticket system on a LAMP stack. The decision turns on four questions: which channels must land in one queue, how much search and reporting your managers need, how users and agents must sign in, and how much operating effort your team can carry after go-live.
Start with channels and search, because they drive the architecture. Zammad is built around omnichannel ticketing and needs PostgreSQL 15 or newer and Redis 7 or newer. Elasticsearch is optional, but the Zammad documentation says it is strongly recommended for faster search, reporting and searching email attachment content, so budget for it if reporting matters. osTicket runs on Apache or IIS, PHP 8.2 to 8.4 and MySQL 5.5 or greater. Confirm with each vendor which search and reporting features you need on the version you plan to run, and test them against your own ticket volume.
For identity, check the sign-in method your users require. Zammad lists SAML, OpenID Connect and several social providers for third-party login. osTicket's plugins repository covers LDAP, CAS, OAuth2 and two-factor authentication. Verify the exact plugin version and the directory setup you need before you commit. Then ask each vendor or implementer for a written scope that covers the migration from your current helpdesk, the upgrade path, and who handles backups and availability, since those recurring tasks, not the license, usually decide the total effort.
Which platform fits which support scenario
This table maps common support situations to the platform that fits them better and the condition under which the other one would be the stronger choice. Read each row against your own queue volume, channel mix, identity stack and reporting needs. Neither product wins everywhere, so the scenario that matches your team usually decides it.
| Scenario | Better fit | Reason and the condition that flips it |
|---|---|---|
| A single email queue with a small agent pool | osTicket | osTicket centers on email, phone and web forms feeding one multi-user interface, and its deploy and update path is simple to run. Zammad becomes the better choice if you expect the queue to grow into several channels or need its richer agent workflow from the start. |
| Multi-channel support with chat and social | Zammad | Zammad's ticket-centric model handles multiple inbound channels in one place, with a richer agent workflow than osTicket's classic model. If chat and social are the primary channels rather than tickets, a conversation-first inbox such as Chatwoot may fit better, which the Zammad vs Chatwoot comparison covers. |
| An existing PHP and MySQL estate | osTicket | osTicket runs on Apache or IIS, PHP 8.2 to 8.4 and MySQL 5.5 or greater, so it fits a team that already operates that stack. Zammad needs PostgreSQL 15 or newer and Redis 7 or newer, so it becomes the better choice only if you are willing to add and maintain that stack. |
| Single sign-on through SAML or OpenID Connect | Zammad | Zammad documents third-party login through SAML and OpenID Connect, among other providers. osTicket's core plugins cover LDAP, CAS, OAuth2 and passthrough authentication, so confirm whether SAML is available in your osTicket build before relying on it, or use the OAuth2 path if it matches your identity provider. |
| Heavy reporting and search needs | Zammad | Zammad uses Elasticsearch for faster search, reporting features and searching email attachment content, but Elasticsearch is optional and adds an operating component. If reporting needs are modest and your team can live with simpler search, osTicket keeps the footprint smaller, so confirm reporting depth against your actual report list. |
| Keeping upgrades predictable with a small team | Depends on your tolerance for stack change | osTicket's upgrade guidance asks you to back up attachments, the database and the codebase before each upgrade, and deploys from a Git clone. Zammad's self-hosted model places updates, backups and availability on your team, so budget for that in either case and ask both vendors for their current upgrade documentation. |
| Hosted or support-backed operation | Zammad | Zammad lists self-hosted support plans and hosted plans from 7 euros per agent per month on its pricing page. osTicket offers a cloud-hosted edition starting at $12 per agent per month and a virtual appliance edition with custom pricing, so compare total cost against the agent count you expect to reach. |
How Zammad and osTicket are built and what that means for operations
Zammad and osTicket are both self-hosted helpdesks, but they sit on different stacks: Zammad on PostgreSQL, Redis and optional Elasticsearch, osTicket on PHP and MySQL. Each stack sets a different patch, backup and deployment routine, so the operations team should weigh these components before the feature list.
Zammad's core data and cache stack
Zammad stores its content in PostgreSQL 15 or newer and needs Redis 7 or newer for realtime websocket communication. Your team must patch, back up and monitor three services, not one, and confirm that your database and cache versions are supported by the release you plan to run. Ask Zammad which PostgreSQL and Redis versions each 7.x release is tested against before you size the database host.
Elasticsearch as an optional search tier
Elasticsearch is optional for Zammad, but without it search is very limited. Zammad uses it for faster search, reporting and searching email attachment content, and it is strongly recommended. Treat it as a stateful service with its own patching, index backups and capacity planning. If you skip it, confirm with Zammad that search and reporting meet your agents' needs before go-live.
Memcached for multi-instance Zammad
Single Zammad installations can use the file system cache, but multi-instance deployments such as containers or cluster nodes need Memcached. Adding it means one more component to keep available and to size. If you plan to run several application nodes behind one load balancer, decide early whether you want that topology, because it changes your monitoring, failover and upgrade sequence.
Zammad install paths and their support limits
Zammad documents package installation, Docker Compose and a Kubernetes Helm chart. On Kubernetes, Zammad support covers only the Zammad application, not Kubernetes-specific issues. Choose the path your platform team can operate, since the package path puts OS patching and service management on your side, while containers shift more of the orchestration burden onto your cluster staff. Confirm what the vendor will and will not support in each path.
osTicket's PHP and MySQL base
osTicket runs on Apache or Microsoft IIS with PHP 8.2 to 8.4 (8.4 recommended), the mysqli extension and MySQL 5.5 or greater. This is a familiar stack for many Linux and Windows administrators, so the skills are easier to find. Your team still owns web server, PHP and database patching, and you should confirm that the MySQL version you run is supported by the osTicket release you choose.
osTicket's git-based deploy and upgrade routine
osTicket is deployed from a clone of its public repository with php manage.php deploy, and later updates are pulled with git pull before redeploying. Its README recommends backing up attachment files, the database and the codebase before every upgrade. Make the git workflow, the backup order and a rollback step part of your change process, and test the procedure on a copy of production before you rely on it.
What the stack difference means for search, uptime and skills
The stack difference matters most for search and reporting. Zammad's prerequisites treat Elasticsearch as optional but strongly recommended, because it powers faster search, reporting features and searching the content of email attachments. Without it, Zammad's search is very limited, so a team that skips Elasticsearch to save a server should expect slower lookups and thinner reports from day one. Before you commit, test your own ticket volume and typical queries against a Zammad instance with and without the search index, and confirm the reporting views your managers need work in your setup. osTicket's search and reporting depend on its own MySQL-backed application rather than a separate search cluster, so the comparison is about how much operational weight each model adds, not a simple feature gap. Confirm what search depth you need for compliance evidence and audits before you size either platform.
Zammad's Redis dependency is about realtime behavior. Redis 7 or newer carries the websocket traffic that keeps agent screens current, so a Redis outage shows up as stale views and delayed updates for agents rather than as a clean error page. Multi-instance deployments such as containers or cluster nodes also need Memcached, while a single installation can use the file system cache. Plan for one more service to monitor, patch and back up, and rehearse what agents see when Redis restarts during a busy shift. osTicket's stack is smaller: Apache or IIS, PHP 8.2 to 8.4 with mysqli, and MySQL 5.5 or greater, with no separate realtime broker listed in its README. That makes uptime planning simpler, but you should still test failover and backup restores for the MySQL tier and the attachment store, which the README asks you to back up along with the database and codebase.
Skills are where a PHP and MySQL team gains the most. A team already running that stack can operate osTicket with familiar tools, and the README's php manage.php deploy and git pull upgrade path is simple to script. Zammad asks for PostgreSQL 15 or newer, Redis, a reverse proxy in Nginx or Apache, and, for scale, Elasticsearch and Memcached, so the operator needs database, cache and search administration alongside Ruby application knowledge. Zammad's own support scope also matters: on Kubernetes, support covers the application, not Kubernetes-specific issues, so platform skills must be in-house or contracted. Confirm your team's current skills, who is on call, and whether a paid Zammad support plan or a DeployOpen engagement fits the gap, using a written scope and a quote before work starts.
Channels, workflow, search, authentication and upgrade paths compared
This table compares Zammad and osTicket on the features and operating details that most often decide a helpdesk shortlist. Read each row as a question to answer for your own environment, and treat any cell marked to confirm as an item to verify with the vendor before you commit.
| Capability | Zammad | osTicket |
|---|---|---|
| License | AGPL-3.0. Self-hosted use has no license fee; paid self-hosted support plans are sold separately. | GPL2 for the open-source download. Cloud and virtual appliance editions are sold separately. |
| Channels | Email and web channels are documented; confirm which additional channels (chat, social, phone) your edition and plugins provide. | Email, phone and web forms are described as inputs to one agent interface. Confirm any other channels against the current documentation. |
| Agent workflow | Ticket-centric helpdesk with a single agent interface. Confirm the trigger, macro and SLA options your version supports. | Multi-user web interface where incoming tickets are saved and assigned to agents. Confirm routing and SLA features against your version. |
| Search and reporting | Elasticsearch is optional but strongly recommended for faster search, reporting and attachment content search. Without it, search is very limited. | Confirm search and reporting depth in the current release. Plan any advanced reporting need as a requirement to test. |
| SSO and directory login | Third-party login through SAML and OpenID Connect, plus Microsoft, Google, GitHub and GitLab among other providers. | Core plugins cover LDAP, CAS and OAuth2 authentication. SAML is not listed among the supplied plugins; confirm it. |
| Two-factor and password policy | Confirm two-factor and password policy options in your Zammad version and admin settings. | Core plugins include two-factor authentication and password policy. Confirm they suit your identity setup. |
| Attachment storage | Stored with the application database and file system setup described in the installation documentation. Confirm object storage options for your version. | Core plugin supports attachment storage on the filesystem or S3. Confirm the setup steps before choosing it. |
| Migration tooling | Included migrators for Freshdesk, Kayako, OTRS and Zendesk. Other systems can be imported through the API or custom development. | No migration tooling was supplied for this comparison. Confirm import options with the vendor and your current system. |
| Upgrade guidance | Minor releases such as 7.2 are followed by security releases (7.2.1 and 7.2.2), with security fixes also published on the 6.5 line. Plan upgrades against the release notes. | Upgrades are supported from 1.6-rc1 and later. The README recommends backing up attachments, database and codebase first. |
| Hosting prerequisites | Requires PostgreSQL 15 or newer and Redis 7 or newer. Memcached is needed for multi-instance deployments. | Requires Apache or IIS, PHP 8.2 to 8.4 and MySQL 5.5 or greater with mysqli. |
| Paid hosted options | Hosted plans start from 7 euros per agent per month, per the Zammad pricing page. Self-hosted support plans are priced per year. | Cloud-hosted edition starts at $12 per agent per month, per the osTicket editions page. Virtual appliance edition is quoted individually. |
What is free and what is paid in each platform
Zammad is licensed under the GNU Affero General Public License version 3, and self-hosted Zammad has no license fee. The paid items are vendor support subscriptions and hosted plans, so the license cost of running it yourself is zero while the operating cost is not. Zammad's pricing page lists three self-hosted support subscriptions, Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, and hosted plans starting at 7 EUR per agent per month, per the Zammad pricing page.
- License: AGPL-3.0, so you may run, modify and self-host the software without a fee. Review the AGPL obligations with counsel if you modify the code and offer it to users over a network.
- Self-hosted support: Business, Enterprise and Corporation subscriptions are priced per year at 2,999, 5,999 and 9,999 EUR, respectively.
- Hosted plans: priced from 7 EUR per agent per month, billed per agent.
- Who runs what: the pricing page states that self-hosted customers handle updates, backups and availability, so those labor costs stay with your team or your implementation partner.
- Your cost drivers: database, Redis and Elasticsearch hosting, plus staff time for upgrades and monitoring.
Confirm with Zammad exactly which features, response times and channels each support tier includes, and whether any feature you need is limited to a hosted plan.
osTicket is released under the GPL2 license. The free download is the open-source product with community support only, so there is no vendor-backed support included in the license. Paid options are a cloud-hosted edition starting at $12 per agent per month and a virtual appliance edition with custom pricing, per the osTicket editions page. Both paid options change who operates the system and what support covers, so the choice depends on your hosting model.
- License: GPL2, which permits free self-hosting and modification under its terms.
- Free edition: community support only, with no service-level commitment from the vendor.
- Cloud edition: starts at $12 per agent per month, billed per agent.
- Virtual appliance: priced on request, so ask for a written quote that names the appliance version and support terms.
- Plugins: the osTicket-plugins repository holds core plugins for LDAP, CAS, OAuth2, two-factor authentication and S3 attachment storage. Confirm whether each plugin you need is free in your deployment.
Confirm what each paid edition includes in support, upgrades and hosting, and whether the cloud edition supports the plugins and integrations your team depends on.
The license line is only part of total cost. For both platforms you pay for the people who install, configure, upgrade and back up the system, and for the infrastructure that runs it. Vendor subscriptions and hosted plans buy support or operations, but they do not remove your responsibility for data, access and integrations unless the contract says so. Comparing the two products fairly means putting each cost on the same page, one-time and recurring.
- One-time: installation, data migration from your current helpdesk, integration with identity and email, and initial configuration.
- Recurring: per-agent hosted fees or vendor support subscriptions, server and database hosting, backups and staff time for upgrades.
- Cost drivers: agent count, channel count, number of integrations and how often you upgrade.
- Hidden items: Zammad's Elasticsearch and Redis dependencies, and osTicket's plugin and hosting work if you self-host.
- Quote request: ask each vendor for a written schedule that lists per-agent or per-year fees, included support, and what you must provide yourself.
Build a three-year comparison that uses only quoted figures, and mark any line item you have not yet confirmed in writing.
Pricing pages state headline figures, but they do not always describe every feature, limit or condition that affects your decision. Before you commit budget to either platform, collect the terms in writing and check them against your requirements. This is especially important for SSO, LDAP, reporting and search, which often depend on the edition or on additional components.
- Feature inclusion: confirm which authentication methods, reporting features and channels are included in each paid tier.
- Support scope: confirm response expectations, business-hour coverage and whether Kubernetes or Docker issues are covered.
- Usage limits: confirm how agents, administrators and customer users are counted for billing.
- Upgrade rights: confirm whether support fees include upgrades to future major versions and what happens if you stop paying.
- Exit terms: confirm data export options and whether migration support is included when you leave.
Ask for each answer in writing, and attach it to your evaluation so the comparison stays current when editions change.
How each platform ships fixes and what upgrading involves
Zammad publishes fixes on more than one line at the same time, so your patch calendar depends on which line you run. Zammad 7.2 shipped on September 23, 2026 as a minor release, followed by the 7.2.1 security release on October 6, 2026 and 7.2.2 on October 8, 2026. On October 15, 2026, Zammad also shipped security release 6.5.5, so the 6.5 line received fixes while 7.x was being patched. Zammad's pricing page states that self-hosted customers handle updates, backups and availability, so each security release lands on your team's change calendar. Before you standardize on a line, ask Zammad to confirm how long each line receives security fixes and how much notice you get before a line reaches end of life.
osTicket's 1.18 and 1.17 lines also move together. Versions 1.18.4 and 1.17.8 were both published on June 17, 2026, so a team on either line should expect parallel maintenance. The osTicket README says upgrades are supported from 1.6-rc1 and later, and it recommends backing up attachment files, the database and the codebase before you upgrade. The attachment backup is the step teams most often skip. If you store files on the filesystem or in S3 through the attachment storage plugin, a database-only restore brings back ticket records without their files. The README describes updating with git pull and then redeploying with php manage.php deploy, so each pull must be tested against your own plugins and template changes. The osTicket README is the starting point for that check.
The testing effort in both cases scales with how much you have changed the default install, not with the release count alone. An install with custom fields, workflows, plugins and a search index needs a full regression pass on every security release, and a standard Zammad install with a pinned Elasticsearch version still needs a check of the PostgreSQL 15 and Redis 7 requirements at each step. For osTicket, the cost of a pull is the review of the diff against your plugins. Ask both vendors for their support windows in writing, and ask osTicket whether the free edition includes any upgrade assistance, since its editions page describes community support for the free download. If you want upgrades and patch testing handled on a schedule, DeployOpen offers ongoing upgrade retainers, priced from a written scope.
What drives running cost for each helpdesk
Running cost for either helpdesk comes from a small set of recurring and one-time items: the servers and database, the people who run and upgrade the system, any paid support or hosting, and add-ons for storage or authentication. Zammad and osTicket shift these items in different directions, so a written quote should price each one separately.
Infrastructure footprint
Zammad expects PostgreSQL 15 or newer and Redis 7 or newer, and Elasticsearch is optional but strongly recommended for faster search and reporting. osTicket runs on Apache or IIS, PHP 8.2 to 8.4 and MySQL 5.5 or greater. Infrastructure is paid to your cloud provider or data center and recurs monthly. Ask the implementer to size each service separately, including backups and the extra Memcached tier that multi-instance Zammad deployments need.
In-house skills to run it
Zammad's stack spans Ruby, PostgreSQL, Redis and a search cluster, while osTicket is a PHP and MySQL application. Whoever operates the system is paid through salary or an external contractor, and this cost recurs for as long as the helpdesk runs. Check whether your team already supports these components, and price the gap as training or hiring rather than assuming it is zero.
Support subscriptions
Self-hosted Zammad has no license fee, but Zammad sells annual self-hosted support plans named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year. osTicket's free download comes with community support only. Both are recurring. Ask the vendor which response times, channels and upgrade assistance each plan includes, and whether the price changes with your agent count.
Upgrade and testing labor
Both platforms require backups of the database, attachments and code before upgrading, and each minor or security release needs a test cycle. Zammad publishes security releases on more than one line in parallel, so patch planning is a recurring task. The work is paid to internal staff or a partner, and it recurs with each release. Request a quote that states which upgrade windows are included and who tests integrations after each one.
Plugins and storage add-ons
osTicket's core plugins cover LDAP, CAS, OAuth2, two-factor authentication, password policy and S3 attachment storage, and these are configured and maintained by you. Zammad includes third-party login options such as SAML and OpenID Connect in the product. Plugin work is usually a one-time build plus recurring review after each core upgrade. Confirm which authentication and storage features you need on day one and which you can defer.
Hosted versus self-hosted pricing
Zammad hosted plans start at 7 euros per agent per month, and osTicket's cloud edition starts at $12 per agent per month. Hosted fees scale with headcount and remove infrastructure and upgrade labor from your budget. Self-hosting moves that cost into servers and staff time. Compare a hosted quote at your expected agent count with a self-hosted estimate that includes infrastructure, labor and support, and ask each vendor whether data residency and backup terms are included.
Moving from osTicket to Zammad or the reverse
This sequence moves ticket history, users, attachments and routing between osTicket and Zammad without losing the audit trail that support teams depend on. The output is a tested cutover with a documented rollback path and an osTicket instance that can be retired on a known date.
Inventory tickets, users and routing rules
Start by exporting a complete inventory from the current helpdesk: open and closed ticket counts by department, the user and agent directory, custom ticket and user fields, canned responses, SLA and escalation rules, and every email address and mailbox that creates tickets. Assign one owner to each category. The step is done when the team can state, for each category, what exists, who uses it and whether it must move, be rebuilt or be archived. Confirm with your own osTicket administrator which custom fields and plugins are in use, since those drive most rework.
Confirm the migration path before building anything
Zammad's documented migrators cover Freshdesk, Kayako, OTRS and Zendesk. Based on the supplied facts, osTicket is not among them, so ask Zammad directly whether an osTicket migrator or import script exists before you commit. If none exists, the realistic path is an export to structured files, mapped and loaded through the Zammad API or through custom development from Zammad, which should be scoped and priced as a separate work item. Going the other direction, from Zammad to osTicket, requires the same confirmation of export tooling. The step closes with a written decision on the path and a named owner for any custom loader.
Map users, groups and attachments
Build a mapping table that links osTicket staff and end users to Zammad users, and osTicket departments and teams to Zammad groups. Decide how roles and permissions translate, because the two products model agents and groups differently. Plan attachment handling separately: confirm where osTicket stores files (database or filesystem, or an S3 target through its plugin) and how the chosen loader will carry them over and verify checksums. The output is a signed-off mapping document and a test export of a small ticket set that reviewers can open and trace back to the source.
Rebuild workflows, authentication and channels
Recreate the operational logic that does not transfer automatically. Rebuild triggers, macros or automation, SLA definitions, notification templates and custom fields in the target system. Reconfigure sign-in: osTicket's supplied plugins include LDAP, CAS, OAuth2 and two-factor authentication, while Zammad lists SAML, OpenID Connect and several social providers, so confirm that each login method you rely on has a supported equivalent. Reconnect every inbound channel, including email addresses, web forms and phone-created tickets, and test each one with a sample message. The step is complete when every intake route has a passing test and every workflow has a reviewer sign-off.
Run parallel intake and compare results
Point a defined share of new mail or form traffic at the target system while the source system continues to accept tickets. Compare ticket counts, routing decisions, assignment times, attachment access and notification delivery each day against the source. Record every mismatch in a defect log with an owner and a fix. The parallel period ends when the defect log shows no open routing or data defects and agents confirm they can resolve tickets without falling back to the old tool. Length of this period is a team decision, not a supplied fact, so set it in your plan.
Cut over DNS, email and final data
Schedule the cutover window with stakeholders and freeze new configuration changes. Run a final incremental export from the source, load it into the target, and reconcile record counts and sampled attachments. Move the mail routing and web form endpoints, then confirm that a test ticket from each channel lands in the correct queue. Keep the source system in read-only mode and retain its database and attachment backups under your retention policy. The step is done when reconciliation passes and every channel is confirmed live in the new system.
Decommission the source system securely
Once the rollback window closes, archive a final export and the source backups in your approved storage, then remove mail forwarding, API tokens, plugin credentials and service accounts tied to the old helpdesk. Revoke access to the old database and filesystem, and update the asset inventory and runbooks. Record the decommission date and the location of the archive so auditors and future staff can find the historical ticket record. The step closes with a signed decommission checklist and an updated system register.
Where helpdesk implementations usually run long
Mail routing and channel setup take more time than the platform install in most helpdesk projects. Zammad and osTicket both receive email, web form and phone-originated tickets, but each channel needs its own mailbox, inbound and outbound settings, and testing with real message threads. Zammad's channel configuration, its Elasticsearch-backed search and its Redis and Memcached settings for multi-instance deployments are separate workstreams that should be scoped on their own. On the osTicket side, the mail fetching, department routing and attachment storage decisions (filesystem or S3 through the osTicket-plugins repository) tend to be settled late, which pushes rework into go-live. Confirm with each vendor which channels your team needs on day one and which can wait.
Identity integration, custom fields and legacy imports are where scope most often grows. Zammad supports SAML and OpenID Connect among other providers, while osTicket relies on plugins for LDAP, CAS, OAuth2 and two-factor authentication, so the identity design differs by platform and must be tested against your directory groups and role mapping. Custom ticket fields, SLA rules and reporting views usually multiply once agents start using the system, and a migration from an older desk brings its own mapping of statuses, agents, attachments and history. Zammad documents migrators for Freshdesk, Kayako, OTRS and Zendesk and an API route for other systems, so ask early whether your source is covered or needs custom development. Training and workflow sign-off follow these decisions, so they should not be left to the end.
Effort depends on the written scope, which DeployOpen agrees in writing before work starts. DeployOpen plans and implements fixed-scope engagements, and the deliverables, timelines and acceptance criteria are set out in that document rather than assumed in advance. A quote should list the installation hardening, identity work, each channel, the workflow and SLA design, reporting, migration and training as separate items, and state what is excluded. Ask the vendor or the partner to confirm the current release line and prerequisites for your environment before the scope is fixed, because the answer determines the hosting work.
Questions buyers ask before choosing between Zammad and osTicket
What does self-hosting Zammad or osTicket cost in effort and skills?
Neither product charges a license fee for the self-hosted software, so the cost is mainly staff time, infrastructure and any paid support you add. Zammad needs PostgreSQL 15 or newer and Redis 7 or newer, and Elasticsearch is optional but strongly recommended for faster search and reporting. Multi-instance deployments also need Memcached. osTicket needs Apache or Microsoft IIS, PHP 8.2 to 8.4 with the mysqli extension, and MySQL 5.5 or greater. One-time costs include installation, configuration, integration and data import. Recurring costs include patching, backups, monitoring and upgrades, which your team carries unless you buy a support plan, hosting or a retainer. Ask any implementation partner for a written scope that lists each component, who operates it and the effort assumed for ongoing upkeep.
How long does a helpdesk migration take and what determines it?
No supplied figure fixes a duration, so the timeline depends on the data you carry over and how it maps to the new system. Zammad includes migrators for Freshdesk, Kayako, OTRS and Zendesk, and other systems can be imported through the Zammad API or through custom development. The main drivers are ticket and attachment volume, the number of custom fields and workflows to recreate, how many mailboxes and channels you reconnect, and how much history agents need to search after cutover. For osTicket, the effort depends on your source system and on the import tooling your team or a partner builds, so confirm what is available before planning. Ask for a dry run on a copy of production data, a field mapping document and a cutover plan with a rollback step. Confirm the source export format early, since it often sets the schedule.
Can our team run Zammad or osTicket without outside help?
It can work if your staff already operate PostgreSQL, Redis and PHP applications, but the skill set differs between the two. Zammad expects you to run PostgreSQL 15 or newer, Redis 7 or newer and a reverse proxy such as Nginx or Apache, and larger installations add Elasticsearch and Memcached. Zammad's pricing page states that self-hosted customers handle updates, backups and availability. osTicket is a PHP application on MySQL, so its skills profile is closer to a classic web application stack, and every upgrade depends on backing up attachment files, the database and the codebase first. Check whether your staff can own patch windows, on-call response and restore tests. If they cannot, ask for a managed operations scope in writing. DeployOpen offers ongoing support, upgrades and continuous testing as retainers.
Which helpdesk needs SSO or LDAP, and how does each handle it?
Both platforms support directory-based sign-in through different mechanisms, so confirm the exact connector against your identity provider before you commit. Zammad's third-party login documentation lists SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab among other providers. The material supplied for this comparison does not confirm LDAP for Zammad, so check the admin documentation for your version. osTicket's core plugins repository includes LDAP, CAS, OAuth2 and passthrough authentication, plus two-factor authentication and password policy plugins. Plugins add a version-matching step that you should test at every upgrade. Ask the vendor or partner to demonstrate group-based role mapping, removal of access when a user leaves, and sign-in that enforces your MFA policy on a test instance.
Is osTicket's free download enough for our number of agents?
The free download can be enough for a small team that is comfortable with community support, but the agent count is only one input. osTicket's editions page lists a free open-source download with community support only, a cloud-hosted edition starting at $12 per agent per month, and a virtual appliance edition with custom pricing. Community support carries no contractual response commitment, so any requirement for a fixed response time needs a paid route. The free download also leaves out hosting, security patching, backups, and any plugin you need for authentication or storage. Model the cloud option per agent using the current editions page, and request a written quote for the appliance. Confirm that every feature your team needs is in the free build before assuming parity with the paid editions.
When is a Zammad support subscription or hosted plan worth quoting?
Request a quote when you need a contractual support route, want the vendor to carry updates and availability, or expect the platform's operational load to outgrow your team. Zammad's pricing page lists self-hosted support plans named Business at 2,999 euros per year, Enterprise at 5,999 euros per year and Corporation at 9,999 euros per year. Its hosted plans start from 7 euros per agent per month. Compare those figures with the staff hours you would otherwise spend on patching, backups and on-call work, plus the infrastructure you would pay for. Included channels, data location and support hours differ by plan, so ask for the current comparison in writing. Hosted operation is a different model from self-hosting, so ask how data would move if you change direction later.
Which upgrade path needs more planning, Zammad or osTicket?
Neither upgrade is risky when you follow the vendor steps, but the planning load differs. Zammad publishes releases across more than one line: version 7.2 arrived on September 23, 2026, security releases 7.2.1 and 7.2.2 followed on October 6 and October 8, 2026, and a 6.5.5 security release appeared on October 15, 2026 for the 6.5 line. Identify which line you run and schedule patches for it, and check the software prerequisites before each change. osTicket's README states that upgrades are supported from 1.6-rc1 and later, and it recommends backing up attachment files, the database and the codebase first. Its 1.18.4 and 1.17.8 releases both appeared on June 17, 2026. Test each upgrade on a staging copy and confirm plugin compatibility from the release notes.
What does DeployOpen cover if we choose one of these platforms?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For either helpdesk, the work can include installation, identity integration, migration planning, channel setup, backup and restore testing, and runbook documentation for your staff. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask that the scope name the platform version, the identity provider, the data sources to migrate and who approves cutover. DeployOpen is not an official partner, reseller or certified provider of Zammad or osTicket.
How DeployOpen helps teams choose and implement a helpdesk
DeployOpen starts by agreeing on which helpdesk fits your channels, identity model and hosting rules, then plans and implements it inside your own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we scope
- We map your inbound channels, agent count and identity provider before recommending Zammad or osTicket.
- The written scope names the database, cache, search and reverse proxy components for your chosen platform.
- We confirm which migration sources, such as Zendesk or Freshdesk, need API work or custom development.
How we build
- We install the platform in your environment and configure authentication, mailboxes and agent workflows to the agreed scope.
- We test SSO or LDAP sign-in, email routing and search behavior against the requirements in the written scope.
- We document configuration, customizations and plugin choices so your team can review them later.
How we hand over
- We deliver runbooks covering backups, upgrades, patching and restore testing for your chosen helpdesk platform.
- We walk your administrators through agent roles, reporting and the steps for applying security releases.
- We record the compliance-relevant evidence your assessor may ask for, such as access settings and backup logs.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover version upgrades, which matter on osTicket's PHP and MySQL stack and on Zammad's PostgreSQL and Redis stack.
- Ask any provider to confirm which platform version, edition and support window they will cover in writing.
