Open-source alternative to Salesforce Service Cloud

Which open-source option replaces Salesforce Service Cloud

If your support team runs on Service Cloud and faces a renewal, a licensing change or data residency pressure, the primary self-hosted replacement for case management, channels and knowledge is Zammad. It is licensed under AGPLv3 and covers ticketing across email and other channels, with a knowledge base and third-party login. SuiteCRM cases are the better fit when support must stay inside the CRM, so that accounts, contacts and cases share one data model. The choice turns on where your support work lives today, not on feature checklists alone.

Start by mapping the channels you actually use: email, web forms, chat, phone or social. Confirm each one against Zammad's channel documentation and against the SuiteCRM modules you would need, because channel coverage differs sharply between the two. Next, write down your SLA rules, escalation paths and the integrations that push or pull case data, such as the telephony system or the order system. Ask each vendor or implementation partner to demonstrate these against your own workflows, not a demo dataset. Zammad's operational needs, including PostgreSQL 15 or newer, Redis 7 or newer and optional Elasticsearch for search, should be sized against your ticket volume during planning.

Service Cloud's AI agent features have no direct open-source equivalent. Agentic deflection, generated replies and automated case triage will need to be rebuilt with separate tools, or dropped, and that work belongs in the cost model from the start. Treat this as a gap to plan around, not a detail to settle later. Also confirm which of your SLA, routing and knowledge features you rely on daily, because those are the features users will notice first if they are missing after cutover.

Service Cloud capabilities mapped to Zammad and SuiteCRM

This table maps the main Service Cloud capabilities to Zammad and SuiteCRM 8, with notes on partial matches. The last column lists what to verify in a proof of concept before you decide. Zammad suits ticket-centric service desks, while SuiteCRM 8 suits service handled inside a wider customer record, and neither is a drop-in match for Salesforce's AI agent features.

Capability	Zammad	SuiteCRM 8	Confirm before deciding
Case management	Ticket-based case handling with email-first intake, agent assignment and groups	Cases module linked to accounts and contacts in the CRM record	Case types, queue structure and required fields for your process
Omni-channel routing	Email, web form and channel integrations feed one agent queue	Cases are created in the CRM; routing relies on workflows or add-ons	Which channels (chat, voice, social) are native and which need integrations
Knowledge management	Knowledge base capability available; confirm it in your release	No dedicated knowledge base module confirmed on this page	Article workflow, versioning and public access, or a separate wiki
Digital engagement	Web-based customer contact and self-service options; confirm depth	Customer portal depends on configuration or add-ons	Chat, messaging and portal features your customers need today
AI agents	No direct equivalent to Service Cloud AI agents confirmed here	No direct equivalent to Service Cloud AI agents confirmed here	Any AI triage, reply drafting or agent features in current versions
SLAs and escalations	Service level and escalation rules are configurable; confirm per version	SLA timers and escalations are typically built with workflows	Business-hour calendars, breach alerts and escalation paths
Reporting and dashboards	Reporting uses Elasticsearch, which is optional but strongly recommended	Reports and dashboards are built in; confirm scope for service metrics	Ticket volume, response and resolution metrics your leads use
Sign-in and access	SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab	LDAP or SAML; SAML does not support IdP-initiated logout	Agent roles, identity provider logout behavior and group mapping
Hosting requirements	PostgreSQL 15 or newer, Redis 7 or newer, Memcached for multi-instance	PHP 8.2 to 8.4, Apache 2.4 and MariaDB or MySQL per compatibility matrix	Versions supported by your platform team and your database standards

When Zammad or SuiteCRM cases fit a support team

Service Cloud bundles case management, omni-channel routing and knowledge into one platform. In open source, the two realistic homes for cases are a dedicated helpdesk, Zammad, or the case module inside SuiteCRM. The right choice depends on whether support work should live beside the sales record or in its own queue.

Zammad as a dedicated helpdesk

Zammad is a standalone helpdesk licensed under the GNU Affero General Public License version 3, so it fits teams whose support queue is the center of the workflow and whose sales data stays in another system. It stores content in PostgreSQL 15 or newer and needs Redis 7 or newer for realtime updates. Check whether your channels, such as email, chat and phone, need connectors beyond the core install, and whether your SLA rules map to its escalation settings. Expect a small platform stack to operate, including Elasticsearch if you want strong search.

SuiteCRM cases inside the CRM

SuiteCRM keeps cases in the same database as accounts, contacts and opportunities, which suits service teams that need to see the full customer history without switching tools. The trade-off is that its case handling is a module within a CRM, so routing depth and omni-channel features need to be tested against your own queues. Confirm the scope of support work you expect before committing, because a heavy ticket volume may outgrow a module built for CRM records.

Who maintains SuiteCRM

SuiteCRM is maintained by SuiteCRM Ltd, which is free to download and self-host, but the company also sells paid services around the software. These include the SuiteASSURED support package, SuiteCRM Hosted, implementation, training and migration. Ask whether you need a paid support contract, and what the vendor commits to in writing for security fixes. Your internal staff or a partner would handle the rest of the operating burden.

Upgrade cadence for SuiteCRM 8

SuiteCRM 8 minor releases arrive roughly every eight weeks, and patch releases carry only security and bug fixes. That cadence is useful for planning, but it means your team must test each minor release on staging before rollout. Check the extended support status before choosing a version line, because no SuiteCRM 8 extended support release had been nominated when this page was written. Ask the vendor when one is expected.

Knowledge and SLA gaps to check

Service Cloud pairs case work with knowledge management and digital engagement, and open-source options cover these in different ways. Zammad supports migrators from Freshdesk, Kayako, OTRS and Zendesk, which helps when moving historical tickets, but confirm how knowledge articles and macros transfer. For SuiteCRM, confirm that SLA timers, queue assignment and knowledge articles meet your requirements before building the process. Treat AI agent features as a separate gap that needs its own assessment.

How the deployment path differs by team size and environment

A package installation on one host suits a small support team, a pilot or a department that wants a contained first deployment. Everything runs on one machine, so the set of components is small and easy to reason about, but the same machine is also the single point of failure for the service and its data.

Core services on one host: Zammad stores its content in PostgreSQL 15 or newer and uses Redis 7 or newer for realtime websocket communication, with Nginx or Apache as the reverse proxy.
Cache without Memcached: single installations can use the file system cache, so Memcached is not needed unless you later add more application instances.
Search decision made early: Elasticsearch is optional but strongly recommended for faster search, reporting and searching email attachment content, so decide before go-live whether to install it on the same host or a separate one.
Ownership of the whole stack: your team patches the operating system, backs up the database and attachments, and applies every Zammad upgrade, with no vendor boundary between layers.
Recovery planning: restoring a single host is the whole recovery plan, so document rebuild steps and test restores on a staging host.

Before you commit, confirm the supported operating system versions and the exact PostgreSQL, Redis and reverse proxy versions in the software requirements for your release.

Running Zammad alongside Salesforce Sales Cloud

Many teams keep Sales Cloud for opportunities and move only ticket handling to Zammad. The split works when identity, customer matching and data ownership are settled before cutover. The cards below cover the decisions and integration work that connect the two systems.

Single sign-on across both systems

Zammad supports third-party login through SAML and OpenID Connect, so agents can sign in with the same identity provider that already fronts Sales Cloud. Confirm which identity provider holds the authoritative user list, how deprovisioning works when an agent leaves, and whether Sales Cloud SSO and Zammad SSO use the same group claims. Test the sign-out path too, because a session ended at one system may stay open in the other.

Matching tickets to customer records

Zammad creates customers from the sender address of incoming email, so the simplest link to Sales Cloud is the email address. Decide what happens when one person uses several addresses, when a shared mailbox sends for many accounts, and when a contact exists in Sales Cloud but not in Zammad. Store the Salesforce record ID in a custom Zammad field where you can, so lookups do not depend on email alone.

Syncing contact data

Contact changes such as a new phone number or a moved account have to reach both systems. Zammad exposes a REST API, and Salesforce provides its own APIs, but neither product ships a finished bidirectional connector between them. Plan a one-way sync for the first phase, typically from Sales Cloud to Zammad, and document field-level rules for any direction you add later. Ask any integration partner to state its error handling and retry behavior in writing.

Deciding which system owns customer master data

Only one system should be the source of truth for account and contact fields. Sales Cloud is usually the stronger candidate because sales owns the commercial relationship, but support teams often need fields that sales does not track, such as entitlement or preferred language. Write down the owner for each field before the integration is built. Without this decision, two sync jobs will overwrite each other and nobody will know which value is current.

Bidirectional sync is custom work

Two-way sync needs conflict rules, change timestamps, and a way to handle records edited in both systems within the same minute. It is custom integration work with ongoing maintenance, not a configuration setting in either product. Ask for the conflict resolution logic in writing, a test plan with sample records, and a named owner for the integration after go-live. Budget for updates when either product's API changes.

Access and audit boundaries

Support agents often need to see only the accounts they serve, while sales reps need the opportunity history. Map Sales Cloud profiles and permission sets to Zammad groups and roles, and review what data gets copied into tickets. Ticket history in Zammad is a second copy of customer data, so include it in retention rules, data subject requests and any export you run for audits.

How knowledge base and SLA rules move to open source

Service Cloud knowledge articles and entitlement-based SLAs do not move as objects. In Salesforce, an entitlement attaches service terms to an account or contact, and milestones drive response and resolution timing. In Zammad, SLA definitions apply to tickets according to conditions such as group, priority and customer, so each Salesforce entitlement needs a deliberate mapping to a Zammad SLA. Knowledge articles need a separate path. Export article content, categories, versions and visibility from Salesforce Knowledge into structured files, then load them into Zammad's knowledge base through its API or custom import work. Zammad's documented migrators cover Freshdesk, Kayako, OTRS and Zendesk, so a Salesforce knowledge import is custom work. Read the Zammad migration documentation before estimating it.

Expect to rebuild several rules by hand. Salesforce milestone escalation actions, business hours tied to each queue, holiday calendars and entitlement exceptions each need a Zammad equivalent that you define and test. Article approval and publishing states from Salesforce Knowledge also need a documented review step in Zammad, since you should not assume the two publishing models match. Decide early whether Elasticsearch is part of the design. Zammad documents it as optional but strongly recommended for faster search, reporting features and searching email attachment content, and without it, article search and reporting depth may fall short of what agents use today.

Before you commit, run the rules in a staging instance. Create one SLA per entitlement type, then push test tickets through first response, escalation and breach thresholds, including tickets that arrive outside business hours and on a holiday. Confirm in writing how Zammad reports SLA breaches and whether the reports cover the cuts your service managers use. Import a sample of articles with their visibility settings, then check that agents and customers see only what they should. Record every gap between the test results and current Service Cloud behavior, because those gaps become the scope of the custom work and the decisions for the cutover.

Moving cases, users and channels out of Service Cloud

This sequence moves open cases, agents, queues and channels from Service Cloud into Zammad in an order that keeps every ticket traceable and gives the support team a tested routing and SLA setup before cutover. Each step ends with a check the team can sign off.

Inventory cases, queues and channels
The support lead and a Salesforce administrator list every case record type, status, priority value, queue, assignment rule, entitlement and SLA milestone in use, along with each inbound channel such as email, web forms, chat, phone and social. Note which Service Cloud features, such as omni-channel presence or AI agent actions, have no direct Zammad equivalent so they can be handled as explicit decisions. The output is a signed inventory document that maps each Salesforce object and field to a Zammad ticket attribute, group or channel. Confirm the mapping with the team leads before any export runs.
Define knowledge and content scope
The knowledge manager decides which Salesforce knowledge articles, article versions and attachments stay in scope, and which are retired. Articles are then sorted by status and owner so that only current content moves. Zammad's knowledge base is set up as a separate target, so the team checks whether articles will be re-created in Zammad's knowledge base or kept in an existing wiki. The output is an approved list of articles with a target location for each one.
Export cases, contacts and attachments
An administrator extracts case, contact, account, article and attachment data using Data Export Service or Data Loader. Data Export Service delivers CSV files in a compressed archive on the cadence Salesforce documents for the edition, so the team confirms the edition and the last export date before relying on it. Data Loader suits repeatable scripted extracts that include related records. The output is a versioned export set with row counts per object, checked against the Salesforce record counts from the inventory.
Map and import into Zammad
Zammad includes migrators for Freshdesk, Kayako, OTRS and Zendesk, but none for Salesforce, so the Salesforce extract is loaded through the Zammad API or through custom import code written by Zammad or a partner. A developer maps case IDs, contact emails, owners, groups and states, and keeps a crosswalk table linking each old case number to its new Zammad ticket number. The output is a test import into a staging instance, reviewed by agents who spot-check a sample of tickets against Salesforce for content, timestamps and attachments.
Migrate users, roles and groups
Agents and supervisors are created in Zammad and assigned to groups that mirror the Salesforce queues and public groups. Sign-in is set up through a supported third-party method, such as SAML or OpenID Connect, so accounts follow the identity provider and do not need separate passwords. Role permissions are checked against what each Salesforce profile allowed, and any gap is documented. The output is a user and group list that the team approves, plus a test login for each role.
Rebuild routing, triggers and SLAs
The team re-creates assignment logic, escalation rules, SLA targets and business hours in Zammad, using the inventory from the first step as the specification. Each rule is tested with sample tickets that cover each channel and priority. Automation that relied on Salesforce Apex, flows or AI agent actions is listed as a gap and either rebuilt with Zammad triggers, scheduled jobs or external integrations, or formally retired. The output is a test log showing each rule fired as expected, with failures tracked to closure.
Connect channels and run parallel support
Email inboxes, web forms, chat and phone integrations are pointed at Zammad on a staging address first, then on production addresses during a planned cutover window. For a defined period both systems stay live, and agents record any case that is created or updated in the old system so the crosswalk stays accurate. The team reviews missed messages, duplicate tickets and SLA timers each day. The output is a cutover checklist signed by the support lead, confirming that all channels deliver to Zammad and that Salesforce is set to read-only.
Retire Service Cloud access and archive
Once the parallel period closes and open cases are either closed or migrated, Salesforce case and user access is removed and a final export is archived with the crosswalk table and migration logs. Retention rules from the organization's policy decide how long the archive is kept and where it is stored. Confirm with your legal or compliance team what must be kept. The output is an archive record with a hash or inventory list, and a note that Salesforce access has been removed for all users.

Questions buyers ask before replacing Service Cloud

How much does it cost to replace Service Cloud with self-hosted Zammad?

The software itself costs nothing to license, because self-hosted Zammad is open source under the AGPLv3. Your total comes from the components you pay for: infrastructure to run the application, PostgreSQL, Redis and Elasticsearch (optional but strongly recommended), implementation and configuration, data migration, support and internal admin time. Infrastructure and admin time recur every year, while implementation and migration are mostly one-time. Zammad's self-hosted support subscriptions are listed at 2,999 EUR per year (Business), 5,999 EUR per year (Enterprise) and 9,999 EUR per year (Corporation), according to Zammad pricing. Subscriptions are optional. Ask vendors for quotes against a written scope that lists channels, integrations, number of agents and migration sources.

How long does it take to implement Zammad for a support team?

The duration depends mainly on how many channels, integrations and workflows you need, how much history you migrate, and how many people must review the configuration. A small team that uses email and a web form with few automations will move far faster than a team that routes phone, chat and social channels through custom logic. Zammad documents installation with packages, Docker Compose and a Kubernetes Helm chart, so the platform setup itself is usually the shortest step. Ask for a timeline in the written scope, and confirm which migrators apply to your current helpdesk, since Zammad includes migrators for Freshdesk, Kayako, OTRS and Zendesk, and other systems require the API or custom development.

Can our internal IT team self-host Zammad without outside help?

Yes, many teams with Linux and container experience can run Zammad themselves, but the work is more than installing one application. Your team needs to manage PostgreSQL 15 or newer, Redis 7 or newer, a reverse proxy such as Nginx or Apache, backups, upgrades and TLS. Multi-instance deployments also need Memcached, and search and attachment indexing depend on Elasticsearch. On Kubernetes, Zammad support covers only the application, so cluster issues fall to your platform team. Be honest about who will carry patching: Zammad has published security releases on more than one line in the same period, so someone must watch the release feed and apply them. Consider whether a support subscription or a retainer for upgrades fits your team.

Which Service Cloud channels and SLA features does Zammad not cover?

Zammad covers the core ticket channels, but you should map each Service Cloud feature you rely on before committing. Confirm email, web form, chat, phone and social channel support in the current release notes against your actual channel mix, because omni-channel routing in Service Cloud is tightly tied to Salesforce's presence and queue features. Confirm SLA escalation rules, business-hour calendars and skills-based routing in your own test instance rather than assuming parity. Document every routing rule and SLA target in writing so the gap analysis is concrete. Any feature without a clear equivalent should be listed as a custom build or a process change in the scope.

Does Zammad replace Service Cloud knowledge base and AI agent features?

Zammad includes knowledge base capabilities, but you should verify them against your current Service Cloud use before relying on them. Salesforce describes Service Cloud as combining case management, omni-channel support, knowledge management, digital engagement and AI agents on one platform. Zammad's documented strengths sit in ticketing, email handling, third-party login and search, so confirm article workflows, publishing approvals and search quality on your own content. AI agent features in Service Cloud have no direct open-source equivalent in Zammad that this page can confirm. If you need automated resolution or generative assistance, plan it as a separate component and check its data handling against your residency and security requirements.

Can Zammad sign in through our existing identity provider?

Zammad supports third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers, according to the Zammad admin documentation. Check which protocol your identity provider uses and test role mapping for agents, supervisors and administrators before go-live. Confirm how deprovisioning works when someone leaves, because access removal in the identity provider does not always translate automatically into the helpdesk. Your security team should review session lifetime, multi-factor policy and audit logging against your internal standards.

What does the migration from Service Cloud involve for cases and attachments?

Migration typically covers exporting cases, contacts, accounts, knowledge articles and attachments, mapping them to Zammad's ticket, customer and organization model, and testing with real historical tickets. Salesforce's Data Export Service provides CSV files in a compressed archive on a weekly or 29-day cadence depending on edition, and Data Loader supports scripted extraction, according to Salesforce Trailhead. Attachments and knowledge content may need separate handling, so confirm what each export includes. Plan a parallel run, a cutover window and a rollback path, and budget migration effort as a one-time cost in your quote.

What is DeployOpen's role in a Zammad replacement project?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. For a Service Cloud replacement, that can cover the Zammad deployment, identity integration, channel configuration, data migration, backup and upgrade routines, and documentation of workflows. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.

What the Service Cloud AI agent features leave without a direct equivalent

Salesforce describes AI agents as part of Service Cloud, alongside case management, omni-channel support and knowledge management. None of the open-source options covered on this page is supplied with a feature that replicates those agents directly, so treat agent-driven deflection, case summarization and automated resolution as a gap until a vendor confirms otherwise. Ask Salesforce which agent capabilities depend on Data Cloud, Einstein or specific Salesforce licenses, since those dependencies decide whether any part of the feature set can move at all.

You have two practical paths. The first is to keep the AI features in Service Cloud during transition, running Zammad or SuiteCRM for the core ticket and knowledge workflows while the agents stay in Salesforce. This keeps two systems and two data flows alive, so the reader should map which case fields and knowledge articles the agents read and write, and plan how those sync. The second is to build bounded automation separately, such as rules that route tickets, suggest knowledge articles or draft replies that a human approves. Zammad exposes an API and webhooks that such tools can call, but the reader should confirm the exact trigger and authentication options in the current documentation before scoping any build.

Whichever path you choose, put any AI feature through the same data review you apply to the CRM itself. Confirm where prompts, transcripts and customer records are processed, whether a model provider or subprocessor sees them, and who approves changes to the automation. Write these checks into the scope before work starts, because a fixed-scope build is easier to test and to hand over when the boundaries are written down.

How DeployOpen scopes and delivers a Service Cloud replacement

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the case management, channel routing and knowledge base work behind an open-source alternative to Salesforce Service Cloud. Engagements start with a written scope that separates what Zammad or SuiteCRM must replace from what needs custom work or a decision from your team.

How we scope

Inventory every Service Cloud case queue, entitlement rule, channel and knowledge article that must move, with its current owner.
Document which channels (email, web, chat, phone) and which SLA timers the replacement must reproduce, and which ones you will retire.
Agree deliverables, timelines and acceptance criteria in writing before work starts, with the AI agent features listed as in or out of scope.

How we build

Deploy Zammad or SuiteCRM in your cloud account, data center or air-gapped network, with PostgreSQL, Redis and the search and cache services your design requires.
Configure groups, roles, SLA rules, identity sign-in through your identity provider, and channel integrations against the agreed scope.
Test case routing, escalation, notifications and knowledge search with your support staff before any cutover, and record the results.

How we hand over

Deliver architecture, configuration, runbooks and a record of each customization so your team can operate the platform after handover.
Run migration rehearsals on a staging copy of exported case history and attachments, with a documented rollback path.
Train administrators and agents on the configured workflows and give your team a written list of gaps that remain after cutover.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after go-live, scoped in writing.
Apply vendor security releases to a staging environment first, then to production, and document each change.
Confirm with the vendor which support subscription, if any, fits your environment, since self-hosted Zammad support is sold separately.