Open-source alternative to HubSpot Service Hub: the short answer
If your support or service team runs on HubSpot Service Hub and faces a renewal, an edition change or a data residency concern while Marketing Hub may stay where it is, the main self-hosted options are Zammad and Znuny. Both cover the core service workload: help desk and ticket handling, SLA rules, a knowledge base and a customer-facing portal. Zammad is licensed under the GNU Affero General Public License version 3, and Znuny continues the OTRS Community Edition 6.0.30 line under GNU GPL v3, so you should check each license against your own legal review before committing. Service Hub is a separate product, not a module that Marketing Hub depends on. HubSpot sells it with Free, Starter, Professional and Enterprise tiers, and it can be used alone or with Marketing Hub and Sales Hub. That matters for scope: a replacement project only needs to move the service module, so your contact records, forms and campaigns can stay in place while tickets move. HubSpot's Service Hub page lists a help desk workspace, omnichannel communication, call tracking, SLA management, service analytics, a knowledge base, a customer portal, and NPS and CSAT feedback surveys. Map each of these to a specific component in Zammad or Znuny, or to a plugin or external tool, and write down which ones your team uses daily. Two items need confirmation before you decide. Call tracking is not a standard help desk function in either platform, so confirm with the vendor or a implementation partner whether telephony integration and call attribution meet your needs. Service analytics also varies: Zammad documents reporting features that depend on Elasticsearch, so confirm which dashboards and metrics your managers rely on will be available in your chosen setup. Ask both vendors for a written feature comparison against your current Service Hub reports before you plan the move.
Which Service Hub capabilities map to Zammad and Znuny
This table maps each HubSpot Service Hub feature to the self-hosted Zammad and Znuny ticketing systems. Where the researched product information confirms a capability, the cell says so, and where it does not, the cell names what to confirm before you commit. Use the last column as a proof of concept checklist, because gaps and add-on needs depend on your channels, telephony and survey requirements.
| Service Hub feature | Zammad | Znuny | What to verify in a proof of concept |
|---|---|---|---|
| Help desk workspace | Ticket queues and agent workspace for help desk teams | Ticketing for customer service, help desk and IT service management | Both cover the core. Test queues, roles and agent views with your own ticket volumes. |
| Omnichannel communication | Email and web channels in the base product; confirm other channels and add-ons | Email-based ticket intake; confirm chat, social and messaging channels | Map every channel agents use today. Test inbound and outbound replies end to end. |
| Call tracking | No documented core feature; confirm telephony integration options | No documented core feature; confirm telephony add-ons with the vendor | Call tracking usually depends on a telephony provider. Decide which system owns call records. |
| SLA management | Confirm SLA rules, escalation and business hours in your version | Confirm SLA and escalation features against your ITSM configuration | Write SLA targets as test cases. Check how breaches, pauses and holidays are calculated. |
| Service analytics | Reporting features rely on Elasticsearch, which is optional but strongly recommended | Confirm reporting and dashboard capabilities in the current feature release | Elasticsearch adds a component to size, run and back up. Confirm report outputs your managers need. |
| Knowledge base | Confirm knowledge base module and public article access | Confirm knowledge base module in the Znuny edition you choose | Plan article migration and access rules. Some teams run a separate wiki, so confirm the fit. |
| Customer portal | Confirm customer self-service portal and ticket visibility controls | Confirm customer portal and customer user access model | Check customer login options. Zammad supports SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab. |
| NPS and CSAT surveys | Confirm built-in survey support or plan an external survey tool | Confirm built-in survey support or plan an external survey tool | Survey responses are customer data. Keep them on your servers or confirm the hosting of any external tool. |
Zammad or Znuny: which helpdesk fits which team
Zammad and Znuny both replace the ticketing core of Service Hub, but they differ in license, stack and the skills your team needs to run them. The cards below cover the decisions that separate them: license terms, database and cache requirements, install options, migration sources and vendor support.
License terms for self-hosting
Zammad is licensed under AGPL-3.0, and Znuny is distributed under GPL v3. Both are open-source licenses that allow self-hosting without a license fee, but the AGPL adds source-sharing obligations if you modify Zammad and make it available over a network. Ask your legal team to review how that applies to any custom code your integrators write before you choose.
Database and cache requirements
Zammad stores its content in PostgreSQL 15 or newer and needs Redis 7 or newer for realtime websocket communication. Znuny runs on MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later or Oracle 19c or later. If your database standard is MySQL or Oracle, Znuny fits without a new engine, while Zammad adds a Redis service to operate.
Application stack and skill set
Znuny runs on Linux, preferably Debian or Red Hat, with Perl 5.16.0 or higher and Apache 2 with mod_perl2 recommended. Teams with Perl and Apache administrators can run it with existing skills, while Zammad's Ruby-based stack and its Nginx or Apache reverse proxy suit teams already operating modern web services. Confirm which skills you have in-house before choosing.
Search and caching for scale
Zammad uses Elasticsearch for faster search, reporting and searching email attachment content. It is optional but strongly recommended, and Memcached is needed for multi-instance deployments such as containers or cluster nodes. Single installations can use the file system cache. Plan these services as extra components in your architecture and their operating cost.
Install options and vendor support
Zammad documents package installation, Docker Compose and a Kubernetes Helm chart, but on Kubernetes its support covers only the Zammad application, not Kubernetes-specific issues. 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. Znuny offers professional services from Znuny GmbH in Berlin. Ask each vendor what support covers before you sign.
Migration source and import path
Zammad includes migrators for Freshdesk, Kayako, OTRS and Zendesk, and other systems can be imported through its API or custom development. Znuny is a continuation of OTRS Community Edition 6.0.30, so teams moving from OTRS usually find the closest data model there. If your source is HubSpot Service Hub, both platforms require an export and a custom mapping step.
Running the helpdesk next to HubSpot Marketing Hub and CRM
This is the lowest-disruption path: marketing campaigns, forms and CRM stay in HubSpot, and only the help desk, ticket queues and SLA timers move to Zammad or Znuny. Tickets then live in the self-hosted platform, while the customer's contact and company records remain in HubSpot as the sales and marketing source of truth. The two systems must agree on who the customer is, so the integration usually matches on email address and stores the external identifier on each side.
- Ticket ownership: Tickets, attachments, internal notes and SLA clocks sit in the help desk database, not in HubSpot.
- Contact references: Store the HubSpot contact ID on the help desk customer record so agents can open the CRM profile from a ticket.
- Sync direction: Decide whether HubSpot pushes contact changes to the help desk, the help desk pushes ticket status to HubSpot, or both run, and keep one side authoritative for each field.
- Batch load: The HubSpot Contacts API supports batch endpoints of up to 100 records per request, which helps with initial backfills and periodic reconciliation.
- Marketing contact tier: Ticket volume does not change marketing contact billing, but any service-driven contact updates should be checked so they do not create new marketing contacts.
Before committing, confirm with the chosen platform and integration partner which HubSpot objects and fields the connector supports, and whether it is maintained for your Zammad or Znuny version.
When the organization also retires HubSpot CRM, contacts, companies and deal history must be exported and loaded into a self-hosted CRM, and the help desk then references that CRM as the customer master. This setup avoids a permanent sync, but it puts more work into the CRM migration and the cutover date. Ticket history from HubSpot can be imported into the help desk only if the migration path supports it, so the team should plan for the ticket export separately from the record export.
- Export scope: HubSpot record exports cover contacts, companies, deals, tickets and custom objects, but limits apply to how many exports can run in a day, so plan the sequence.
- Customer identity: Pick one primary key (usually email plus an internal customer ID) and map every ticket to it before loading history.
- Ticket history: Zammad includes migrators for Freshdesk, Kayako, OTRS and Zendesk, and other sources need the API or custom development, so HubSpot tickets may need a script.
- Parallel run: Keep HubSpot read-only for service records during a short overlap so agents can search old conversations.
- Cutover scripts: Freeze new ticket creation in HubSpot before the final delta load to avoid duplicate or lost conversations.
Ask the migration partner to write down how each ticket field, attachment and internal note maps, and what is left behind.
Some teams keep HubSpot contacts as the single customer identity because sales, marketing and service all rely on them, and the help desk becomes a specialized system that references those records. In this model the help desk stores tickets and conversation history, but it looks up customers through the HubSpot record, so identity errors in HubSpot propagate to support. It suits organizations that already maintain disciplined contact data in HubSpot and want agents to see deal and marketing context without a second customer database.
- Lookup pattern: The help desk queries HubSpot by email or ID when a ticket arrives, then caches only the fields agents need.
- Data minimization: Cache the smallest set of fields, and define how long cached personal data is kept in the help desk.
- Failure handling: Decide what agents see when HubSpot is unreachable, since the help desk must still accept and route tickets.
- Duplicates: Merge rules in HubSpot determine which contact a ticket follows, so align deduplication before go-live.
- Access control: Confirm that help desk agents only receive the HubSpot data their role permits, because API tokens often grant broader access.
Confirm the caching, retention and token scope with the platform owner and your privacy team before building the lookup.
Across all three setups, the ticket is the record of service work, while HubSpot holds the commercial and marketing picture. The practical question for auditors and data owners is where each category of personal data is stored, how long it persists, and who can export it. Self-hosting moves ticket content, attachments and search indexes into infrastructure you operate, which adds backup, retention and deletion duties that the SaaS vendor previously carried.
- Ticket content: Messages, attachments and internal notes reside in the help desk's PostgreSQL database and file storage.
- Search indexes: Zammad documents Elasticsearch as optional but strongly recommended for search and attachment content, so index data needs the same retention rules as tickets.
- Caches and sessions: Redis and memcached hold short-lived state, but confirm what is cached and for how long.
- Deletion requests: A data subject request may touch both HubSpot and the help desk, so document a single procedure for both systems.
- Backups: Backups of the help desk now carry customer data, so align their retention with the policy that covers HubSpot exports.
Record the data map for each setup and confirm retention and deletion behavior for each system in your own environment.
The integration is usually the riskiest part of this move, and it depends on the connector, the help desk version and your HubSpot subscription. Treat every capability below as something to verify in writing, not something to assume from the product name. Scope the integration as a fixed set of fields and events, and test it with copies of real but anonymized data before any cutover.
- Connector coverage: Confirm which HubSpot objects, properties and associations the connector reads and writes.
- API limits: Check the rate limits and batch sizes that apply to your HubSpot tier and plan backfill windows around them.
- Version support: Confirm the connector supports the Zammad or Znuny release you will run, including security releases.
- Error handling: Require retry behavior, alerting and a reconciliation report for failed syncs.
- Testing: Run a full sync test with a subset of contacts and tickets before the production cutover.
Ask the implementation partner for a written integration specification that lists each supported field, the sync direction, and the test results.
Moving tickets, customers and knowledge out of HubSpot
This sequence moves tickets, customer records, SLA rules and knowledge base articles from Service Hub into a self-hosted Zammad or Znuny instance in a controlled order, so each stage can be checked before email and channels are switched over.
Inventory channels and SLA rules
Before any data moves, list every channel that creates tickets today: web forms, shared inboxes, phone call tracking, live chat, and the customer portal. Write down each SLA rule, its response and resolution targets, the business hours it runs on, and the escalation paths tied to it. Confirm with service leads which ticket properties, pipelines and statuses are actually used, because unused fields rarely need to migrate. The step is done when you have a signed-off list of channels, SLA rules and required fields that the target system must reproduce.
Stand up the target in a test environment
Deploy Zammad or Znuny in a non-production environment inside your own infrastructure, using the installation method your team can operate. For Zammad, that is the package, Docker Compose or Helm path, with PostgreSQL 15 or newer and Redis 7 or newer as prerequisites. For Znuny, check the supported database and Perl requirements in its README before choosing the platform. Decide early whether you need Elasticsearch and Memcached, since the software requirements pages describe them as optional for search but needed for multi-instance deployments. The step is done when the test instance runs, a test agent can log in, and your backup and restore procedure has been exercised.
Export tickets, contacts and articles from HubSpot
Export the CRM records you need from HubSpot. HubSpot's record export produces CSV, XLS or XLSX files sent by email link, and the account is limited to 300 exports per rolling 24 hours, so plan the export runs in advance. Use the HubSpot CRM API for data that record exports do not cover, such as full conversation threads or specific associations, and keep the API batch limit of 100 records per request in mind. Confirm with your HubSpot administrator which knowledge base articles and portal content are exportable and where they are stored. The step is done when every export file is stored in a restricted location, checksummed, and its record count matches what HubSpot reports.
Map fields, statuses and customers
Create a mapping sheet that links each HubSpot ticket property, pipeline stage, contact and company field to a Zammad or Znuny attribute, group, state or customer field. Decide how HubSpot contacts become Zammad customers and organizations, and how duplicate contacts are merged. Record fields that have no equivalent and decide whether to drop them or store them as custom attributes. Note that Zammad's migrators cover Freshdesk, Kayako, OTRS and Zendesk, not HubSpot, so a HubSpot import will usually require the API or custom development. The step is done when a reviewer from service operations has signed off the mapping sheet against a sample of tickets.
Import through the API and validate in test
Load the mapped data into the test instance through the Zammad API or the Znuny interfaces, or with custom import scripts built by your implementation partner. Run the import in small batches first, then the full set. Check that ticket counts, timestamps, attachments, customer links and agent assignments match the source exports. Compare a random sample of at least several tickets per channel by hand. Where a HubSpot export cannot carry an element, such as attachment content or thread order, record the gap so the service team can decide whether to keep an archive. The step is done when the reconciliation report shows zero unexplained differences and the gaps are documented and accepted.
Rebuild SLAs, triggers and knowledge base
Recreate each SLA from the inventory as a Zammad or Znuny rule with its calendar, escalation and notification settings, then test each one with sample tickets at the boundary of its target. Rebuild triggers and automation that route tickets, set priorities or send replies. Move knowledge base articles and customer portal content into the target's knowledge base, check internal links and images, and set up the public or customer-facing views you need. Configure third-party login such as SAML or OpenID Connect if agents already authenticate through your identity provider. The step is done when test tickets trigger the expected SLA timers, notifications and article visibility for both agents and customers.
Cut over email and channels
Plan the switch-over with a fixed date and a rollback plan agreed in advance. Repoint inbound email addresses, web forms, chat widgets and phone integrations to the new system, and set up outbound sending from the new instance using your domain's authentication records. Run both systems in parallel for a short, agreed period so late replies to old threads are caught. Confirm survey settings for NPS and CSAT feedback in the new system, since Service Hub includes them as built-in features. The step is done when a test message from each channel creates a ticket in the new system, outbound replies arrive correctly, and the HubSpot inbound paths are disabled.
Retire HubSpot access after verification
After the cutover period, confirm that all open tickets are handled in the new system and that no channel still routes to HubSpot. Keep the exported archives under your retention policy, then review what remains in HubSpot, including subscription scope if Service Hub is part of a broader bundle. Remove integrations and API tokens that no longer have a purpose, and document the operating runbook for backups, upgrades and security releases, since Zammad and Znuny publish updates on their own schedules. The step is done when the runbook is accepted by the service owner and the HubSpot service configuration is no longer used for live tickets.
How the self-hosted helpdesk handles channels, SLAs and surveys
The first decision is which channels feed the queue. Both Zammad and Znuny are ticketing systems built for customer service, so inbound email and web intake are the starting point, but the supplied facts do not list their channel types, mailbox connector settings or web form options. Confirm in each product's current documentation how email threads map back to a ticket, how shared support mailboxes are configured, and whether the intake you use today is covered. HubSpot's omnichannel messaging and call tracking have no equivalent described in these facts, so plan telephony and chat as separate integrations if your support team relies on them. On the access side, Zammad supports third-party login through SAML and OpenID Connect, which lets agent sign-in follow your existing identity provider. Check the Zammad third-party login documentation for the exact setup.
SLA management is where the two products need the most hands-on testing. None of the supplied facts describe SLA time targets, business hour calendars, or escalation rules in Zammad or Znuny, so ask the vendor or test in a staging instance before you commit. Verify four things: whether first response and resolution targets can be set by priority, queue or group; how business hours and holidays are handled; what happens when a target is about to breach; and who is notified at each escalation step. Treat those answers as acceptance criteria, not assumptions. Breach reporting is also unconfirmed. Zammad documents Elasticsearch as optional but strongly recommended for faster search and reporting features, so if SLA reporting is a requirement, include that component in your sizing and test it with realistic ticket volumes.
The customer portal and knowledge base are not described in the supplied facts for either product, so both belong on the confirmation list. Ask whether a public knowledge base and a customer-facing portal with their own login are included in the self-hosted edition, or whether they are add-ons, and whether articles can be restricted by audience. HubSpot lists NPS and CSAT feedback surveys as native Service Hub features. No built-in equivalent is shown in these facts, so the usual pattern is an external survey tool linked from ticket close notifications, with responses stored in infrastructure you control if data residency matters. Scope any custom survey or portal work in writing and test the full path, from ticket closure to survey response to reporting, before cutover.
What drives the cost of replacing Service Hub
Replacing Service Hub with self-hosted Zammad or Znuny moves cost from a subscription to a set of components you pay for directly. Software licensing is only one of them, and the largest recurring costs usually sit in hosting, upkeep and support. Use these cards to build a quote request that compares like with like.
Software licensing
Self-hosted Zammad carries no license fee, and Zammad is licensed under AGPL-3.0. Znuny is distributed under GPL v3 and its community use is also free of license fees. The license cost is usually the smallest line item, so the decision depends on the components below. Check whether your legal team needs a review of AGPL obligations if you modify the code and offer it to users over a network.
Infrastructure and database hosting
Zammad needs PostgreSQL 15 or newer and Redis 7 or newer, and Elasticsearch is optional but strongly recommended for search, reporting and attachment content. Multi-instance deployments also need Memcached. Ask your platform team to price servers, storage, backups and monitoring in your own cloud or data center. This is a recurring cost that grows with ticket volume and attachment size.
Implementation and migration effort
Most of the one-time cost is configuring channels, SLA rules, roles and the knowledge base, then moving tickets out of HubSpot. Zammad includes migrators for Freshdesk, Kayako, OTRS and Zendesk, while HubSpot tickets usually need an export and API-based import or custom development. Ask any implementation partner for a fixed scope listing each data set, the number of channels and the test cycles included.
HubSpot integration work
Service Hub data often links to contacts, companies and deals in HubSpot CRM. If those records must stay in sync with the helpdesk, you need an integration that reads from the HubSpot CRM Contacts API, which returns batch results of up to 100 records per request, and maps them to Zammad objects. Quote this as a separate item, and confirm whether tickets, notes and survey results must flow back to HubSpot.
Vendor support subscriptions
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. These are optional and recur annually. Znuny offers professional services from Znuny GmbH, so request a separate quote for support hours and response terms. Ask which tier covers upgrades, security patches and hosting questions.
Staff time for upkeep
Self-hosting shifts updates, backups, monitoring and availability to your team, which Zammad's pricing page confirms for self-hosted customers. Security fixes were published for both the 6.5 and 7.x lines in parallel, so plan for patch windows on the version you run. Include the on-call and testing time in your internal cost model, and ask a partner to quote recurring upkeep or a retainer as a separate line.
Questions buyers ask before replacing HubSpot Service Hub
Can Zammad or Znuny replace HubSpot Service Hub on its own?
Both can cover the core help desk work: ticket intake, agent queues, and service level rules. Service Hub also lists omnichannel communication, call tracking, service analytics, a knowledge base, a customer portal, and NPS and CSAT surveys as features. Confirm with each vendor which of those features ship in the edition you choose, and which need add-ons, custom development, or a separate tool such as a survey product. Service Hub is also sold alongside Marketing Hub and Sales Hub, so check which CRM records your service team reads today, because a standalone help desk does not carry those objects across automatically.
How much work does a Service Hub migration take, and what drives it?
The effort depends mostly on the ticket history, attachments, and integrations you need to keep, not on the help desk software itself. Zammad includes migrators for Freshdesk, Kayako, OTRS, and Zendesk, and other systems can be imported through the Zammad API or custom development. Service Hub exports are a separate step, so check what your export covers before you plan the import. The main cost drivers are the number of ticket records, the number of agents and their roles, how many channels you reconnect (email, chat, phone), the SLA and workflow rules you rebuild, and the knowledge base articles you move. Ask any implementation partner for a written scope that lists each of these items.
Can an internal team run a self-hosted Zammad or Znuny installation?
A small platform team can run either system, but the work is ongoing, not a one-time install. For Zammad, the requirements include PostgreSQL 15 or newer and Redis 7 or newer for realtime websocket communication, plus a reverse proxy such as Nginx or Apache. Elasticsearch is optional but strongly recommended for search, reporting, and attachment content search. Multi-instance deployments such as containers or cluster nodes need Memcached. Znuny runs on Linux with Perl 5.16.0 or higher and supports MySQL, MariaDB, PostgreSQL, and Oracle. Your team owns upgrades, backups, patching, and availability unless you contract that work out. Confirm your staffing and on-call coverage before you commit to a design.
How are SLAs and customer surveys rebuilt after moving off Service Hub?
SLA management and surveys are rebuilt as configuration and integration work, so plan them as separate deliverables. Export your current response and resolution targets, business hours, escalation paths, and priority rules, then recreate them in the help desk and test each rule against historical tickets. Service Hub includes NPS and CSAT feedback surveys. Zammad and Znuny each have their own way of handling ticket-level notifications and reporting, so confirm whether satisfaction surveys are native in the version you select or whether they need an external survey tool that writes results back to the ticket. Compare the reporting output with your current service analytics before you retire the old dashboards.
What security and single sign-on setup does a self-hosted help desk need?
Treat the help desk as a system that holds customer personal data, so the security work covers hosting, access, and logging. Zammad supports third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub, and GitLab, among other providers, so you can connect it to your existing identity provider. Confirm the same for Znuny with its current documentation. Plan for TLS termination at the reverse proxy, encrypted database and backup storage, role-based agent permissions, audit logs, and a documented patch process. Both projects publish security releases, and the Zammad releases page shows fixes for more than one release line at a time, so assign someone to track advisories for the version you run.
Are paid support subscriptions required to run Zammad or Znuny?
No. Self-hosted Zammad has no license fee, and its AGPL-3.0 license permits self-hosting. 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 its pricing page. Its pricing page also states that self-hosted customers handle updates, backups, and availability, so a subscription adds vendor support but does not transfer operations. Znuny is maintained by an open-source project, and Znuny GmbH offers professional services in Berlin. Ask each option what is covered, what response expectations apply, and whether Kubernetes issues are included, since Zammad support covers only the application on Kubernetes.
How should we test the new help desk before cutover?
Run a parallel period with a copy of real ticket flows before you switch email and channel routing. Use a staging instance seeded with a migrated sample of tickets, then test inbound email, outbound replies, attachments, SLA timers, escalations, merges, and survey triggers. Check login through your identity provider, role permissions for each agent group, and the reporting figures against Service Hub for the same period. Keep Service Hub read-only for a defined period so you can reconcile any gaps. Write acceptance criteria and a rollback plan before testing begins, and agree on them with the service owner. A fixed-scope engagement from DeployOpen can include this test plan as part of the written deliverables.
Official sources to check the platform details
Before you size a migration, check the current service details against the vendor's own pages, because help desk feature sets, release lines and requirements change between versions. Start with HubSpot's Service Hub product page, which lists the features this page maps to open source: the help desk workspace, SLA management, the knowledge base, the customer portal and the NPS and CSAT surveys. Confirm which of these your current edition includes, since HubSpot sells Service Hub in Free, Starter, Professional and Enterprise tiers, and the tier you hold determines what you must replace. Export a written list of the features your agents actually use, so you compare against real workflows rather than the marketing summary.
For Zammad, the release notes and the requirements page are the two documents to read before choosing a version. The Zammad releases page shows that security fixes can be published on more than one release line at the same time, so decide which line you will run and who applies patches on it. The Zammad software requirements page sets the database, Redis and cache needs for your deployment size, and it is the document your platform team should review against your hosting standards. Confirm the Elasticsearch and Memcached guidance with your own architect, since both depend on how many instances you run.
For Znuny, use the Znuny documentation portal and the Znuny releases page together. The portal keeps separate documentation for the current feature version and the LTS version, so pick the line that matches your support policy and read the matching agent and administrator guides. Confirm the supported database versions and the Perl and web server prerequisites against the README in the Znuny repository before you order infrastructure. Keep a dated copy of the documents you relied on, since your change record and any compliance evidence will need it.
How DeployOpen scopes and delivers a service desk replacement
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source help desk platforms inside your own infrastructure, including the Zammad or Znuny options covered on this page. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory HubSpot Service Hub use: help desk queues, channels, SLA rules, surveys and portal pages in use
- Decide between Zammad and Znuny against your channels, integrations, hosting and database standards
- Agree in writing which tickets, attachments, knowledge base articles and survey data migrate
How we build
- Deploy the chosen platform in your cloud account, data center or air-gapped network with PostgreSQL and Redis
- Configure channels, SLA rules, roles, third-party login and the customer portal to match the agreed scope
- Test ticket routing, escalation and migrated records against an agreed acceptance checklist before cutover
How we hand over
- Document architecture, configuration, backup and restore steps, and admin procedures for your own staff
- Deliver runbooks covering upgrades, security releases and the reverse proxy and cache setup
- Train agents and administrators on daily operation and record the handover evidence in the agreed format
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer agreed separately from the build
- Plan security release adoption and upgrade windows with your change management process
- Confirm with the vendor which support plan covers your self-hosted environment before signing
