Self-hosted helpdesk and ticketing in 2026: revisit Zammad, FreeScout and osTicket before you move another support inbox

Most support desks in Indian companies did not start as a project. They started as one email address, support@, shared by three people. Then a fourth person joined, somebody added labels, somebody else started a spreadsheet of “pending complaints”, and a sales manager began forwarding WhatsApp screenshots to the same mailbox. Five years later the company has a support process that lives in a mailbox, two phones and the memory of the senior engineer. Nobody can say how many complaints came in last month, how long they took, or which customer has been waiting since Tuesday.

At some point the company either buys a SaaS helpdesk or asks whether it can run one itself. This post is about the second question. A helpdesk holds customer data, depends on the company’s mail system and shapes the daily work of the people who answer customers, so a wrong choice shows up quickly.

We revisit three open-source helpdesks that people actually run in 2026: Zammad (a full multichannel helpdesk on Ruby on Rails, under AGPL-3.0), FreeScout (a lightweight shared inbox on PHP and Laravel, under AGPL-3.0, extended with paid modules) and osTicket (the long-running PHP and MySQL ticket system, under GPL-2.0). We checked whether one of them should be swapped out. All three had real releases in 2026, so they stay. We mention the alternatives we looked at, and why they did not make the cut, in the history section.

There is real news this autumn, and most of it is about security. Zammad 7.2 came out on 23 September 2026 with a tamper-proof admin audit log and better spam protection for web forms. Two weeks later, on 6 October, Zammad 7.2.1 fixed 27 published security advisories in one go, and 7.2.2 followed on 8 October for a local root escalation that affects only the DEB and RPM packages. FreeScout released 1.8.249 on 31 October 2026 with eight more advisories fixed, on top of a year in which its GitHub advisory list grew by 88 entries. osTicket’s last release was 1.18.4 on 17 June 2026, a release made entirely of security patches. If you run any of these, this is the right month to look at your version number.

This post stays with ticketing: email, web forms, chat, messaging and phone feeding one queue. For the systems around a helpdesk, see self-hosted email in 2026 because the mail server is the helpdesk’s front door, self-hosted wikis in 2026 for internal runbooks, and self-hosted project tracking in 2026 for the engineering side of a bug that support escalates.

A scenario to keep us honest

We will use one invented company through the post. Siddheshwar Agro Controls is an invented example, not a real business: a Solapur company that designs and sells drip irrigation controllers, solar pump controllers and soil moisture sensors to farmers through about 300 dealers in Solapur, Pandharpur, Osmanabad, Latur, Vijayapura and Kalaburagi. It has about 180 people. The support team has 14 agents who speak Marathi, Kannada, Hindi and English between them. About 30 field technicians visit farms for installation and warranty work. IT is a team of two, led by Pradnya, with most systems on Google Workspace and two VMs in a Mumbai cloud region.

What they use today:

  • A Google Workspace shared mailbox, support@, with labels for “warranty”, “dealer”, “billing” and “urgent”, where farmers, dealers and the company’s own sales staff all write.
  • A Freshdesk account that the dealer team started using three years ago on a low plan. It holds a little over 20,000 dealer tickets, with three groups, two custom fields (controller serial number and dealer code) and a set of canned replies.
  • A WhatsApp Business number on two shared phones, where farmers send photos of controllers showing error codes, and a missed-call number from a cloud telephony provider whose call logs nobody connects to anything.
  • A spreadsheet called “Field visits” that the service manager updates every evening.

What triggered the review: the Freshdesk renewal came with a higher per-agent price for the plan the dealer team now needs, and the company wants all 14 agents in one tool, not some in Freshdesk and some in Gmail. In the same quarter, a state agriculture department tender asked bidders to describe where farmer complaint records, including names, mobile numbers, village names and installation photos, are stored and who can access them. And the service manager found that a farmer in Akkalkot had sent the same warranty photo four times on WhatsApp over two weeks, because the phone that received it was in a drawer during the harvest rush.

Pradnya’s questions: which helpdesk, which channels it really supports, how agents and dealers sign in, how much server it needs, what moves from Freshdesk and what does not, how backups and upgrades work, and whether two IT people can keep it patched given how many security fixes these projects shipped this year.

The short version

  • All three are alive and maintained, but they are different kinds of tool. Zammad is a full helpdesk with many channels, SLAs, a knowledge base and reporting. FreeScout is a shared inbox in the Help Scout style, small at its core and extended with modules. osTicket is a classic ticket system with help topics, departments, SLA plans and a customer portal, mostly built around email and web forms.
  • Zammad is the broadest. Email (IMAP and SMTP, Google, Microsoft 365), web forms, a chat widget, SMS, Telegram, WhatsApp and Facebook channels, phone integration through CTI, LDAP and SAML and OpenID Connect sign-in, and built-in importers for Freshdesk, Zendesk, Kayako and OTRS are all in the open-source code. There is no paid feature edition for self-hosting. The cost is weight: PostgreSQL, Redis, Memcached in container setups, and Elasticsearch strongly recommended.
  • FreeScout is the lightest and the most pleasant for agents who live in email. The core is free with unlimited agents and mailboxes, but much of what a helpdesk team expects (tags, saved replies, workflows, custom fields, reports, a customer portal, LDAP, SAML, WhatsApp, a knowledge base) comes from official modules sold as lifetime licences per instance. Its release pace is very fast, often several releases a month, and many of them carry security fixes.
  • osTicket is the most conservative. It runs on PHP and MySQL with a web installer, supports email fetching and piping, web forms, an API for creating tickets, and plugins for LDAP, OAuth2 sign-in and email, two-factor authentication and attachment storage. It had two releases in 2026, both security-focused. It has no built-in importer and no chat or messaging channels.
  • For Siddheshwar we recommend a structured pilot of Zammad 7.2.2 on Docker Compose, a test import from Freshdesk on a throwaway instance, Google sign-in for staff, the Google email channel for support@, and WhatsApp only after a careful look at its limits. Details later.
  • Do not migrate the mess. Migrate the queue. The value is in open tickets, customer history and good replies. Labels nobody understands, rules nobody remembers and a dozen “urgent” categories should be redesigned before any import.

Where things stand on 2 November 2026

Zammad

  • Current release: 7.2.2 on 8 October 2026. It fixes one advisory, a local privilege escalation to root that affects only installations from DEB or RPM packages built with packager.io. Zammad 7.2.1, two days earlier on 6 October, fixed 27 advisories, listed in the release note with titles such as cross-organisation ticket disclosure through unfiltered sign-up fields, a bypass of multi-factor authentication through the email verification flow, remote code execution through a template sanitiser bypass in automation configuration, a second-order SQL injection in ticket overview sorting, and channel administration APIs returning stored channel credentials in clear text. Zammad 6.5.5 on 15 October was an exceptional release for the unsupported 6.5 line, hardening the WebSocket server, and the note says plainly that it does not extend 6.5’s support life.
  • What came in 7.2 (23 September 2026): a tamper-proof admin audit log, where changes in the admin area are recorded and cannot be edited or deleted through the UI or API; a modular spam protection framework for web forms; AI features that draft knowledge base answers from solved tickets and suggest existing answers in the ticket sidebar; embedding self-hosted video in knowledge base answers after an admin approves the media server; a central setting for the order of first and last names; and the option to suppress notifications for API updates. Elasticsearch 7 is no longer supported, 8.15 is the new minimum, and the index must be rebuilt after the upgrade for the audit log.
  • The year’s direction: Zammad 7.0 on 4 March 2026 brought the first AI features (AI agents called from triggers, macros or scheduler jobs, ticket summaries, a writing assistant), all off by default and working with an LLM provider the admin chooses. It also added nested LDAP groups for role mapping, role-based reporting profiles and Bearer tokens for webhooks. 7.0 dropped MySQL support completely and removed the Twitter/X integration. 7.1 followed on 17 June 2026.
  • Requirements: PostgreSQL 15 or newer, Redis 7 or newer, Nginx or Apache as reverse proxy, and Elasticsearch (optional but strongly recommended; 7.2 needs 8.15 or newer and below 10). Packages are offered for Ubuntu 22.04, 24.04 and 26.04, Debian 11, 12 and 13, RHEL and CentOS 9 and 10, and openSUSE Leap and SLES 15 and 16, and the 7.2.1 note announces that Debian 11 will be dropped. Docker Compose and Kubernetes carry all dependencies.
  • Licence: AGPL-3.0. The docs state that the code is owned by the Zammad Foundation, which is independent of Zammad GmbH, the company that does most of the development and sells hosting and support.

FreeScout

  • Current release: 1.8.249 on 31 October 2026. It added merging conversations from the list view and an option to skip attachments already received in a conversation, and fixed eight advisories published the same day. Among them: a forged notification-reply Message-ID that let an outside sender post as an agent, an agent without delete permission erasing history by merging conversations, a password reset token that survived a change of email address, members of an archived mailbox still reading its messages, disabled agents still replying by email, and a path traversal in the translations editor that let an administrator write PHP files outside the intended folder.
  • What came just before: 1.8.248 on 17 October added a split view for conversations and fixed advisories including concurrent invitation redemption creating several sessions. 1.8.246 and 1.8.247 on 10 October improved the customer list and fixed a crash. Releases 1.8.244 and 1.8.245 came on 3 October. That is six releases in October alone.
  • The security record this year: FreeScout’s GitHub advisory list has 127 entries, of which 88 were published in 2026: 7 critical, 39 high, 40 medium and 2 low. The critical ones include an unauthenticated account takeover through an empty invitation hash on MySQL, invitation links that never expired, a Zip Slip path traversal in module installation leading to code execution, and a mass assignment bug in mailbox connection settings that could silently redirect email. We read this as a project under heavy outside review that fixes and discloses quickly, not as a reason to panic. It does mean an operator must update often.
  • Requirements: the README lists Nginx, Apache or IIS, PHP 7.4 to 8.x, and MySQL, MariaDB or PostgreSQL, and says there are no minimum CPU or RAM requirements. The project’s own composer.json in 1.8.249 still declares PHP 7.1 or newer and pins Laravel 5.5.40, with a folder of overrides for older libraries.
  • Licence: AGPL-3.0 for the core. The modules page says official modules are also open source under AGPL-3.0, sold as lifetime licences for a single FreeScout instance with lifetime updates.

osTicket

  • Current release: 1.18.4 on 17 June 2026, together with 1.17.8 for the older 1.17 line. The release note lists only a security section with 25 patch commits. The osTicket announcement says the release supports PHP 8.2 to 8.4 and that the OAuth2 plugin is needed for modern email authentication.
  • Before that: 1.18.3 on 15 January 2026 upgraded the bundled mPDF and htmLawed libraries and carried six security patches. 1.18.2 came in February 2025.
  • Advisories: osTicket does not publish GitHub advisories. Public CVE records this year describe a stored XSS through a Bootstrap tooltip component (CVE-2026-36214, affecting versions up to 1.17.7 and 1.18.3), an authorisation gap where an agent limited to one department could read ticket fields from another department (CVE-2026-14871, fixed in 1.18.4 and 1.17.8 according to the researcher’s advisory), and three more records published in August 2026 against 1.18.3: predictable API key generation (CVE-2026-38447) and two stored XSS issues through email display names and thread titles. Check your version against each record rather than assuming.
  • Requirements: Apache, LiteSpeed or IIS with URL rewriting, PHP 8.2 to 8.4 (8.4 recommended), the mysqli extension and MySQL 5.5 or newer. MariaDB is mentioned in the Windows links in the install guide.
  • Licence: GPL-2.0. Enhancesoft is the company behind osTicket and sells a hosted version and support.

The first questions to ask

  1. Where do requests come from today, by count? Email, web form, WhatsApp, phone, dealers walking in. Count a normal month. The tool should fit the channels you have, not the ones in the brochure.
  2. Who answers, and who only watches? Agents, supervisors, field staff who need to see a ticket on a phone, sales people who want to know if their customer is unhappy. Licence costs, permissions and training all follow from this.
  3. Do customers need to log in? A portal where farmers or dealers see their own tickets is useful, but it also means customer accounts, password resets and one more thing to secure.
  4. What must move from the old system? Open tickets, customers, organisations and maybe two years of closed history. Older history can often stay as an export.
  5. How do agents sign in? Google Workspace, Microsoft 365, LDAP or Active Directory, Keycloak, or local passwords with two-factor authentication. This decides between free core features and paid modules in one of the three tools.
  6. Which mail system feeds it? Google and Microsoft 365 need OAuth for mailbox access now. A self-hosted mail server needs IMAP and SMTP with proper SPF, DKIM and DMARC.
  7. What is the promise to customers? First response in four working hours, resolution in three days, or nothing written down. SLA features are only useful once the promise exists.
  8. Who owns it in year three? Given this year’s advisory counts, the honest answer must include “someone who updates it every week or two”.

How each one works

Zammad: a Rails application with real-time parts

Zammad is a Ruby on Rails application with several processes: a Rails server for the web UI and API, a WebSocket server for live updates, and a scheduler for background jobs such as fetching mail, running triggers and checking SLAs. It stores data in PostgreSQL, uses Redis for real-time communication, uses Memcached as a shared cache when processes run in separate containers, and uses Elasticsearch for fast search, reporting and searching inside attachments. The docs warn that without Elasticsearch search becomes slow and limited.

You can install it from DEB or RPM packages (the package installs PostgreSQL if none is found), with Docker Compose, on Kubernetes with a Helm chart, or from source. The Docker Compose project we read, release v17.5.4 of zammad-docker-compose from 27 October 2026, defines eleven services: backup, Elasticsearch 9.5.5, an init job, Memcached 1.6.45, Nginx, PostgreSQL 17.11, a PostgreSQL init helper, the Rails server, Redis 8.10.3, the scheduler and the WebSocket server, with the Zammad image pinned to 7.2.2-0024 and Nginx published on port 8080.

FreeScout: a Laravel app that runs almost anywhere

FreeScout is a PHP application on a pinned, patched Laravel 5.5. It needs a web server, PHP and a database, and nothing else for the core. Background work (fetching mail, sending replies, notifications) runs through Laravel’s scheduler and queue, triggered by a cron entry every minute. The project offers a web installer and a web updater, an interactive install script for Ubuntu, a Docker image, and listings with several shared hosting panels.

The core is a shared inbox: mailboxes, conversations, assignment, internal notes, collision detection, saved drafts, following, search and notifications. Almost everything beyond that is a module, installed from the admin area with a licence key. That keeps the core small, but it means the real system is “core plus the 10 to 20 modules you installed”, and each module has its own version.

osTicket: a PHP application with a web installer

osTicket is plain PHP with a MySQL database. You upload the upload folder to the web root, run the web installer, which writes include/ost-config.php, then remove write access to that file and delete the setup folder. Mail is fetched by a cron job (api/cron.php or the rcron.php script) or piped from the mail server with the automail scripts. Ticket creation by API uses an API key tied to an IP address.

Plugins are separate downloads from the osTicket website, placed in include/plugins. The official plugin set covers LDAP and Active Directory, OAuth2 (for both sign-in and mailbox authentication), CAS, HTTP pass-through authentication, two-factor authentication, password policies, an audit log, and attachment storage on the filesystem or S3. Our download of 1.18.4 contained no plugins, only an updates certificate in that folder.

Data model and channels

Zammad

  • Model: tickets belong to groups (queues), have a state, priority, owner and customer, and contain articles (each email, note, chat transcript, WhatsApp message or call note is an article). Customers belong to organisations, and a user can have secondary organisations. Custom fields are “objects” added by the admin.
  • Rules: triggers act on create and update, schedulers act on time, macros are one-click bundles of actions, and core workflows control which fields are shown or required. SLAs measure first response, update and solution times against business-hour calendars. Time accounting can be required on replies.
  • Channels: email (IMAP, POP3, SMTP, and OAuth connections for Google and Microsoft 365 including a Graph API option), web form, chat widget, SMS, Telegram, Facebook and WhatsApp. The phone integrations are generic CTI, Placetel and sipgate; with generic CTI, a phone system that supports it can show caller details and log calls.
  • WhatsApp in practice: the channel uses the WhatsApp Business platform from Meta. Zammad’s own limitations page is clear: only customer-initiated conversations are supported, because Zammad does not support Meta’s approved message templates; replies are possible only inside a 24-hour service window, with an optional reminder after 23 hours; one attachment per outgoing message; and one phone number per business app. This is fine for “farmer sends a photo, agent replies the same day”, and not fine for “agent follows up on Monday about Friday’s complaint”.
  • Knowledge base: built in, with public and internal answers, multiple languages, and since 7.2 AI-drafted answers from solved tickets if you enable an AI provider.

FreeScout

  • Model: mailboxes hold conversations; a conversation has threads (customer messages, replies, notes), a status, an assignee and a customer. Customers are tracked by email address and can have phone numbers and a company. Folders show “unassigned”, “mine”, “assigned” and so on.
  • Rules and fields: tags, saved replies, workflows (automation), custom fields, custom folders, time tracking, SLA-like reminders through workflows, and satisfaction ratings are all modules. In the core you get assignment, notes, auto-replies and notifications.
  • Channels: email is the heart of it (IMAP, POP3, SMTP, and OAuth for Microsoft 365 and Google Workspace). Phone conversations can be logged by hand in the core. Live chat, an end-user portal and contact form widget, WhatsApp, Telegram, Facebook, SMS through Twilio and Slack notifications are modules.
  • Knowledge base: a module.

osTicket

  • Model: tickets are created by users through email, the web portal, the API or by an agent on the phone, and are routed by help topics to departments and teams. Each help topic can carry its own form with custom fields, a priority, an SLA plan and an auto-assignment rule. Tasks can be attached to tickets for internal work.
  • Rules: ticket filters act on incoming tickets, SLA plans set grace periods, and canned responses help agents reply. Queues can be customised with saved searches and columns.
  • Channels: email by fetching or piping, the web portal, and the API. Phone tickets are typed in by an agent. There is no chat or messaging channel in core or in the official plugins.
  • Knowledge base: FAQs with categories, public or internal.

Security, sign-in and permissions

Who can sign in, and how

  • Zammad: local accounts with two-factor authentication (added in 6.1), LDAP and Active Directory with role and group mapping (nested groups since 7.0), SAML, OpenID Connect (since 6.5), Kerberos SSO, and third-party logins including Google, Microsoft, GitHub and GitLab. All of this is in the open-source code; there is nothing to buy for self-hosting.
  • FreeScout: local accounts in the core. Two-factor authentication, LDAP, SAML SSO and “OAuth and social login” (Google, Azure and others) are each separate modules.
  • osTicket: local accounts, with multifactor authentication documented as a feature, and plugins for LDAP and Active Directory, OAuth2 sign-in (Google, Microsoft, Okta are the examples in the guide), CAS and HTTP pass-through. Agents and end users can use different backends.

Permissions

  • Zammad uses roles with permissions (for example ticket.agent, admin.channel_email, admin.ai_agent) and per-group access levels (read, create, change, overview, full). Customers see only their own tickets, or their organisation’s tickets if you allow it. The October advisories show where this got tested hard: cross-organisation disclosure, deactivated roles still granting access, and articles visible without authorisation.
  • FreeScout controls access per mailbox, with an option to let agents see only conversations assigned to them, and a “customer visibility” option. Its security policy states some deliberate design choices worth knowing: agents may move conversations to any mailbox, even ones they cannot access, and drafts are visible to any member of the mailbox.
  • osTicket gives agents a primary department, extended access to other departments, and a role per department. The 2026 BOLA issue was exactly a case where a field view did not check department access.

The advisory record

Between them, these three projects published well over a hundred security fixes in 2026. Some lessons are common to all three:

  • Inbound email is untrusted input. FreeScout and osTicket both had stored XSS issues where a crafted email (a display name, a thread body, an HTML part) ended up rendered in the agent interface. Zammad had stored XSS in ticket zoom through article preferences. Your helpdesk is a web app that renders mail written by strangers.
  • Permissions get tested at the edges. Archived mailboxes, deactivated roles, merged conversations, organisation changes and invitation links are where bugs were found, not the main ticket screen.
  • Admin screens hold secrets. Zammad’s channel APIs returned mail credentials in clear text before 7.2.1, and FreeScout had an installer page that could disclose .env after a manual install. Treat helpdesk admin accounts like mail admin accounts.
  • Packaging matters too. Zammad 7.2.2 was about the DEB and RPM packages, not the application code. Whichever install path you choose, it is part of your attack surface.

The practical answer is the same for all three: subscribe to the advisories (GitHub for Zammad and FreeScout, the osTicket blog and NVD for osTicket), update within days for high and critical issues, and keep the admin area off the public internet where you can.

Complaint data is personal data

A helpdesk is often the largest store of customer personal data in a small company, larger than the CRM. Farmer names, mobile numbers, villages, photos of fields and installations, invoice copies and sometimes bank details for refunds all end up in tickets and attachments. India’s Digital Personal Data Protection Act, 2023 makes you think about purpose, retention and who can see what. We are not giving legal advice here, so please ask your counsel what applies to you. Practically, decide a retention period for closed tickets and attachments, restrict who can export data, and know which of your tools can delete a customer with all their history. Zammad’s admin area has a data privacy function for deleting a user together with their tickets, and its docs have a privacy and data retention page; FreeScout has a GDPR module for deleting customers with their conversations; in osTicket you delete users and tickets through the agent and admin panels.

Performance and capacity

These are the projects’ own guidance, not our measurements.

  • Zammad: the hardware page says requirements depend on agents, ticket volume, channels and install type, and gives two reference points. A minimal setup with PostgreSQL should not go below 2 CPU cores and 6 GB of RAM, plus 4 GB if Elasticsearch runs on the same server. An example setup for up to 40 agents is 6 CPU cores and 6 GB of RAM, plus 6 GB for Elasticsearch on the same server. The docs make no disk recommendation and note that Zammad stores identical attachments only once. The Docker Compose environment file has optional resource limits for each service, for example 500 MB for Memcached and Redis.
  • FreeScout: the README says there are no minimum CPU or RAM requirements and that FreeScout will run on any system, including shared hosting. That is the project’s claim; in practice, mail fetching frequency, attachment size and the number of modules decide the load. The Faster Search module uses Meilisearch if built-in search becomes slow.
  • osTicket: the docs give software requirements but no hardware sizing. It is a PHP and MySQL application, and the usual PHP tuning (OPcache, which the README recommends, and APCu) applies.

For a team of 14 to 30 agents, none of these is a capacity problem on a modern VM. The real limits are elsewhere: Elasticsearch memory for Zammad, mail provider rate limits during imports, and attachment storage growth when customers send phone videos.

Licences and editions

  • Zammad: AGPL-3.0, one edition. Zammad GmbH sells hosted plans (its pricing page lists Starter, Professional and Plus per agent per month, in euros, hosted in German data centres, with channels and features increasing by plan) and support packages for self-hosted customers, with yearly prices and service levels. Self-hosting gets every feature, including WhatsApp, SLAs, LDAP, SAML and OIDC, without a licence key. Optional AI features on the hosted plans have a per-call fee; self-hosted users connect their own AI provider.
  • FreeScout: AGPL-3.0 core with unlimited agents, mailboxes and tickets. Official modules are AGPL-3.0 code sold as lifetime licences per instance. There is no subscription, but a realistic helpdesk setup needs several modules, so budget for them up front. Because the module code is AGPL, you are allowed to read and modify it; what you buy is the licence key, updates and support.
  • osTicket: GPL-2.0, one edition, with free official plugins. Enhancesoft sells a hosted service and paid support and installation services.

Operations and day two

Install

  • Zammad: Docker Compose is the quickest way to get a complete stack, and the compose project includes a backup container. Packages suit teams that prefer system services. Either way, put a reverse proxy with TLS in front, set the FQDN and HTTP type in the settings, and, for Docker, change the default POSTGRES_PASS (the compose environment file shows zammad as the example) before the first start. Plan Elasticsearch memory from day one.
  • FreeScout: a LEMP or LAMP server, the web installer or the Ubuntu script, a cron entry for artisan schedule:run every minute, and file permissions for storage and bootstrap/cache. The advisory about the installer’s final page disclosing .env is a reminder to finish installation quickly and confirm the installer is no longer reachable.
  • osTicket: unzip, upload, run the installer, lock include/ost-config.php, delete setup/, configure cron for mail fetching, and download the plugins you need. A fresh install creates 67 tables with the default utf8 charset in the 1.18.4 install script we read.

Upgrades

  • Zammad: package upgrades follow your package manager; Docker upgrades change the image tag and run migrations through the init container. Major and minor releases often need extra steps, such as rebuilding the Elasticsearch index (7.0 and 7.2 both required it) or updating the Nginx configuration (7.0). Read BREAKING_CHANGES.md before every minor release. Zammad publishes minor releases a few times a year and security patch releases in between; 6.5 is out of support.
  • FreeScout: the built-in updater or git pull plus artisan commands, and module updates from the modules page. With six releases in October, set a fixed weekly slot rather than updating “when there is time”.
  • osTicket: download the new release, back up, replace the code (keeping ost-config.php and plugins), and run the upgrader from the admin panel if the database needs patches. The 1.18.4 package carries 126 upgrade patch files, and upgrades are supported from 1.6-rc1 onwards. Releases are infrequent, so the risk is forgetting, not fatigue.

Backups

  • Zammad: package installs ship zammad_backup.sh and zammad_restore.sh in /opt/zammad/contrib/backup. The docs list their limits clearly: always a full dump, no partial restore, no restore to an older version, environment variables not included, and the scripts do not work for container or source installs. The Docker Compose stack has its own backup service, scheduled by default at 03:00 with 10 days of retention. In both cases copy the dumps off the host and test a restore on a second machine. Elasticsearch can be rebuilt from the database, so it does not need a backup of its own.
  • FreeScout: back up the database (mysqldump or pg_dump), the storage folder with attachments (or the S3 bucket if you use the S3 module), the .env file and the Modules folder. A restore without the same APP_KEY will break encrypted values.
  • osTicket: back up the MySQL database, include/ost-config.php (which holds SECRET_SALT) and attachments if you moved them to the filesystem or S3 with a plugin; by default attachments live in the database, which makes the dump larger but simpler.

For the database side, see PostgreSQL backups in 2026, and for files and offsite copies, backups in 2026.

Migration from Freshdesk, Zendesk or a shared mailbox

Zammad’s built-in importers

Zammad has importers for Freshdesk, Kayako, OTRS and Zendesk, available from the setup wizard in the browser or from the Rails console for larger instances. The docs say they move tickets with their articles, groups or queues, organisations, and agents and customers. The limits matter more than the features:

  • Migrations work only on a new Zammad instance, and only from one source per instance.
  • They move all or nothing; you cannot choose specific groups, tickets or users.
  • Differential migrations are not supported. Run a test import first to learn how long it takes, then plan a cut-over window.
  • For Freshdesk and Zendesk, speed depends on the source plan’s API rate limits, and the plan must include API access, which the docs warn may not be true for every plan.
  • User passwords are not migrated; agents and customers reset passwords or use LDAP or single sign-on.
  • For Zendesk, objects with Cyrillic strings must be renamed first.
  • After import you log in with the admin email and the API token you used, then fix the FQDN settings.

Zammad 7.2.1 announced that import mode will also enable maintenance mode, and 7.2 made the health check report import mode as an issue, so plan for the system to be unavailable to agents during an import.

FreeScout: a module for Help Scout, a paid service for the rest

FreeScout’s migration page offers a Help Scout to FreeScout migration module for Help Scout users, and for every other helpdesk points to Help Desk Migration, a third-party paid service, which uses FreeScout’s API and Webhooks module. The page notes that ticket numbers from the old system cannot be kept, that agents should be created by hand first with a default agent for inactive ones, that the Tags module is needed if tags should move, and that a small demo migration is free before you pay for the full run.

osTicket: no importer

osTicket has no built-in importer from Freshdesk or Zendesk. Its API creates tickets from JSON or XML with a name, email, subject, message and attachments, which is enough for a script that creates one ticket per old conversation, but not for full history with agent replies in order. Teams moving to osTicket usually start fresh and keep the old system as a read-only archive, or pay a migration service.

From a shared mailbox

For all three, moving from a shared mailbox is mostly about not importing the whole archive. Point the helpdesk at the mailbox from a chosen date, let new and recent mail flow in, and keep the old mailbox read-only for search. Zammad can archive existing mail when you add an email account (the mailbox archive feature from 3.6), and FreeScout and osTicket fetch whatever is in the folder you point them at, so start with a clean folder.

What does not move, whichever tool you choose

  • Automations: triggers, workflows and SLA rules must be rebuilt. This is a feature; most old rules deserve rethinking.
  • Reports and dashboards: historical metrics such as first response times rarely carry over cleanly.
  • Integrations: CRM links, telephony connections and chat widgets on the website are new work.
  • Customer-facing links: old ticket URLs in customers’ email will break, and ticket numbers usually change.
  • Passwords: nobody’s password moves. Plan the first-login experience for agents and for customers who use the portal.

Side by side

Best fit

  • Zammad: a support team that handles several channels, needs SLAs, a knowledge base, reporting and proper roles, and wants every feature without licence keys.
  • FreeScout: a small to medium team that works mainly in email and wants a fast, simple shared inbox, buying only the modules it needs.
  • osTicket: an internal IT or facilities helpdesk, or a customer desk built around web forms with help topics, where stability and a simple PHP stack matter more than new channels.

Channels

  • Zammad: email, web form, chat, SMS, Telegram, WhatsApp, Facebook and phone via CTI, all in core.
  • FreeScout: email in core; chat, portal, WhatsApp, Telegram, Facebook, SMS as modules.
  • osTicket: email, web portal and API; phone tickets entered by agents.

Sign-in

  • Zammad: local with 2FA, LDAP, SAML, OIDC, Kerberos and social logins in core.
  • FreeScout: local in core; 2FA, LDAP, SAML and OAuth as modules.
  • osTicket: local with MFA; LDAP, OAuth2, CAS and pass-through as free plugins.

Migration

  • Zammad: built-in Freshdesk, Zendesk, Kayako and OTRS importers, new instance only, all or nothing.
  • FreeScout: Help Scout module; other sources through a paid third-party service.
  • osTicket: none built in; API for scripted ticket creation.

Operations

  • Zammad: heaviest stack (PostgreSQL, Redis, Memcached in containers, Elasticsearch), good backup scripts and a backup container, read breaking changes every release.
  • FreeScout: lightest stack, frequent releases with security fixes, modules to keep in step.
  • osTicket: light stack, rare releases, plugins downloaded separately.

Licence

  • Zammad: AGPL-3.0, single edition.
  • FreeScout: AGPL-3.0 core, AGPL-3.0 paid modules with lifetime licences.
  • osTicket: GPL-2.0, single edition.

A worked plan for Siddheshwar

Month 1: decide what support means

  • Count a normal month by channel: emails to support@, Freshdesk tickets, WhatsApp chats on the two phones, missed calls. Pradnya’s first rough count is the baseline every later decision is measured against.
  • Write a one-page support design: three or four groups (Farmer support, Dealer desk, Warranty, Billing), five ticket states, two priorities that mean something, and one promise per group, for example a first reply within four working hours for warranty complaints.
  • Decide the fields that matter: controller serial number, dealer code, district and crop season. Drop the rest.
  • Decide retention with management and counsel: how long closed tickets and installation photos are kept, and who can export them.
  • Ask Freshdesk support or check the plan to confirm API access is available, because Zammad’s importer needs an admin API key and the plan’s API limits decide import speed.

Month 2: build a test instance

  • One 6 vCPU, 16 GB VM in the Mumbai region for the pilot, which is a little above Zammad’s example for up to 40 agents with Elasticsearch on the same server. This is our judgement for headroom, not a vendor number.
  • Zammad 7.2.2 from the official Docker Compose project, with the image tag pinned, POSTGRES_PASS changed, TLS on the reverse proxy they already run, and the admin area reachable only over the office VPN.
  • The backup container enabled, dumps copied to object storage in another region every night, and one full restore to a second VM before any real ticket arrives.
  • Google sign-in for staff through Zammad’s third-party login, local accounts with two-factor authentication for the two admins as a break-glass path, and customer sign-up turned off.
  • A test import from Freshdesk into a throwaway instance. Record how long it takes, how many tickets fail, how custom fields arrived, and what agents must fix by hand. Remember the importer only runs on a new instance, so the final import will be on a fresh install, not on this test box.

Month 3: pilot with real work

  • The Dealer desk (four agents) moves completely to Zammad for four weeks, using a fresh instance with the final Freshdesk import done over a weekend. Freshdesk stays read-only for reference until the subscription ends.
  • support@ is connected through Zammad’s Google email channel for the Warranty group only, starting from that day’s mail. The old mailbox stays searchable.
  • Triggers for auto-acknowledgement in Marathi, Kannada and English, an SLA for warranty first replies, and three macros for the most common answers.
  • At the end of the pilot, the agents answer two questions: is it faster than before, and would you go back?

Months 4 to 6: channels, one at a time

  • Web form on the company website, with the new spam protection settings, replacing the “contact us” email link.
  • WhatsApp through the WhatsApp Business platform, tested first with one number for warranty. The team accepts the limits in writing: replies only within 24 hours of the farmer’s last message, no outbound templates from Zammad, one attachment per reply. For follow-ups after the window, agents call the farmer and log the call.
  • Phone only if their cloud telephony provider supports Zammad’s generic CTI; otherwise agents log calls as notes and the integration waits.
  • Field technicians get agent accounts with access to the Warranty group only, so they can read the ticket on a phone before a farm visit, replacing the “Field visits” spreadsheet for open complaints.

What we do not recommend for Siddheshwar

  • FreeScout would make a pleasant shared inbox for the dealer desk alone, but the company needs WhatsApp, SLAs, custom fields, workflows, reports and Google sign-in, which is six or more paid modules, plus a paid third-party service to move the Freshdesk history. With two IT people, a weekly release cadence across core and modules is also a real load.
  • osTicket fits internal IT ticketing well, and Pradnya may still use it for the company’s own IT requests. For farmer support it lacks WhatsApp and chat, has no Freshdesk importer, and its interface will feel dated to agents used to Freshdesk.
  • AI features: leave them off in the pilot. Zammad’s AI features are off by default and need an external LLM provider that will see ticket content, which includes farmers’ personal data. Decide that question separately, with counsel, after the basics work.

When not to adopt each

  • Do not pick Zammad if you cannot give Elasticsearch the memory it needs, if your team will not read release notes and breaking changes before each upgrade, or if you only need a shared inbox for two people.
  • Do not pick FreeScout if you need many helpdesk features on day one and do not want to depend on a growing list of paid modules, or if nobody can apply updates every week or two.
  • Do not pick osTicket if your customers live on WhatsApp and chat, if you need a built-in import from a SaaS helpdesk, or if agents expect a modern, real-time interface.
  • Do not self-host at all if nobody owns patching within days of a critical advisory, nobody tests restores, or mail deliverability is already a struggle. A hosted plan from the same project, or a SaaS helpdesk, may cost less than the risk.

A short history

  • osTicket: the oldest of the three. Its GitHub repository, created in August 2013, describes itself as the official repository for versions 1.8 and later, and the README says upgrades are supported from 1.6-rc1. Enhancesoft is the company behind it. It became the default “free ticket system” on many shared hosting panels.
  • Zammad: its repository was created in April 2012, and the first public release line, 1.0 and 1.1, arrived in late 2016 with a four-weekly release cycle at the start. It grew through WhatsApp (6.3, April 2024), OpenID Connect and the Microsoft Graph email channel (6.5, April 2025) to AI features in 7.0 (March 2026). MySQL support ended with 7.0.
  • FreeScout: its repository was created in June 2018, and it presents itself as a free, self-hosted alternative to Help Scout and Zendesk, developed from scratch. It has stayed on the 1.8.x version line since 1.8.0 in February 2022, adding features mostly as modules.
  • Others we looked at: Peppermint’s repository is archived on GitHub and its last release was 0.5.5 in November 2024. UVdesk’s community skeleton last released 1.1.8 in September 2025. Chatwoot is very active (v4.19.1 on 24 October 2026) but is a customer messaging platform rather than a classic ticketing helpdesk; it deserves its own post.

A simple decision guide

  • Do you need many channels, SLAs, a knowledge base, single sign-on and a built-in Freshdesk or Zendesk importer, all without licence keys? Choose Zammad.
  • Is your support mostly email, with a small team that wants a fast shared inbox and is happy to buy a few modules? Choose FreeScout.
  • Is it an internal IT or facilities desk, built on web forms and help topics, on a simple PHP and MySQL server? Choose osTicket.
  • Must you keep full history from Help Scout? FreeScout has a dedicated module. From Freshdesk, Zendesk, Kayako or OTRS? Zammad has built-in importers.
  • Can nobody patch within days of a critical advisory? Use a hosted service.

Checklist before go-live

  • A one-page support design: groups, states, priorities, fields and the promise to customers.
  • Channel list with owners: which mailbox, which WhatsApp number, which web form, which phone line.
  • Sign-in decided and tested, including a disabled staff account that must fail to log in.
  • Customer self-registration off unless you really need a portal, and if on, tested for what a customer can see.
  • Mail authentication set: OAuth for Google or Microsoft 365, or IMAP and SMTP with SPF, DKIM and DMARC aligned for the helpdesk’s sending address.
  • Default passwords and example secrets changed (POSTGRES_PASS for Zammad Docker, APP_KEY set for FreeScout, SECRET_SALT for osTicket).
  • Installer removed or unreachable (osTicket setup/, FreeScout installer).
  • Admin area reachable only from the office or VPN where possible.
  • Nightly backups of database and attachments, copied off the host, and one restore tested on a second machine.
  • Test import reviewed by the team lead, with a written list of what was fixed by hand.
  • Advisory feeds subscribed and an update slot booked every week or fortnight.
  • Retention period and deletion process for customer data agreed and written down.

Common mistakes

  • Importing the inbox, not the queue. Ten years of mail pulled into a helpdesk makes search slow and reports meaningless. Start from a date.
  • Copying old categories. Twelve “urgent” labels become twelve useless groups. Design fewer, clearer ones.
  • Promising WhatsApp support without reading the rules. The 24-hour window and customer-initiated limit decide how agents work, and your team must know them before customers do.
  • Running the helpdesk as admin. Agents with admin rights can read channel settings and, as this year showed, sometimes more. Give agents agent roles.
  • Leaving the installer. Both osTicket and FreeScout warn about it in their own ways; delete or block it.
  • Updating once a quarter. Zammad fixed 27 advisories in one release and FreeScout shipped six releases in October. Quarterly is too slow for a system that reads mail from strangers.
  • Forgetting the modules and plugins. In FreeScout and osTicket, the core version is only half the story; a module or plugin can lag behind.
  • Turning on AI before deciding who sees the data. An LLM provider will receive ticket text. Decide that on purpose.

Hands-on check: what we ran and what we did not

We kept this check small, user-level and inside /workspace/revisit/drill107 on our shared Linux box, on 2 November 2026 at about 6:24 PM IST, and it took a few minutes. We did not start any of the three helpdesks: Zammad needs Docker or system packages, FreeScout and osTicket need PHP, a web server and a database, and we did not install system packages, run Docker or start services for this post.

What we did:

  • Downloaded osTicket-v1.18.4.zip from the GitHub release (51,852,488 bytes). Its SHA-256, a4187df5...8151a7, matched the digest GitHub lists for the release asset. Inside, bootstrap.php reports v1.18.4, the fresh install script creates 67 tables with DEFAULT CHARSET=utf8, there are 126 upgrade patch files, the include/plugins folder holds only an updates certificate (plugins are separate downloads), and the sample config has placeholders for SECRET_SALT and the database host that the installer fills in.
  • Downloaded the FreeScout 1.8.249 source archive from GitHub. config/app.php reports version 1.8.249, composer.json declares the AGPL-3.0 licence, PHP 7.1 or newer and Laravel 5.5.40, there is an overrides folder with 31 patched third-party packages, 82 database migrations, an empty Modules folder, and an .env.example with an empty APP_KEY. Its SECURITY.md lists the design choices on mailbox moves and drafts that we quoted above.
  • Downloaded the zammad-docker-compose v17.5.4 release. The compose file defines eleven services, pins the Zammad image to 7.2.2-0024, PostgreSQL to 17.11, Redis to 8.10.3, Memcached to 1.6.45 and Elasticsearch to 9.5.5, publishes Nginx on port 8080, and schedules the backup service at 03:00 with 10 days of retention. The environment example uses zammad as the PostgreSQL password, which must be changed.
  • Pulled release dates and advisory counts for all three projects from the GitHub API, and read the Zammad and osTicket release announcements on their own sites.

What we did not do: run any of the three applications, test sign-in, connect a mailbox, import Freshdesk data, try WhatsApp or measure performance. Those need a proper VM with Docker or a PHP stack, a test mailbox and a copy of real data.

Unlearn and re-learn

  • Unlearn: “A helpdesk is a better inbox.” Re-learn: a helpdesk is a promise to customers with a queue behind it; write the promise first.
  • Unlearn: “Open source means everything is free.” Re-learn: Zammad gives every feature in one edition, FreeScout sells modules, osTicket gives plugins; check where your must-haves live.
  • Unlearn: “Once installed, a ticket system can be left alone.” Re-learn: this year’s advisories show that a helpdesk needs patching on the same rhythm as a mail server.
  • Unlearn: “WhatsApp is just another email address.” Re-learn: messaging channels come with the platform’s rules, and those rules shape your support process.

Sources

comments powered by Disqus

Releted Posts

Self-hosted video conferencing in 2026: revisit Jitsi Meet, BigBlueButton and LiveKit before you move another meeting off Zoom

Most Indian companies did not choose their video meeting tool. It arrived in a hurry in 2020, on a credit card, because people had to talk to each other from home.

Read more

Self-hosted file sync and share in 2026: revisit Nextcloud, Seafile and OpenCloud before you move another shared drive

Most Indian companies of a few hundred people have the same file story: an old Windows file server with mapped drives that only work in the office, personal Google Drive accounts used by the sales team on phones, and pen drives and large email attachments that nobody can track.

Read more

Self-hosted team chat in 2026: revisit Mattermost, Rocket.Chat and Zulip before you move another team off Slack

Sooner or later, every growing Indian company has the same conversation about chat. The free plan of a hosted chat tool has started hiding old messages, or the renewal quote for a paid plan has arrived for a few hundred users, or a large customer has asked where the project discussions are stored.

Read more