Can Zammad replace ServiceNow Customer Service Management?
For external customer support, Zammad is the main self-hosted option, and internal IT can stay on GLPI or iTop. If your customer-facing support operation runs on ServiceNow Customer Service Management, you are facing a decision about one module, not the whole ServiceNow estate. CSM is sold separately from ITSM, so you can replace it on its own timeline while your internal service desk keeps running on its current platform. This page covers only the customer support module: inbound requests from customers, multichannel ticketing, a customer portal and a public knowledge base.
The separation matters for the decision. Renewal pressure, licensing changes or a data residency requirement often apply to the customer data held in CSM, which may be a different data set from your employee and asset records. Start by listing which record types, channels and integrations the CSM instance actually handles, and which of them customers touch directly. Then confirm with ServiceNow, in writing, the scope, term and export conditions of the CSM subscription, and check whether it is bundled with other ServiceNow products in your agreement.
Once the scope is clear, confirm the fit with your own requirements before any tooling work. Ask whether Zammad covers each channel your customers use, whether your portal and knowledge base requirements are met, and which identity provider your agents and customers need to sign in through. Zammad supports third-party login through SAML and OpenID Connect, among other providers, which you should verify against your directory. Treat the answers as hypotheses to test with a pilot group of agents rather than as settled facts.
Which CSM capabilities map to Zammad, and where the gaps are
This table maps the customer-facing capabilities of ServiceNow Customer Service Management to documented Zammad features and marks each as full, partial or confirm-with-vendor. Read the coverage column first, then the gap notes, because items that depend on ServiceNow's platform builders or field service need a separate review before you commit to a migration.
| Capability | Zammad coverage | Notes and what to confirm |
|---|---|---|
| Multichannel ticketing | Full | Zammad handles email, web form and phone-logged tickets in one agent view. Confirm the exact channels you need, such as live chat or social, against current Zammad channel options. |
| Customer portal | Partial | Zammad provides a customer-facing web interface for ticket creation and status. Confirm branding, self-service depth and custom portal pages against your current ServiceNow portal use. |
| Knowledge base | Partial | Zammad includes a knowledge base for public articles. Confirm search, versioning and article workflow needs before assuming parity with ServiceNow knowledge management. |
| SLAs and escalations | Partial | Zammad supports service level rules for tickets. Confirm how your SLA definitions, business hours and escalation paths translate, and test them with real ticket volumes. |
| Automation and triggers | Partial | Zammad uses triggers, schedulers and macros for routing and notifications. Deep multi-step workflow builders in the Now Platform have no direct equivalent and need a separate review. |
| Reporting and search | Partial | Elasticsearch is optional but strongly recommended for faster search, reporting features and searching attachment content. Plan its hosting and sizing as its own component. |
| Agent collaboration | Full | Agents work in shared ticket views with internal notes, mentions and ticket ownership. Confirm the collaboration features your teams rely on in ServiceNow. |
| Identity and login | Full | Third-party login supports SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab. Confirm your identity provider and customer login model, since customer accounts may differ from staff accounts. |
| API and integrations | Partial | Zammad exposes an API used for imports and integrations. Custom integrations with your CRM or ERP may need development, and rate limits depend on the design you choose. |
| Field service and Now Platform workflow builders | Confirm with vendor | Field service dispatch and deep Now Platform workflow builders are outside the documented Zammad scope. Treat them as a separate review item. |
Which open-source options fit customer support
Customer support needs differ from internal IT, so the right choice depends on your channels, team size and how much workflow the desk must carry. Zammad covers multichannel ticketing and portals, while lighter inbox tools and a ticket-centric system suit narrower needs.
Zammad for multichannel ticketing
Zammad is the primary fit because it is built around multichannel ticketing, with customer-facing portals and a knowledge base alongside agent work. It is licensed under AGPLv3, and its source code is owned by the Zammad Foundation, independent of Zammad GmbH, so you can review the code and host it in your own environment. Check which channels your teams need on day one, such as email, web forms and chat, and confirm how each is configured in your own instance before you commit to a migration plan.
Zendesk migration path
Zammad ships a migrator for Zendesk, which is the most direct route if your support queue already sits there. The migration needs an API token created by a full administrator, and user passwords are not carried over. Differential migrations are not supported, and rate limits depend on your Zendesk plan, so schedule a cutover window and confirm plan limits with Zendesk first. Migrations are all or nothing and work only on a new Zammad instance.
Running the Zammad stack
Zammad stores its content in PostgreSQL 15 or newer and needs Redis 7 or newer for realtime websocket communication, with Nginx or Apache as the reverse proxy. Elasticsearch is optional but strongly recommended for search, reporting and attachment content, and Memcached is needed for multi-instance deployments such as containers or cluster nodes. Plan for these components as ongoing operations, and confirm whether your Kubernetes support scope covers only the Zammad application.
Paid support for self-hosted Zammad
Self-hosted Zammad has no license fee, but Zammad GmbH sells support subscriptions named Business, Enterprise and Corporation for self-hosted installations. The pricing page lists Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year. Your own hosting, staffing and upgrade time are separate costs, so ask each vendor what a tier covers before you compare it with a hosted plan.
Lighter shared inboxes for small teams
FreeScout and Chatwoot are lighter shared-inbox tools that may suit smaller teams whose support runs mostly through email and chat handled by a few agents. They are usually a smaller installation to run, which makes them a reasonable starting point for a limited pilot. The trade-off is scope: confirm portal, knowledge base, reporting and integration needs against your current ServiceNow Customer Service Management use, because a lighter tool may need extra work later.
Znuny for ticket-centric support
Znuny is the GPL-3.0 continuation of OTRS Community Edition and centers on tickets, queues and agent workflow. It is package-based and offers an LTS release line, which matters if you want a slower upgrade cadence. Confirm whether the portal, knowledge base and multichannel features you need are covered by its add-ons in your environment, and whether your team already knows the OTRS model, before you select it for customer-facing work.
How Zammad runs alongside GLPI or iTop for internal IT
Internal IT and customer support can share one identity source without sharing one ticket queue. Zammad supports third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers, so staff accounts can sign in with the same directory that governs GLPI or iTop. Customers normally need a separate population in Zammad, and that population should never be granted internal agent rights. Decide early which directory is authoritative for agents, how role mapping works, and who approves access changes.
- Agent sign-in: Map Zammad agent roles to directory groups so access follows joiners, movers and leavers.
- Customer accounts: Keep customers out of the internal directory and confirm they cannot reach agent interfaces.
- Protocol choice: Confirm whether SAML or OpenID Connect fits your identity provider and what attributes it sends.
- Session and MFA: Confirm that multi-factor enforcement at the identity provider applies to Zammad logins.
- Break-glass access: Keep a documented local administrator path for when the identity provider is unavailable.
Before go-live, test login for an agent, a customer and a departed employee in a non-production instance, and confirm the exact attribute and group settings with the Zammad admin documentation for your version.
Asset inventory, configuration items and contract records belong in GLPI or iTop, where internal IT already tracks them. Customer tickets in Zammad should refer to the customer's product or account, not to the internal asset database. Mixing the two in one tool tends to expose hardware and software records to customer-facing roles, and it makes it harder to show which system is the record of truth for an audit. Define what each system owns before importing anything.
- System of record: Assign asset and CMDB data to GLPI or iTop only, and treat Zammad as the owner of customer conversations.
- Customer-facing fields: Expose only the product or account identifiers that customers need to quote in a request.
- Data flow direction: Decide whether any asset data is copied into Zammad at all, and if so, which fields and how often.
- Retention rules: Set different retention periods for customer correspondence and internal asset history.
- Access review: Include both systems in the same periodic access review so no one keeps a forgotten role.
Ask your compliance lead which system the auditors will treat as authoritative for each data category, and document the answer before designing any synchronization.
A customer complaint often becomes an internal incident, and the two records should point to each other without copying every comment. Zammad exposes an API that can create and update tickets from another system, which is the usual integration point for this handoff. The integration itself is custom work: someone must decide which customer ticket triggers an incident, which fields carry over, and how status changes return to the customer. Confirm each of these points against the API documentation for your Zammad version before you design the flow.
- Trigger rule: Define which Zammad state, tag or group creates an incident in GLPI or iTop.
- Reference fields: Store the external incident identifier on the Zammad ticket and the Zammad ticket number on the incident.
- Status return path: Decide how resolution is reported back to the customer and who sends that message.
- Error handling: Plan for failed API calls, duplicate creation and retries, with alerts to an owner.
- Service account: Use a dedicated API identity with the narrowest permissions that work.
Before building, run the flow end to end in a test environment with sample tickets and confirm the API token scope and rate limits with your Zammad and GLPI or iTop administrators.
The choice between one service desk and two depends on how different the work is, not on tool preference. Internal IT handles incidents tied to assets, changes and service levels, while support handles conversations with customers who never see internal records. A single desk simplifies reporting and has one queue to manage, but it requires tight role separation and can make customer views noisy. Two desks keep duties apart and reduce the risk of a customer seeing internal detail, but they add an integration to build and operate.
- Volume and mix: Compare how many customer requests become internal work, since frequent handoffs favor a tighter integration.
- Role separation: Two desks make it easier to show that customer users cannot reach internal records.
- Reporting: Decide which metrics must combine both sources, and whether a reporting layer is needed.
- Operating cost: Each desk adds administration, upgrades, backups and training, and the integration adds its own support.
- Exit planning: Two systems mean two migrations later, so record the data owner for each.
Ask your internal IT and support leads to write down the handoffs they expect each month, then review that list with your security team before choosing the model.
How to move customer tickets, users and knowledge base content
This sequence moves customer support history, contacts and help content from ServiceNow Customer Service Management into a self-hosted Zammad instance you control, with each stage ending in a check you can verify before the next one starts.
Inventory the ServiceNow CSM data set
Ask the ServiceNow administrator to list every table in scope: customer cases, customer accounts and contacts, case comments and work notes, attachments, knowledge articles, and catalog or portal content. Confirm with ServiceNow whether your instance can export each table, in which formats and at what record limits, and whether attachments need a separate extraction. The output is a signed-off inventory that states what will and will not be migrated. Do not assume that a standard export covers attachments, activity history or user credentials.
Extract and validate the export files
Run the agreed exports and store them in an encrypted location under your control. Your team, not the migration vendor, should open a sample of each file and compare record counts, timestamps and character encoding against the source instance. Confirm that case-to-contact and case-to-account references are intact. The check is a reconciliation sheet with counts per table that the support lead has reviewed.
Build the new Zammad instance
Install Zammad on infrastructure you control, using the package, Docker Compose or Helm options described in its documentation, with PostgreSQL 15 or newer and Redis 7 or newer. Add Elasticsearch if you need attachment search and reporting, and Memcached if you run multiple application instances. Because Zammad's built-in migrators work only on a new instance, do not load production data into a system that has already been used. The output is a tested empty instance with backups configured.
Map queues, groups, states and SLAs
Create a mapping workbook that links ServiceNow CSM assignment groups, case states, priorities and SLA definitions to Zammad groups, ticket states, priorities and escalation settings. Decide which ServiceNow fields become Zammad fields and which are kept only as archived notes. Agree the mapping with the support manager and record each decision. The check is a signed mapping document in which every ServiceNow state has a Zammad target.
Load tickets, users and history through a custom import
Zammad's built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk only, so ServiceNow CSM data needs the Zammad API or a custom import written for your mapping. Load users and organizations first, then tickets with their articles. Confirm explicitly whether attachments, comment history, timestamps and agent assignments survive the load, and whether passwords are migrated (they generally are not). The check is a set of sample tickets compared field by field with the ServiceNow originals.
Rebuild knowledge base and portal content
Move knowledge articles, categories and customer-facing portal text into Zammad's knowledge base and help pages. Recreate forms, links and images, and review each article for references to ServiceNow-only features that no longer apply. Configure third-party login such as SAML or OpenID Connect so customers and agents authenticate through your identity provider. The output is a published knowledge base reviewed by the content owner.
Run parallel access and test cutover
Before cutover, give a small pilot group of agents access to Zammad while ServiceNow stays live for new cases. Test inbound email routing, notifications, SLA timers and reporting against real but non-sensitive cases. Record defects and retest them. Because migrations are not differential, plan how cases opened after the export will be handled, either by re-exporting or by manually recording them. The check is a signed pilot report with no open critical defects.
Cut over and retain read-only evidence
Switch customer channels and the support mailbox to Zammad, close ServiceNow intake, and keep the old instance in read-only form for the retention period your legal and compliance teams set. Document the final reconciliation, the exit decision and the location of archived exports. Confirm that you can still produce records from the archive if a customer or regulator asks. The closing check is a cutover record approved by the service owner and the data protection lead.
What does replacing ServiceNow CSM cost and take?
What does self-hosted Zammad cost in licenses?
Self-hosted Zammad has no license fee, because the software is licensed under the GNU Affero General Public License version 3. The recurring commercial line is an optional support subscription. Zammad GmbH sells Business, Enterprise and Corporation support contracts for self-hosted installations, listed at 2,999 EUR, 5,999 EUR and 9,999 EUR per year respectively on the Zammad pricing page. Those list prices are the only figures we can quote here, so confirm current amounts on that page before budgeting. Whether you buy a subscription at all is a decision about how much vendor-backed support your team needs.
What are the real cost components of replacing ServiceNow CSM?
The real costs sit outside the software license. There are five main components:
- Hosting: servers or containers, PostgreSQL 15 or newer, Redis 7 or newer, and optionally Elasticsearch and Memcached, all in your cloud account or data center.
- Implementation: installation, configuration of channels, roles and SLAs, third-party login, and hardening.
- Migration: exporting from ServiceNow, mapping customers, organizations and tickets, and rebuilding any portal or knowledge base content that does not move cleanly.
- Staff: the administrators and support engineers who run and patch the platform.
- Optional support: a Zammad subscription or a services partner for upgrades and incidents.
Hosting and staff recur every year. Implementation and migration are mostly one-time costs.
What drives the cost of a Zammad replacement up or down?
The main drivers are ticket volume and history, the number of channels and integrations, and how much customization the customer portal and knowledge base need. Larger histories and more source systems raise migration effort. Running several Zammad instances or a cluster raises hosting and operations work, since multi-instance deployments need Memcached. Choosing to keep Elasticsearch for search and attachment indexing adds components to run. Fewer customizations, a single source system and a clean data export generally lower the total. Ask your team to inventory these items before requesting estimates.
How long does a ServiceNow CSM to Zammad migration take?
No duration is fixed in the researched facts, so the timeline depends on your scope. Zammad's built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk, and migrations run all or nothing on a new instance, with one source system per migration. ServiceNow CSM is not one of the built-in sources, so records are typically moved through the Zammad API or custom development. The schedule therefore follows the number of entities to map, the export approach, test cycles and cutover planning. Ask for a phased plan with written milestones in any proposal, and confirm the export and import approach with Zammad documentation before committing dates.
What must our team provide during a Zammad implementation?
Your team needs to provide the infrastructure target, identity provider access, a named business owner for support processes, and access to the ServiceNow CSM data needed for migration. Expect to supply:
- Cloud or data center capacity, plus network access for mail, channels and integrations.
- Administrators who can create an API token with full administrator rights for migration work.
- Subject-matter owners for queues, SLAs, roles, templates and knowledge base structure.
- Test users and sign-off authority for cutover.
These requirements should appear in the written scope, along with who owns each one.
Can our own team replace ServiceNow CSM without an implementation partner?
Yes, a team with Linux, PostgreSQL and web application experience can install Zammad using the documented package, Docker Compose or Kubernetes Helm chart paths. Migration and integration work is harder to do alone, because it needs careful mapping, API work for sources that have no built-in migrator, and tested cutover. Zammad support on Kubernetes covers only the application, not Kubernetes issues, so your platform team must own that layer. DeployOpen can plan, implement, integrate, harden, back up and document a self-hosted Zammad fixed-scope, with ongoing support available as a retainer, so you can decide which parts to keep in-house.
What should we ask for in a written quote for this migration?
Ask for a written scope that lists each deliverable, the source systems and data types in scope, and the acceptance criteria. Request separate line items for infrastructure, installation, channel and integration setup, migration, testing, cutover, documentation, training and post-go-live support. Ask how the quote handles data that cannot be migrated, such as comments, attachments and user passwords, which do not carry over in every path. Confirm the timeline milestones, the assumptions about your team's inputs, and whether the price includes a Zammad support subscription or assumes you buy one separately.
Does replacing ServiceNow CSM need a compliance review first?
Replacing the platform does not by itself make a service compliant, so plan a compliance readiness review before cutover. Customer support data often includes personal information, so confirm where data is stored, who holds administrator rights, and how access is logged and reviewed. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments, so ask your auditor which evidence they expect before scoping the work.
What you give up when leaving ServiceNow CSM
The main thing you give up when leaving ServiceNow Customer Service Management is the platform breadth that sits behind it. CSM runs on the same ServiceNow platform as ITSM, so customer cases can share workflows, catalog logic, reporting and identity with internal tickets. Zammad is a focused ticketing system: it covers multichannel ticketing, a customer portal and a knowledge base, and it integrates through its API, SAML, OpenID Connect and third-party login options. Before you commit, list every CSM workflow that calls ITSM records, such as escalations to incidents or changes, and decide whether that link becomes an API integration, a manual handoff or a process change. Confirm with Zammad's documentation which integrations you need to build yourself.
You also give up the vendor's support model. With ServiceNow you call the vendor and its partners for upgrades, incidents and configuration help under your contract. With Zammad, support depends on what you buy. Zammad GmbH sells support subscriptions for self-hosted installations named Business, Enterprise and Corporation, and the AGPLv3 license lets you run the software without one. The source code is owned by the Zammad Foundation, which is independent of Zammad GmbH. Ask any provider which tier covers your on-call hours, response expectations and Elasticsearch or Redis incidents, and whether your own partner will carry the escalation path.
Finally, you take on upgrades, patching and backups. Zammad published security releases on both lines in parallel: 7.2.1 and 7.2.2 for the 7.x line and 6.5.5 for the 6.5 line in October 2026. If you run an older line, you must track both release streams and schedule updates yourself. Your backup plan must cover PostgreSQL, attachments and the file or search indexes, and you should test restores on a schedule. Confirm the upgrade path, rollback steps and maintenance window with your operations team before cutover, and decide who has the on-call duty for patches when a security release lands.
How to decide whether to move support first
This sequence tells you whether moving customer support off ServiceNow Customer Service Management to self-hosted Zammad is worth doing first, and it ends with a documented go or no-go decision backed by a tested pilot.
Inventory how CSM is actually used
Your ServiceNow administrator and support team list every customer-facing channel, queue, form, knowledge article, SLA and integration that CSM touches today, with the owning team for each. Compare that list with what is used in practice by pulling recent case volumes by channel. The step is done when every queue and channel has a named owner and a yes or no answer on whether it stays in scope for the move.
Confirm your data can leave ServiceNow
Work with your ServiceNow administrator to check which export formats and record limits apply to your instance, and whether attachments and comments need a separate extraction. Test one full export of a closed-case queue and open it to confirm that case threads, customer identities and attachments came through. The step is done when a test export has been reviewed and its gaps are written down in a list you can act on.
Build a Zammad pilot environment
Your platform or IT team, with DeployOpen if you engage us, deploys a non-production Zammad instance inside your own infrastructure using the documented install method your team supports. Confirm the database and cache prerequisites in the software requirements, then configure one email channel and one web form. The step is done when the pilot runs with test accounts and an administrator can log in, send and receive mail, and search tickets.
Pilot a subset of queues with real agents
Choose a small set of low-risk queues and move them into the pilot, with a few agents working them in parallel with the existing CSM process. Track whether agents can complete the core tasks without workarounds, including escalations, reassignment, macros and reporting. The step is done when the pilot queues have run long enough for the support lead to sign off on a written list of gaps, each marked as fixed, accepted or blocking.
Verify integrations and identity
List every system that CSM talks to, such as identity providers, telephony, billing, product databases and any link back to ITSM, and confirm each has a Zammad equivalent or an agreed interim method. Check that single sign-on works with your provider, using the third-party login options Zammad documents for SAML or OpenID Connect where they apply. The step is done when each integration has a tested path, or a documented decision to build it later.
Confirm data residency and hosting obligations
Your compliance lead and legal team confirm where customer personal data may be stored, who may administer the system, and what logging, retention and backup rules apply to the new platform. Decide between self-hosting in your own environment and any vendor-hosted option, and record the answer. Ask your auditors which evidence they expect for the new system before cutover. The step is done when a signed residency and access decision exists and the backup approach has been tested with a restore.
Decide on full cutover with a written go or no-go
The support owner, IT lead and security lead review the pilot gap list, integration results, residency decision and export test together. They choose one of three outcomes: full cutover on a dated plan, a longer pilot with named open items, or staying on CSM for now. Confirm that the Zammad support tier you need, if any, is in a written quote before committing. The step is done when the decision is recorded, with its owner and the criteria used to make it.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the customer portal, ticketing and knowledge base needed to move customer support off ServiceNow Customer Service Management. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory the ServiceNow customer support channels, queues, SLAs, portal pages and knowledge articles in use today
- Confirm which channels Zammad must cover, such as email, web form, chat or phone, and which integrations stay
- Agree in writing the data to migrate, the data to archive, and the content to rebuild by hand
- Confirm hosting location, identity provider, and whether internal IT stays on GLPI or iTop
How we build
- Deploy Zammad on your infrastructure with PostgreSQL 15 or newer, Redis 7 or newer, and a reverse proxy
- Decide on Elasticsearch and Memcached based on search needs and whether the deployment runs multiple instances
- Configure third-party login through SAML, OpenID Connect or your existing identity provider
- Test a trial migration from your export on a new instance, since Zammad migrations run all or nothing
How we hand over
- Deliver documented configuration, backup and restore procedures, and a record of each migration run and its results
- Provide a reconciliation report comparing ticket counts, attachments and customer records against the ServiceNow export
- Document content that was rebuilt manually, such as portal templates, automations and notification rules
- Train administrators and agents on daily operation, role permissions and the upgrade path for Zammad releases
How we support
- Support after handover is available as a retainer covering upgrades, patching and monitoring of the Zammad stack
- Continuous security testing of the customer portal and API can be added to the retainer where the scope calls for it
- Ask for the support boundary in writing, including which tiers belong to DeployOpen and which to Zammad GmbH's support contracts
- Run upgrades on a test instance first, reviewing each Zammad release and its security notes before production
