Open-source alternative to HubSpot Service Hub

Open-source alternative to HubSpot Service Hub: when Zammad fits

Zammad is the main self-hosted option for help desk, ticketing and knowledge base work that teams currently run in HubSpot Service Hub. If your renewal, seat growth, data residency requirement or tier limits sit on the service side rather than the sales side, Zammad is the platform to evaluate first. It covers ticket handling across channels, a customer-facing portal and a knowledge base, and it runs in your own cloud account, data center or private network. Before committing, confirm with your team which Service Hub features you actually use, because some reporting, survey and automation features will need a different approach.

The CRM side does not have to move at the same time. Your contacts, companies and deals can stay in HubSpot Sales Hub or move to another self-hosted CRM, and the two systems can be linked through an integration or a shared customer identifier. Zammad is licensed under the GNU Affero General Public License version 3 (AGPLv3), and self-hosting it carries no license fee. The costs you will pay are infrastructure, implementation, migration, administration and, if you want one, a vendor support subscription. Zammad sells self-hosted support subscriptions named Business, Enterprise and Corporation, priced per year, so treat support as a separate line in your budget.

Plan the decision around the ongoing components rather than the software itself. Zammad stores its content in PostgreSQL 15 or newer and uses Redis 7 or newer for realtime updates, so your operations team needs to own those services, along with the reverse proxy and backups. Elasticsearch is optional but strongly recommended for search, reporting and attachment content search. Confirm with the Zammad documentation which of these your target architecture requires, and ask any implementation partner to price each component in the written scope.

Which Service Hub capabilities map to Zammad and where gaps remain

This table maps each HubSpot Service Hub capability to Zammad and to complementary open-source tools, marked as a direct fit, partial fit, or something to confirm with the vendor. Use it to scope which functions move as-is, which need a second tool, and which need verification before you commit. Customer success workspace and survey features in particular must be checked against Zammad's current feature set.

Service Hub capability	Zammad	Complementary open-source options
Help desk and ticketing	Direct fit: shared inbox, tickets, channels for email, web and chat, and per-group routing	Not usually needed; confirm your required channels such as phone or social are covered by Zammad or an add-on
Service level targets	Partial: Zammad supports SLA definitions, but confirm the escalation and calendar rules you use in HubSpot	Confirm with the vendor and test against your current HubSpot SLA policies before migrating
Knowledge base	Partial: Zammad includes a knowledge base feature; confirm publishing, categories and multilingual needs	Wiki or documentation platforms such as those in the knowledge base and wiki pillar if you need a standalone portal
Customer portal	Confirm with the vendor: check whether Zammad's customer-facing ticket view meets your self-service requirements	A separate self-hosted portal or front end may be needed if you need custom account pages or branded flows
NPS and CSAT surveys	Confirm with the vendor: verify whether Zammad sends satisfaction surveys natively in your version	Self-hosted form and survey tools from the forms and surveys pillar, linked to ticket IDs by webhook or API
Customer success workspace	Confirm with the vendor: this workspace is not a known core Zammad function, so verify before committing	Self-hosted CRM such as EspoCRM or SuiteCRM for account health records, linked to Zammad tickets
CRM linkage of ticket context	Partial: link tickets to customer records through the Zammad API and identifiers you maintain	Integration layer or workflow automation tools to sync ticket status and contacts with your self-hosted CRM

Which open-source option fits Service Hub ticketing best

Service Hub combines a help desk, knowledge base, customer portal and feedback surveys in one suite. Open-source replacements split these functions differently, so the first decision is whether ticket handling should live in a dedicated help desk or inside the CRM that already holds the customer record.

Zammad as the primary help desk

Zammad is a dedicated ticketing system licensed under the GNU Affero General Public License version 3, and it covers the multi-channel inbox, ticket queues and SLA-style workflows that Service Hub's help desk provides. It is the closest functional match for teams whose main need is support operations. Check that its channel set (email, web, phone or chat integrations) matches the channels your agents use today, and confirm each channel with your own test tickets before cutover.

Stack trade-offs for Zammad

Zammad stores its content in PostgreSQL 15 or newer and requires Redis 7 or newer for realtime websocket communication. Elasticsearch is optional but strongly recommended for faster search, reporting and attachment content search. Multi-instance deployments such as containers or cluster nodes also need Memcached. Your platform team must run, back up and patch each of these components, so budget that operational work alongside the software itself.

CRM-centric case handling in SuiteCRM

SuiteCRM 8 can hold cases alongside accounts, contacts and opportunities, so agents see the full customer record without switching tools. This fits organizations where service cases are tied closely to sales and account management. It usually offers less specialized ticket routing and channel handling than a help desk, so confirm the queueing, email intake and SLA rules you need. The sibling topic on SuiteCRM covers the case management migration in detail.

Knowledge base in a separate wiki

Service Hub's knowledge base is bundled with its ticketing. Zammad has its own knowledge base features, but many teams prefer a dedicated wiki so articles can serve staff, partners and public readers beyond support. If you choose a separate platform, agents and the portal need a single source for article links, and you must confirm how that platform handles access control and search. The knowledge base pillar on this site covers those options.

Customer portal and feedback surveys

Service Hub's customer portal and NPS or CSAT surveys are not a single built-in feature in every open-source option. Confirm whether Zammad's customer-facing features meet your portal needs, and plan a separate survey tool if they do not. Survey responses that link back to a ticket need a stable ticket identifier, so test that link before you commit to a design.

Support cost and what it leaves

Self-hosted Zammad has no license fee, but Zammad sells self-hosted support subscriptions named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to Zammad's pricing page. Whichever option you choose, the recurring costs are hosting, database and search operations, upgrades and the admin time needed to maintain workflows. Ask any implementation partner to quote these components separately.

How Zammad handles channels, SLAs and the customer portal

HubSpot Service Hub routes tickets from several intake points into one help desk. Zammad is built around email as its core intake, but the current release's full channel list should be confirmed in its documentation before you design routing around it.

Email: Confirm how shared inboxes, group routing and reply addresses map to the queues your team uses in Service Hub today.
Web and chat forms: Confirm whether a built-in web form or chat channel ships in the current release, or whether a plugin or custom integration is needed.
Phone and social: Ask for the channel list in writing, including whether call logging is native or entered by hand.
Historical tickets: Zammad documents migrators for Freshdesk, Kayako, OTRS and Zendesk. HubSpot tickets are not on that list, so plan an API or custom import and test it on a sample.
Routing rules: Write down every HubSpot routing rule and confirm which Zammad trigger or condition reproduces it.

Test each inbound path on a staging instance before cutover, and keep a record of which channels were verified.

Running Zammad next to HubSpot or another CRM

Moving a help desk does not have to mean moving the CRM in the same project. The four patterns below differ in who owns the customer record, how contacts and tickets are matched, and what breaks when the link between Zammad and the CRM fails. Pick the pattern that matches your data residency needs and your appetite for integration work.

Keep HubSpot, move only the help desk

HubSpot stays the system of record for contacts, companies and deals, while Zammad takes over tickets, email channels and the knowledge base. Zammad holds its own customer records, so the match key is usually the primary email address, which you must normalize on both sides. If the link breaks, agents see tickets without deal or lifecycle context, and HubSpot misses ticket status changes. Confirm which HubSpot ticket properties you still need and whether you will sync them in one direction or both.

Move both to a self-hosted CRM

When the CRM also leaves HubSpot, the CRM becomes the owner of the contact and company record, and Zammad references those records through an API integration. Identifiers should be the CRM record ID stored on each Zammad customer, with email as a fallback for matching during migration. If the API link fails, new tickets can still be created, but the customer link and deal history will drift until a reconciliation job runs. Ask your CRM vendor or integrator how the CRM exposes its REST API and how it handles duplicate records.

Zammad as sole ticketing system

Zammad becomes the only place where tickets live, and CRM records are exported on a schedule for sales and reporting use. Zammad owns ticket history and customer identity, and the CRM receives periodic snapshots keyed by email or external ID. The risk is staleness: between exports, sales may see outdated ticket counts or account health. The schedule and export format should be agreed with both teams in writing before cutover, and you should test a restore from the export files.

Split tickets from marketing data

Support traffic runs through Zammad, while newsletters, forms and campaign lists stay in a marketing tool. This keeps consent records and campaign history apart from support conversations, which matters when a customer opts out of marketing but still needs help. Identifiers must not be shared blindly, because a support email should not add a person to a campaign. If the link breaks, the only loss is cross-team reporting, not customer communication. Check how each marketing platform records consent before you map any field.

What feedback surveys need instead of HubSpot NPS and CSAT

NPS and CSAT in Service Hub are not a standalone feature you can copy across. They depend on HubSpot's survey delivery, response collection and reporting layer, which is tied to the contact and ticket records in the same portal. Before migration, decide three things separately: where responses are collected, where they are stored, and where scores are calculated and reported. Each can sit in a different system, and each choice affects who can see individual customer answers and how long they are kept.

The usual approach is to keep surveys in a self-hosted forms and surveys tool, such as one of the options covered on the forms and surveys pillar, and send a link to the survey when a ticket is closed. Zammad's public documentation and the sources supplied for this page do not confirm a built-in NPS or CSAT survey feature, so confirm this with Zammad before you plan around it. Ask specifically whether a ticket close can trigger an outbound survey link, whether responses can be written back to the ticket, and whether any score reporting is included or must be built from exported data. If the answer is no, the survey tool becomes your reporting source, and you need a clear rule for who owns that data.

Link each response to the ticket and contact through an identifier, such as the Zammad ticket number and a contact email or external ID, rather than by copying the full survey into the ticket. Carry the ticket identifier as a hidden field in the survey link so responses can be matched on import, and keep a retention rule for both sides. Test the join with a few closed tickets before cutting over, and confirm with your privacy lead whether customers were told their feedback is stored on your own servers. Ask the survey vendor or project team to confirm how the export looks, since matching errors are easiest to fix before historical HubSpot scores are imported.

How to move tickets, articles and users out of Service Hub

The sequence moves ticket history, contacts, companies and knowledge base content from HubSpot Service Hub into a self-hosted Zammad instance, with identities reconciled and a rollback path kept until the new desk is proven.

Inventory channels, SLAs, teams and articles
Your support lead and a HubSpot admin list every inbound channel, each ticket pipeline and stage, the SLA rules and business hours, the team and queue assignments, and every knowledge base article with its status. Map each item to a Zammad equivalent such as a group, trigger, SLA or macro, and note anything you will rebuild instead of carry over. The output is a signed-off mapping sheet that the migration scripts will follow.
Export tickets, companies and contacts
A HubSpot user with export permissions exports tickets, contacts and companies as CSV, XLSX or XLS files, with property values and associations included. HubSpot allows up to 300 exports in a rolling 24-hour window and up to three exports running at once, so plan batches around those limits and confirm current limits in the HubSpot knowledge base before starting. Store the raw files read-only with checksums. The output is a complete, dated set of source files with a record count for each object type.
Choose the import route
Zammad ships migrators for Freshdesk, Kayako, OTRS and Zendesk, and HubSpot is not on that list. Your engineers then choose between importing through the Zammad API, which requires scripting the mapping of exported rows to users, organizations, tickets and articles, or commissioning custom development from Zammad or a partner. Ask for a written estimate of effort for each route, and confirm that the chosen approach keeps ticket history and attachments intact. The output is a documented decision and a test plan.
Reconcile users and organizations
Match each HubSpot contact and company to a single Zammad customer and organization, using email address as the primary key and flagging duplicates and shared mailboxes for manual review. Decide which HubSpot users become Zammad agents and which roles and groups they receive, and plan single sign-on if you use SAML, OpenID Connect or a supported provider. The output is an identity map that lists every source record, its target record and any exceptions an owner has approved.
Load tickets and articles into a test instance
Import the mapped data into a non-production Zammad instance, running package, Docker Compose or Kubernetes installs as your platform team prefers, with PostgreSQL 15 or newer and Redis 7 or newer as required. Check ticket counts, states, timestamps, attachments and article bodies against the source files, and confirm that Elasticsearch search and Memcached caching are configured where your deployment needs them. The output is a reconciliation report with zero unexplained differences.
Run a parallel support period
Route new tickets to Zammad on a defined set of channels while HubSpot keeps running for the rest, and have agents answer from one system per customer thread to avoid split conversations. Compare SLA timers, escalations and assignment behavior daily, and log every mismatch with an owner and a fix. Ask your partner to document the test results so the cutover decision rests on evidence. The output is a signed parallel-run log that shows the new desk meets the agreed service levels.
Cut over with a rollback plan
Freeze HubSpot ticket creation on a set date, run a final incremental export and import, repoint inbound email and web forms to Zammad, and update the help center links. Write the rollback steps in advance, including how to re-enable HubSpot routing and which data would need re-export, and keep the HubSpot subscription active until the agreed retention and audit needs are met. The output is a closed cutover record and a retained HubSpot archive.

What the Zammad stack requires before go-live

Zammad is a single application with several supporting services behind it. Each component has a clear job, and some are optional, but the choices you make for database, caching and deployment method shape how the help desk runs day to day.

PostgreSQL for application content

PostgreSQL 15 or newer stores Zammad's tickets, articles, customers and configuration. It is the one component you cannot skip, so it becomes the system your backup and recovery plan must protect first. Confirm your database team can operate it with point-in-time recovery, and check that the version you deploy matches the Zammad release you choose, since the requirements page sets the minimum.

Redis for realtime updates

Redis 7 or newer carries the websocket traffic that pushes new tickets and updates to agents without a page refresh. Without it, agents lose live updates, so treat it as a required service in production. Plan for it to be monitored and restarted with the rest of the stack, and confirm the high-availability approach your platform team uses for it.

Nginx or Apache as reverse proxy

A reverse proxy terminates TLS, forwards requests to the Zammad application and passes websocket connections through. Nginx or Apache are the documented choices. Decide early where certificates are issued and renewed, how the proxy is hardened, and how it fits your existing ingress or load balancer standards so agents and customer portal users reach one consistent address.

Elasticsearch for search and attachments

Elasticsearch is optional, but Zammad strongly recommends it. It speeds up ticket search, drives reporting features and indexes the content of email attachments. Without it, search across large ticket volumes and attachment text is limited, which matters for SLA reporting and for finding past cases. Budget an extra service to patch, back up and size, and confirm which search capabilities your team needs before you skip it.

Memcached for multi-instance deployments

Memcached is needed when you run several Zammad application instances, for example in containers or cluster nodes, so that they share cache state. A single package installation can use the file system cache instead. Choose the topology first: one server suits a small team, while replicated containers or Kubernetes need Memcached from the start.

Install path and Kubernetes support limit

Zammad documents package installation, Docker Compose and a Kubernetes Helm chart. On Kubernetes, Zammad support covers only the Zammad application, not cluster issues. Your platform team owns the cluster, storage classes, ingress and node operations. Pick the install path your operations team can run and patch, and agree in writing who handles cluster-level incidents before go-live.

How much effort, time and internal work does a Service Hub move take?

What are the cost components of moving HubSpot Service Hub to Zammad?

The software has no license fee when self-hosted, so the cost is made up of infrastructure, migration and integration work, support, and admin time. Hosting covers the application server, PostgreSQL 15 or newer, Redis 7 or newer, and optional Elasticsearch and Memcached nodes for multi-instance deployments. Migration and integration work is usually the largest one-time item. Zammad also sells self-hosted support subscriptions named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to Zammad's pricing page. Ask any quote to separate one-time items (setup, migration, integrations) from recurring items (hosting, subscription, patching, admin hours).

What drives the effort of a Service Hub move up or down?

Effort rises with the number of tickets to migrate, the number of SLA policies, the number of custom integrations with other systems, and the size of the knowledge base. Each SLA and escalation rule has to be rebuilt and tested, and each HubSpot workflow tied to tickets needs a Zammad equivalent or a decision to drop it. Zammad includes migrators for Freshdesk, Kayako, OTRS and Zendesk, but HubSpot is not on that list, so a HubSpot move relies on the Zammad API or custom development. Knowledge base articles usually need reformatting and link checks. Ask the provider to size these four drivers in writing before agreeing on a fixed scope.

Can our own team move HubSpot Service Hub to Zammad without an outside partner?

A team with Linux, PostgreSQL and reverse proxy experience can install Zammad from the documented package, Docker Compose or Helm chart paths, but the migration and integration work is where teams most often stall. An illustrative small team might own the server and admin setup while an outside provider handles the HubSpot export mapping and API import. If you keep the work in-house, assign one owner for data mapping, one for integrations and one for cutover testing. Be honest about the time those roles take alongside existing service duties. Confirm what your staff already runs before deciding.

What does the work need from our staff during the move?

Your staff must supply decisions and subject matter knowledge that no installer can supply. These include which ticket states, priorities, queues and SLA targets to keep, who owns each queue after cutover, and which HubSpot automations are business rules rather than habits. Agents need time to test their queues in a staging instance and to review sample migrated tickets. Administrators need to confirm login integration, such as SAML, OpenID Connect or Microsoft and Google sign-in. Plan these reviews into the schedule before the migration starts, not after.

How should we plan around HubSpot export limits during a Service Hub migration?

HubSpot lets users with export permissions export tickets and other records as CSV, XLSX or XLS files, with associations and property values included. HubSpot allows up to 300 exports in a rolling 24-hour window and up to three exports running at once, according to HubSpot's knowledge base. Plan extraction in batches that stay under those limits, export a test set first, and keep a dated record of each export. Start the full extraction early enough that a second pass for tickets created during the move fits within the window. Ask the migration provider to show how they handle ticket-to-contact associations in the export files.

How do we keep Zammad security patches current across release lines?

Zammad published security fixes in parallel on two lines: security release 6.5.5 on 15 October 2026, alongside 7.2.1 on 6 October 2026 and 7.2.2 on 8 October 2026, according to Zammad's releases page. Choose one supported line at install time and record it in your change log. Subscribe to the releases page, test each patch in a staging copy that mirrors your Elasticsearch and Redis setup, and schedule a fixed patch window with a rollback plan. Ask any provider to name who applies security releases, how fast they respond, and whether that service is in the quote or a recurring retainer.

What should a quote for a Service Hub to Zammad move include?

A written quote should list the fixed scope and each deliverable separately, including installation, hardening, data migration, integration with other systems, knowledge base transfer, staff training and cutover support. It should state what is one-time and what recurs, including hosting, the Zammad support tier if chosen, security patch handling and admin hours. Ask for the assumed ticket volume, number of SLA policies and integrations, and the exclusions, such as the customer portal design or survey replacements. DeployOpen works from a written scope agreed before work starts and does not publish a price list, so ask for a quote tied to these items.

How DeployOpen scopes and delivers a Service Hub replacement

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Service Hub replacement, that means turning help desk, portal, knowledge base and feedback survey requirements into a written scope on Zammad before any build work starts.

How we scope

Inventory every Service Hub ticket pipeline, inbound channel and SLA rule your teams rely on today
Decide which customer portal, knowledge base and survey functions move to Zammad and which stay elsewhere
Agree in writing how ticket context links back to CRM records and which fields sync

How we build

Deploy Zammad with PostgreSQL 15 or newer, Redis 7 or newer and a reverse proxy in your environment
Configure channels, SLA rules, roles and SSO through SAML, OpenID Connect or your identity provider
Test migration of ticket history with sample exports before any production cutover

How we hand over

Document architecture, configuration decisions, integration logic and the runbook for operators
Deliver tested backup and restore procedures so ticket data and attachments can be recovered
Train administrators and agents on the configured workflows and record what each team owns

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
Ongoing support, version upgrades and security patch rollouts are available as a retainer
Confirm with us which Zammad support tier and component scope your retainer covers before you sign