Who should leave Kayako Classic
This page is different from a normal "alternatives" list: with kayako-classic">Kayako Classic there is no scenario where staying is the long-term answer. Classic is the original self-hosted, PHP-based version of Kayako, and it is in maintenance mode — no new licenses are sold, no new features ship, and support has been wound down toward Kayako's cloud product. The only teams still on it are the ones who deployed it years ago, customized it heavily, and haven't yet migrated. If that's you, the question isn't whether to leave but where to land and how fast.
The urgency is a security one. A self-hosted application that no longer receives active development will, sooner or later, stop receiving meaningful security patches — and an internet-facing support portal holding customer data is exactly the kind of target you don't want running unpatched. Teams in regulated industries who chose Classic for on-premises data control are in the sharpest bind: the very compliance posture that justified Classic is undermined the moment the platform goes unmaintained. Move now, on your own timeline, rather than being forced to move later during an incident.
What to consider
- Direct cloud successor for complex deployments → Zendesk. If your Classic instance grew into a heavily-customized, multi-department, high-volume operation, Zendesk is the closest feature-for-feature landing — ticketing, help center, live chat, and voice in one Suite, 1,000+ integrations, and mature automation to rebuild your KQL-era workflows. Budget for the true cost (add-ons stack up well past the base rate).
- Easiest, cheapest cloud landing → Freshdesk. A genuine free tier and paid plans from $15/agent/mo make Freshdesk the lowest-friction exit from Classic. Multi-channel ticketing, SLAs, and a knowledge base cover the Classic feature set without the on-prem maintenance burden, and importers ease the data move.
- If Classic's "personal" support feel mattered → Help Scout. Teams that used Classic as a shared support mailbox rather than a heavyweight ITSM tool will feel at home in Help Scout's inbox-style interface. It's fast to set up, has a free plan for up to 5 users, and its AI resolves routine requests before they reach an agent.
- The self-hosted successor for data-residency teams → Zammad. If you must keep data on your own infrastructure, Zammad is the modern open-source answer: AGPLv3, free to self-host, with LDAP/AD/SAML/SSO out of the box and a REST API. It replaces Classic's on-prem control with a platform that's actually still being developed — and offers a managed cloud tier if you'd rather shed the server admin.
- Simplest free self-hosted ticketing → osTicket. A decade-plus-old open-source ticketing system that, like Classic, runs on PHP/MySQL on your own server — so it's familiar territory for your admins. Email piping, help topics, auto-assignment, and SLAs cover core needs at zero license cost, with a cloud edition from $12/agent/mo if you'd rather not host.
- Free shared inbox with unlimited agents → FreeScout. Another PHP/Laravel self-hosted option, FreeScout gives you unlimited agents and mailboxes for the cost of hosting, with optional modules for CRM, live chat, and knowledge base. It's the value pick for a small team that wants to keep data in-house without per-seat fees.
How to sequence your migration off Classic
Treat this as a project with a deadline, not a someday task. First, decide the cloud-vs-self-hosted question honestly: if the only reason you're still self-hosted is inertia, moving to Zendesk or Freshdesk removes the security-patching problem entirely and is the lower-total-effort path. If a real regulatory or data-residency requirement remains, choose Zammad (or osTicket/FreeScout for a leaner setup) so you keep control and get active maintenance.
Then protect your history. Export tickets, contacts, and knowledge base content from your Classic database while you still fully control it — that on-prem database is an asset for a clean migration. Use each target's importer or a specialist service (Help Desk Migration supports Kayako as a source) to bring the data across, stand up the new instance in parallel, redirect your support address, and only then decommission Classic. The goal is to retire the unmaintained platform before its aging code becomes someone else's way in.