Open-source alternative to Freshdesk omnichannel and live chat: the short answer
If your support team runs live chat, WhatsApp, social messaging and email inside Freshdesk and you are facing a renewal, a cost increase or a data residency question, Chatwoot is the self-hosted option for the chat and messaging channels. The email ticketing decision is separate and should be made on its own terms. Chatwoot brings website live chat, email, Facebook, Instagram, Telegram, WhatsApp and SMS into one inbox, and its README also lists Twitter and Line, so confirm the channels your team actually uses against the current release before you plan around them.
For ticketing and email, Zammad is the main alternative to keep alongside Chatwoot. Zammad covers ticket queues, SLAs and email-based case handling in a model closer to Freshdesk's helpdesk, and it has a built-in Freshdesk migrator. Chatwoot can also take over email, which lets you run one tool for everything, but that changes how tickets, escalations and reporting work for agents who are used to Freshdesk. Map your current email volume and workflows before choosing. Chatwoot's Community Edition is licensed under the MIT Expat license, except the content in its enterprise directory, which carries a separate license, and third-party components keep their own licenses. Some capabilities sit in paid tiers: Captain AI, voice calls, custom branding and roles and permissions are in Premium Support, while SSO with SAML and SLA policies are in Enterprise Edition. Check those lists against your requirements, and ask for a written quote covering the tier, hosting and any support contract before you commit.
Which Freshdesk channel and inbox capabilities map to which open-source option
This table maps Freshdesk's channel, inbox, help center, automation and reporting capabilities to Chatwoot and Zammad. Read each row as what the open-source option documents, then confirm the gaps in a test instance or with the vendor before you commit. The main takeaway is that Chatwoot's documented channel list covers live chat and messaging apps, while Zammad's documented strength is email ticketing.
| Freshdesk capability | Chatwoot | Zammad |
|---|---|---|
| Website live chat | Website live chat widget is a listed channel; confirm widget customization and branding on your plan | Not in the supplied documentation; confirm whether a chat widget exists or pair with Chatwoot |
| Email ticketing | Email is a listed channel in one inbox; confirm threading, shared mailboxes and ticket states for your workflow | Core ticketing model; confirm group, state and shared mailbox setup against your current Freshdesk flows |
| WhatsApp, Facebook, Instagram, Telegram and SMS | All listed in the README; Twitter and Line are also listed; confirm each provider's account setup and fees | Not listed in the supplied documentation; confirm before committing to Zammad for these channels |
| Help center | Help Center portal for articles, FAQs and guides; confirm it meets your public site and language needs | Confirm whether a public knowledge base covers your current help center content and access rules |
| Automation and routing | Auto-assignment by agent availability, auto-responders, business hours, teams and labels are listed | Confirm triggers, escalation rules and macros in the version you plan to run |
| Reporting and CSAT | Conversation, agent, inbox, team and CSAT reports are listed; confirm report fields against your KPIs | Reporting depends on optional Elasticsearch, which the documentation says is strongly recommended |
| AI and integrations | Captain AI sits in paid Premium Support; Slack, Shopify, Dialogflow and Linear are listed integrations | Not in the supplied documentation; confirm AI and integration coverage with Zammad before migrating |
| Operating stack | Ruby 3.2 or later, Node.js 20.x, PostgreSQL only, Redis 7.0 or higher | PostgreSQL 15 or newer, Redis 7 or newer, optional Elasticsearch and Memcached for multi-instance setups |
Chatwoot, Zammad and a split design: which option fits which team
Freshdesk bundles live chat, messaging and email ticketing, so replacing it means deciding which of those jobs each open-source tool takes. The three options below differ mainly in whether chat, email or both move, and in which paid Chatwoot or Zammad features your team would need to buy.
Chatwoot alone for chat and messaging
Chatwoot fits teams whose volume comes mostly from website chat, WhatsApp, Facebook, Instagram, Telegram and SMS, with email as a secondary channel. It puts those channels in one inbox with a Help Center, auto-assignment, canned responses, teams and CSAT reports in the free Community Edition. The main trade-off is that email ticketing is not its core design, so check how your existing mailboxes, SLA tracking and ticket history will behave. Voice calls, custom branding, roles and permissions, and Captain AI sit in Premium Support, and SAML SSO and SLA policies sit in Enterprise.
Zammad alone for ticketing
Zammad fits teams whose main need is structured email and ticket handling, with a migration path from Freshdesk through its built-in migrator on a fresh instance. Zammad also supports web and phone channels, but it does not offer Chatwoot's breadth of social and messaging inboxes. The main trade-off is that live chat and WhatsApp-style conversations would stay on another tool or be handled through Zammad's own channel options, so confirm which channels your customers actually use before you commit. Zammad's self-hosted core has no license fee, and paid Business, Enterprise and Corporation support contracts are optional.
Chatwoot and Zammad as a split design
A split design keeps Zammad for email ticketing and routes live chat and social messages to Chatwoot, so each tool handles the work it is built for. It suits organizations that need strong ticket workflows and also many messaging channels. The main cost is running two systems, two databases, two sets of user accounts and two backup routines, plus agents switching between inboxes. Decide early whether customers see one contact record across both tools, and whether SAML or other single sign-on must cover both.
Premium features to price before you choose
Several capabilities that matter to larger support teams sit outside Chatwoot's free Community Edition. Premium Support at $19 per agent per month adds Captain AI, voice calls, custom branding, agent capacity, roles and permissions and priority support. Enterprise at $99 per agent per month adds SAML SSO and SLA policies. Ask which of these your agents need on day one, because the per-agent cost recurs as headcount grows, while the Community Edition carries no license fee.
Running Chatwoot beside Zammad or replacing both
Teams that already run email ticketing in Zammad can keep that queue and add Chatwoot only for website live chat and messaging channels such as WhatsApp, Facebook, Instagram, Telegram and SMS. Two systems then answer customers, so the boundary between them must be written down before cutover. Without that boundary, a message can land in neither queue or reach two agents at once.
- Channel ownership: Assign each channel to one system. Email stays in Zammad, while chat and messaging go to Chatwoot inboxes.
- Contact records: Chatwoot creates a contact for each visitor, and Zammad creates a customer for each email sender. Pick a matching key, such as email address or phone number, and name the person who merges duplicates.
- Handoff: Define how a chat that needs a formal ticket moves to Zammad, and whether the agent copies the conversation text or links back to it.
- Routing: Chatwoot auto-assignment and Zammad triggers and groups run independently. Document which system assigns each queue so no conversation is claimed twice.
Confirm how reporting will combine volume and response times from both systems before leadership relies on those numbers.
Chatwoot can handle email as one of its inbox channels next to chat and messaging, so a single tool can replace the Freshdesk channels and the Zammad email queue together. This path is a larger migration because the two products model work differently. Chatwoot conversations follow their own structure, so Zammad ticket numbers, states, priorities and groups need explicit mapping to Chatwoot equivalents.
- Mailbox cutover: Move each mailbox into a Chatwoot inbox and stop forwarding to Zammad on a dated schedule, so messages in flight are not split across two systems.
- Status and group mapping: Map every Zammad state and group to a Chatwoot status and team, and confirm how customer-facing reference numbers are kept.
- Historical data: Confirm whether Chatwoot offers an import path for closed tickets. If it does not fit your data, keep Zammad read-only or archive its export under your retention rules.
- Retirement timing: Keep Zammad running until the archive has been checked against your retention requirements.
Check which features you need, such as reporting depth or SSO, sit in the Community Edition or in a paid Chatwoot edition before you commit to this path.
Customers who use Freshdesk for public articles and solutions need a place to publish them after the move. Chatwoot's README lists a Help Center portal for articles, FAQs and guides, so it can host public documentation alongside its inboxes. The supplied material does not establish whether Zammad's knowledge base covers the same needs, so confirm that feature set before choosing where articles live.
- Export first: Freshdesk's account export includes solutions and forums as XML, so keep that file as the source for rebuilding articles.
- Conversion work: XML needs conversion before another tool can use it. Assign someone to rewrite internal links, images and categories.
- Public URLs: Article addresses will change. Plan redirects for links that customers, partners and search engines already use.
- Scope of the portal: Confirm which languages, brands and access rules the help center must support, and check that Chatwoot's portal covers them.
Check the help center layout and publishing workflow with a sample of articles before you move the full library.
Both products can take agents and customers from an identity provider, but the supported options differ by edition. Zammad lists third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers. The Chatwoot self-hosted plans page lists SSO with SAML in the Enterprise Edition at $99 per agent per month, so confirm whether OpenID Connect is available in your edition before you design around it.
- Agent directory: Decide whether agents in both tools come from one identity provider group, so leavers are removed in one place.
- Local accounts: If Chatwoot stays on a lower-tier edition without SAML, plan local agent accounts and their password and removal process.
- Customer master: Decide whether customer records are kept in one store or matched by email or phone number, and who resolves conflicts.
- Duplicate contacts: A customer who writes by email and by WhatsApp may appear twice. Define the merge rule and the approver.
- Routing ownership: Keep each queue's assignment rules in one system only.
Confirm SAML and OpenID Connect support, group mapping and any automated provisioning with your identity provider and the vendor before the design is final.
Moving chat, messaging and email data off Freshdesk
This sequence produces a Chatwoot or Chatwoot-plus-Zammad design that is agreed before any data moves, a fresh target instance, and channels that are tested and running in parallel with Freshdesk before cutover.
Inventory channels and integrations
Someone on the support operations team lists every channel Freshdesk handles today: website live chat widgets, the email addresses that feed tickets, WhatsApp, Facebook, Instagram, Telegram and SMS numbers, plus any connected apps such as Shopify or Slack. For each one, record the owner of the provider account, the volume and who answers it. Confirm with the vendors and your own admins which accounts and phone numbers you control, because the reconnection step depends on that. The step is done when you have a written channel register that every channel owner has reviewed.
Choose a Chatwoot-only or split design
Decide whether Chatwoot takes over email as well as chat and messaging, or whether Zammad keeps email ticketing alongside it. Chatwoot covers website live chat, email, WhatsApp, Facebook, Instagram, Telegram and SMS in one inbox, so a Chatwoot-only design means one platform to run. A split design keeps Zammad's ticket model for email while Chatwoot handles conversations. Check the requirements for each option against your register, and confirm feature needs such as SLA policies or SSO, which the Chatwoot self-hosted plans page places in its Enterprise Edition. The step is done when the design decision and its reasons are signed off by the support lead and the platform owner.
Export Freshdesk data as XML
A Freshdesk account administrator opens Admin, Account, Account Details and then Export data, which is available on all plans, to produce an XML export of tickets, solutions, forums and customers. Store the file in an encrypted location with access limited to the migration team. Chat transcripts and live chat history should be checked in the export, since it is a fallback copy and conversion work will be needed before another helpdesk can read it. The step is done when the export file is downloaded, its checksum is recorded and the admin confirms the file opens.
Build the target instance
Your platform team or DeployOpen deploys Chatwoot in your own infrastructure, using the Linux installation script, Docker or Kubernetes with the Helm chart. Chatwoot requires PostgreSQL as its only database, Redis 7.0 or higher and Ruby 3.2 or later, and the requirements page sets the CPU and memory guidance by daily conversation volume. If Zammad is part of the split design, build it on a new instance, because its migrator works only there. The step is done when the application starts, the admin account logs in and backups of the database are tested.
Configure channels and reconnect provider accounts
Create one inbox per channel in Chatwoot and reconnect each provider using accounts the organization controls. Install the live chat widget on the websites, set up the email forwarding for each mailbox, and re-create canned responses, teams, auto-assignment and business hours. Live chat history and channel connections usually have to be rebuilt rather than imported, so plan a clean start for each channel. Confirm with each provider that the connection is approved for your business account, because some channels such as WhatsApp depend on vendor onboarding. The step is done when a test message arrives and is answered in each inbox.
Import ticket history into Zammad where needed
If you chose a split design, run Zammad's built-in Freshdesk migrator on the new instance. The migrator is all or nothing, works only on a new instance and accepts one source system per migration, so run a test migration on a copy first and review the results. Expect that any conversion work from the XML file and any item the migrator does not carry must be rebuilt by hand. The step is done when the migration log is reviewed, sample tickets match Freshdesk, and the support lead accepts the gaps in writing.
Run a parallel period before cutover
Keep Freshdesk and the new inboxes live together while agents work in both, and route a small share of inbound traffic to the new channels first. Compare response handling, routing and customer replies, and log any channel that drops messages. Confirm with your security team how access, retention and audit logs apply to the new system before you commit. The length of the parallel period should be set by the support lead against the channel register, because no duration is fixed in the source material. The step is done when every channel has handled live traffic without missed messages and the cutover checklist is signed off.
Cut over and retain the Freshdesk export
Point each channel at the new inboxes, update website widgets and email forwarding, and disable the Freshdesk channel connections only after the new ones are confirmed. Keep the Freshdesk account and the XML export for a retention period set by your records policy and legal team. Document the final channel configuration in your runbook. The step is done when no inbound messages are reaching Freshdesk, the retained export is verified and the runbook is handed to the operations team.
What the self-hosted Chatwoot stack needs from your team
Running Chatwoot yourself means operating a Rails application with its supporting services, so the first decision is which runtime and data stores your platform team will own. Chatwoot requires Ruby 3.2 or later and recommends Node.js 20.x, and it supports only PostgreSQL as its database. Redis 7.0 or higher is also required. Chatwoot lists Ubuntu 20.04 as the only officially supported Linux distribution, so confirm with your own security team whether that release matches your hardening baseline before you pick a host image. Ask Chatwoot's maintainers or your DeployOpen scoping call to confirm the current supported list before build day.
Sizing is the second decision. Chatwoot's requirements guidance recommends at least 4 CPU cores and 4 GB of RAM for up to 10,000 conversations a day, and 8 cores and 8 GB of RAM for up to 20,000, plus at least 1 GB of swap. The same guidance notes that Sidekiq can use more than 1 GB of memory on a very active server. Measure your real conversation volume across live chat, email and social channels before you size, because a shared inbox with several busy channels can reach those thresholds sooner than a single website widget would suggest.
Deployment method shapes who patches what. The Linux VM installation script is the simplest path for a single server, Docker suits teams that already run containers, and the Helm chart for Kubernetes is documented for larger high-availability deployments. Whichever you choose, your operations team owns the Rails, Sidekiq, PostgreSQL and Redis upgrades, security patches, and tested backups of the database and attachments. Agree on a patch window, an owner for each component, and a restore test with your team before go-live, and confirm with your own environment which services will sit behind your load balancer.
What does moving Freshdesk live chat to self-hosted Chatwoot cost and take?
What are the cost components of running Chatwoot instead of Freshdesk chat?
The Community Edition has no license fee, so your cost is the infrastructure, the people who run it and any paid tier you choose. Expect four components: servers and managed services for the Rails application, PostgreSQL, Redis and background workers; staff time for installation, channel setup, upgrades and monitoring; migration and integration work; and optional subscriptions. The Premium Support tier is listed at $19 per agent per month and the Enterprise Edition at $99 per agent per month, both on Chatwoot's self-hosted plans page. Hosting and staff time recur every month, while setup and channel configuration are mostly one-time. Ask any provider to split the quote into these components.
Which Chatwoot features need a paid tier instead of Community Edition?
Premium Support adds Captain AI, voice calls, custom branding, agent capacity, roles and permissions and priority support. The Enterprise Edition adds SSO with SAML and SLA policies. Chatwoot's code is MIT Expat licensed except the enterprise/ directory, which uses its own license, so confirm with the vendor which features your plan needs before you design around them. Check your Freshdesk plan too, because some features you use there may need a different Chatwoot tier or a replacement such as a separate identity provider integration.
How long does moving Freshdesk live chat to Chatwoot take?
The duration depends mainly on the number of channels, the number of inboxes and teams, and how many integrations or automations you rebuild. A website widget and one email inbox are the smallest case. Each additional channel such as WhatsApp, Facebook, Instagram, Telegram or SMS adds approval, credential and testing steps, and Meta and WhatsApp business account verification often takes the longest because it depends on third parties. Chatwoot has no migrator from Freshdesk in the supplied sources, so historical conversations usually need a separate export and import plan. Ask a provider for a timeline that lists each channel separately, and confirm the timing with your own environment.
What must our team provide before a Chatwoot deployment starts?
Prepare the following before work starts:
- Admin access to Freshdesk for an export of your account, plus admin access to the chat and email systems that feed it
- A Meta business account for Facebook and Instagram, and a WhatsApp Business account with a verified number and API access
- Credentials for each Telegram bot, SMS provider and email mailbox you plan to connect
- A Linux host or cluster with PostgreSQL and Redis 7.0 or higher, and a DNS name and TLS certificate for the chat widget
- Named owners for agent accounts, teams, business hours and canned responses
Chatwoot's deployment requirements list Ubuntu 20.04 as the only officially supported Linux distribution, so confirm that your standard base image is covered.
Can our own IT team deploy and run Chatwoot without an outside provider?
Yes, if your team has Ruby on Rails, PostgreSQL, Redis and Linux operations skills and time for upgrades. Chatwoot documents a Linux VM installation script, Docker, and a Kubernetes Helm chart for larger high-availability deployments, so the technical path is well documented. The harder part is ongoing ownership: channel credentials expire, Meta and WhatsApp policies change and releases ship regularly, with v4.18.0 published on September 18, 2026. If you do not have that capacity, DeployOpen plans, implements, integrates, backs up, upgrades and supports self-hosted platforms in your own infrastructure under a fixed-scope written agreement, and ongoing support is available as a retainer.
Should Chatwoot replace Zammad for email, or run beside it?
Chatwoot can take over email along with chat, because its README lists email as one of the channels in its shared inbox. Keep Zammad alongside it when your ticketing workflow, escalations or SLA reporting already depend on Zammad's ticket model, since Zammad's migrators cover Freshdesk and its licensing is AGPLv3. Running two systems doubles the operations work, so price that in. Zammad's Business, Enterprise and Corporation support tiers are 2,999 EUR, 5,999 EUR and 9,999 EUR per year, according to the Zammad pricing page, and apply only if you buy Zammad support.
What should we ask a provider for in a Chatwoot quote?
Ask for a written scope that lists every channel, inbox, integration and automation to be built, and a cost split across infrastructure, implementation, channel setup, migration, training and ongoing support. Also ask who holds the Meta, WhatsApp and SMS accounts, how credentials are stored and rotated, what backup and restore testing is included, which Chatwoot release line you will run and how upgrades are handled, and how the quote changes if you add a channel later. DeployOpen provides a quote from that written scope, and does not publish a price list.
What infrastructure sizing does Chatwoot need for our conversation volume?
Chatwoot's requirements recommend at least 4 CPU cores and 4 GB of RAM for up to 10,000 conversations a day, and 8 cores and 8 GB of RAM for up to 20,000 conversations a day, plus at least 1 GB of swap. The same page notes that Sidekiq can use more than 1 GB of memory on a very active server. Measure your actual daily conversation volume and peak agent count before you choose instance sizes, and load test the chosen configuration in a non-production environment.
How to decide between Chatwoot-only and a split design
Start by counting channels and reading the email load honestly. If most of your customer contact arrives through the website widget, WhatsApp, Facebook, Instagram, Telegram or SMS, Chatwoot-only is a strong fit because its inbox was built to treat those channels as one queue. If email is the dominant channel and it carries formal ticket numbers, customer-visible status changes and contractual response targets, that points toward keeping Zammad for email ticketing. Pull three months of Freshdesk reports and split conversations by channel and by whether they need a ticket lifecycle. That split, not a feature checklist, usually settles the design.
Next, test your SLA and workflow requirements against the ticket model. Chatwoot offers business hours, auto-assignment and automation rules, and its README lists conversation and CSAT reports, but you should confirm in a pilot whether its conversation model covers the escalation rules, pending states and reporting your service levels depend on. Check SSO and role needs too. Chatwoot's SSO with SAML and its SLA policies sit in the Enterprise Edition, while agent capacity, roles and permissions and custom branding are in Premium Support, so price those tiers against the agent count you will have, and ask Chatwoot to confirm the current edition contents in writing.
Finally, decide who will run the platform. A Chatwoot-only design means one Rails, Redis and PostgreSQL stack, one upgrade path and one set of on-call duties. A split design adds a second application with its own database, backups and upgrade cadence, but it lets the email queue stay stable while the chat stack changes. If one team owns both, a split design is manageable. If chat is run by marketing and email by IT, a single platform with clear ownership usually reduces the risk of gaps. Whichever you choose, write the decision down with its owner, and ask DeployOpen or your own platform team to confirm the chosen design against your sizing and backup targets.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an omnichannel replacement, that means agreeing in writing which channels, inboxes and integrations move, and then building and testing them on infrastructure you control.
How we scope
- Inventory every live chat widget, email inbox, WhatsApp, Facebook, Instagram, Telegram and SMS channel your teams use today.
- Decide in writing whether Zammad keeps email ticketing alongside Chatwoot or Chatwoot takes over both.
- Agree a fixed scope with deliverables and timelines before any work starts, with the retainer option stated separately.
How we build
- Deploy Chatwoot with PostgreSQL, Redis and the Ruby on Rails stack on Linux, Docker or Kubernetes in your environment.
- Size compute, memory and swap against your expected daily conversation volume and the published requirements.
- Connect each channel, test routing, auto-assignment, business hours and CSAT reporting before cutover.
How we hand over
- Document the channel configuration, integration credentials handling, routing rules and admin procedures your team will run.
- Deliver backup and restore runbooks covering the database, attachments and Redis state, and test a restore.
- Train administrators and agents on the inbox, then confirm the final scope against the signed deliverables list.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan each Chatwoot and Zammad upgrade in a staging copy, including checks on channel connections after the change.
- Confirm with Chatwoot which features sit in its paid editions before you rely on them, since those are licensed separately from the community code.
