Which open-source option replaces the Intercom Help Center
If you are weighing a renewal or data residency concern on Intercom's help center, the choice comes down to how your support is run today. Chatwoot's Help Center portal fits teams that run live chat and the inbox on the same stack, because the portal sits next to the website widget, the omnichannel inbox and the reports you already use. Its listed scope covers articles, FAQs and guides, which is the core of what most teams publish. Zammad's knowledge base fits email and ticket-led support, where answers are written once and reused by agents and customers across several languages chosen at setup.
Neither product is a one-to-one copy of Intercom's article editor, collections or in-widget search, so plan for a gap review before you commit. Confirm in a test instance how each one handles article layout, grouping, search inside the chat widget and the redirects you need so old Intercom links keep working. Zammad's knowledge base is the one that supports staff-only (internal) answers and per-category permissions, which matters if your runbooks or pricing exceptions must stay away from customers. Chatwoot's public portal covers public content well, so check whether you need internal-only material before choosing it.
Plan the decision as a checklist: list your published articles, the languages they need, which answers must stay internal, and whether your help content is searched from the chat widget or from a standalone page. Ask any implementation partner or vendor to demonstrate those exact cases on your content. Hosting, the database and search components are one-time setup costs plus recurring infrastructure and support, and they differ by product, so confirm them against the requirements for your chosen option rather than relying on this summary.
How Intercom Help Center capabilities map to Chatwoot and Zammad
This table maps the Help Center capabilities most teams rely on against Chatwoot and Zammad, marking where each option is supported, partial or unconfirmed. Read the rows as a checklist to test in your own instance, since editor behavior and search relevance depend on your content and configuration. The main takeaway is that Zammad's knowledge base is the more documented option for internal and public answers in several languages, while Chatwoot's Help Center portal is the stronger fit for a public guides site beside a live chat inbox.
| Capability | Chatwoot Help Center portal | Zammad knowledge base |
|---|---|---|
| Articles and drafts | Help Center portal publishes articles, FAQs and guides; confirm draft workflow and review steps in your test instance | Supports draft, staff-only and public answers with publishing controls |
| Public and internal answers | Public portal content is documented; confirm whether internal-only answers are kept separate from the public site | Staff-only (internal) answers are a built-in type alongside public answers |
| Collections or categories | Confirm how sections and categories are organized and whether they can carry separate permissions | Categories with per-category permissions, so access can differ by group |
| Multilingual publishing | Confirm language support for articles and locale switching in the portal before committing | Publishes in several languages, chosen at setup of the knowledge base |
| In-widget or in-product search | Confirm whether the live chat widget searches Help Center articles; behavior varies by version | Confirm search across answers and any in-product entry point in your own environment |
| Custom domain | Confirm custom domain setup for the portal on your self-hosted instance | Custom knowledge base domain is available only on self-hosted instances |
| Linking to conversations | Confirm whether articles can be attached or referenced from conversations in the inbox | Wiki-style links between answers and tickets are supported |
| Migrating Intercom articles | Export or rebuild articles manually or through the API; no built-in article importer is documented here | No Intercom migrator is listed; articles need export or API-based import work |
When Chatwoot or Zammad fits your help center
Both platforms can host public articles and internal answers on infrastructure you control, but they differ in how the knowledge base is built and in which features sit behind paid tiers. The cards below set out what each one covers, where the trade-offs fall, and what to verify before you move Intercom articles across.
Chatwoot Help Center portal
Chatwoot's Help Center portal publishes articles, FAQs and guides alongside the same omnichannel inbox your agents already use, so support content and conversations sit in one self-hosted system. The core is MIT-licensed, but the Community Edition is the only tier at $0, and Premium and Enterprise add features such as custom branding, roles and permissions, and SAML single sign-on. Check whether the portal and search cover your required languages and whether your team needs a paid tier. Confirm with the vendor which Help Center features sit in each tier before you build a migration plan.
Chatwoot runtime requirements
Running Chatwoot yourself means operating Ruby on Rails, Node.js, PostgreSQL as the only supported database, and Redis 7.0 or higher. Ubuntu 20.04 is the only officially supported Linux distribution, so the host image and patching plan need to match that list. Sizing guidance starts at 4 CPU cores and 4 GB of RAM for up to 10,000 conversations a day, and the platform team should plan for swap and for Sidekiq memory on busy servers. Ask your platform team to confirm that these components fit your existing operations standards.
Zammad knowledge base states
Zammad's knowledge base supports draft answers, staff-only internal answers and public answers, so you can keep troubleshooting steps for agents separate from articles your customers see. Categories carry their own permissions, and wiki-style links connect answers with tickets. Languages are chosen at setup, which means multilingual help content needs its language list planned before you import anything. Decide early which answers are internal, and confirm that the category permission model matches who edits what.
Zammad licensing and search
Zammad is licensed under the GNU Affero General Public License version 3, which carries source obligations for anyone who modifies it and offers it over a network, so involve your legal team if you plan custom changes. Elasticsearch is optional but strongly recommended for faster search and for searching attachment content, which adds a separate cluster to run. A custom knowledge base domain is available only on self-hosted instances, so public help content on your own domain requires that hosting model. Confirm the search cluster sizing and the AGPL position before go-live.
Running the help center next to Intercom during cutover
This pattern leaves the Intercom Messenger and inbox running while the help center articles move to a new portal. It suits teams that need time to validate the new help center before they change the live chat widget. The cost is that two systems stay live, so agents work in Intercom while readers search a second site, and the article links shown in Intercom must keep resolving during the overlap.
- Freeze article URLs early: Decide the new public paths before publishing, so that redirects are written once and not revised during the overlap.
- Repoint messenger links in stages: Intercom-sent links to articles keep working through a redirect, while new replies cite the new URLs once they resolve.
- Keep search on both sides: Readers using the old in-widget search still reach articles, so confirm which index answers queries during the overlap.
- Set a retirement date for Intercom articles: Define when the old collections are unpublished so that stale copies do not compete in search.
Before you start, confirm with your team how long the two help centers will both be live and which system owns each redirect.
This pattern moves the live chat widget, the inbox and the help center in one cutover window. It removes the dual-running period for agents and gives a single place for article links, widget search and conversation history. The trade-off is a larger change at once, so the rollback plan has to cover the widget, the inbox routing and the articles together.
- Rebuild the widget and article links together: The new widget and its help center links go live as one change, so no visitor sees a broken article link.
- Migrate articles and collections in one pass: Move collections, article drafts and publish states together so that categories and audience settings match.
- Test in-widget search against migrated content: Run representative queries before cutover and compare results with the Intercom baseline.
- Plan the rollback path: Keep the Intercom widget snippet and the old article URLs ready so that the previous state can be restored quickly.
Confirm with your vendor or implementation partner exactly which settings a rollback restores, since widget and portal configuration may not revert with the same switch.
This pattern moves the help center to a separate public site and keeps Intercom as the messenger and inbox. Chat still runs in Intercom, so the messenger's links to help articles and its search must be repointed to the new public site. The key decision is whether the new site lives on its own domain or under your main website path, because that choice determines how redirects and cookies behave.
- Map every Intercom article link: Export the list of published article URLs and map each one to its new address before the switch.
- Repoint messenger help links: Change the help center base URL used in the Intercom messenger settings so that article suggestions open the new site.
- Decide on search responsibility: Intercom's in-messenger search may index only Intercom articles, so confirm whether it can query the new site or whether readers need a separate search entry point.
- Use permanent redirects: Serve permanent redirects from old article paths to new ones so that external links and search engine results continue to resolve.
Confirm with Intercom which messenger settings accept an external help center base URL on your plan, and with the new platform which portal domain it can serve.
Many products link to help articles or embed help content inside the application, not only on a public website. Those embeds, deep links and in-app help triggers are easy to miss in a cutover plan because they sit in product code and not in the help center. Each one needs an inventory entry so the team knows where the Intercom URLs appear and who updates them.
- Inventory in-app help links: Search product code, email templates and documentation for Intercom help center domains and article paths.
- Check embedded content: If the product displays articles inside its own pages, confirm how the new portal serves content to an embedded frame and whether it sets cookies that the host site must allow.
- Update email and notification templates: Transactional emails often carry article links that do not pass through the messenger, so they need their own repointing.
- Confirm cross-domain behavior: Check how the new help center handles sign-in, custom domains and content security policies when it loads inside your product.
Before cutover, confirm these points with the platform team and in a staging copy of your product, since embed behavior depends on your own domain and security settings.
Moving Intercom articles, collections and redirects
This sequence moves published help center content out of Intercom into a staging instance of Chatwoot or Zammad, with collections mapped to categories, visibility and languages checked, and old article links redirected before the live cutover. The result is a help center that answers the same questions at the same addresses on infrastructure you control.
Inventory articles, collections and languages
The support lead lists every published and draft article, its Intercom collection, its translations and its current public URL, and records which articles are internal only. Ask Intercom which export route returns the full article body before relying on any file: CSV and S3 exports do not carry full article content, so confirm what each route returns against a sample article. The inventory is done when every article has a row with a collection, a language and a visibility status, and the team has signed off on what is in scope.
Pull full article content through the API
An engineer with access to the Intercom API retrieves article bodies, titles, collection membership, translations and timestamps, and stores the raw responses in a restricted location inside your environment. Because the API response is the route that carries the complete article body, this step replaces any reliance on CSV or S3 exports for content. Confirm rate limits and token scopes with Intercom before starting, and check that a sample of retrieved articles matches what appears in the Intercom editor. The step is complete when the stored set matches the inventory count and the sample check passes.
Map collections to categories and languages
The content owner maps each Intercom collection to a Chatwoot help center category or to a Zammad knowledge base category, and maps each language to the language set chosen for the target instance. In Zammad, languages are selected at setup, so confirm the language list before creating content, and set per-category permissions so that internal answers are limited to staff. Chatwoot organizes its Help Center portal by its own categories and locales, so confirm the locale configuration in the target before import. The mapping is complete when every collection and language has a documented destination and an owner.
Import into a staging instance
The engineer loads the transformed articles into a staging instance of the chosen platform, using the platform's API or a scripted import written for your export format. Zammad's built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk, not Intercom, so an Intercom import is custom work either through the Zammad API or through development by your team or DeployOpen. Keep a log of each article's source ID and destination ID so that failures can be re-run without duplicates. The step is complete when the staging counts match the inventory and the log records every article.
Check internal and public visibility
The support lead reviews each imported article in staging and confirms its state: draft, staff-only (internal) or public. In Zammad, check that internal answers are not exposed through the public knowledge base and that category permissions match the mapping from the previous step. In Chatwoot, confirm which Help Center portal pages are published and which content is kept for agents only. Test visibility by viewing the public site while signed out. The check is complete when a signed-out tester cannot reach any internal article and every public article renders in the expected language.
Rebuild search, widget and internal links
The engineer updates the chat widget and any in-product links so they point to the new help center categories and article addresses, and rebuilds internal cross-references between articles. Zammad supports wiki-style links between answers and tickets, so re-link articles that were referenced from ticket templates or macros. Check whether the search configured for the new help center covers the imported content, and confirm whether any search index needs a rebuild after import. The step is done when a test search for a set of known questions returns the expected articles in staging.
Set redirects from old article URLs
The web team creates a redirect map that sends each old Intercom article URL to its new address, using the inventory as the source list. Confirm with your web server, CDN or DNS provider how redirects are configured for your domain, and test a sample of old links in staging before going live. Keep the map under version control so later changes are traceable. The step is complete when every old public URL in the inventory returns a redirect to a live page and no redirect loops.
Cut over DNS and test in-product links
The platform owner switches the help center hostname to the production instance, with a rollback plan documented before the change. After cutover, the support team clicks through the widget, the help center links inside product emails and the links in saved replies, and confirms each one resolves to the correct article. Keep Intercom read-only for a defined period agreed by the team so that late links can be traced. The sequence is finished when the live hostname serves the new help center, the redirect map passes its test and the in-product link checklist is signed off.
Questions buyers ask before moving the Intercom Help Center
What drives the cost of moving Intercom Help Center articles to self-hosted software?
Effort follows the content and the design work, not the software license, because both Chatwoot and Zammad are free to self-host. The main drivers are the number of articles and collections, how many languages each article needs, how much custom design the help center must keep, how many old URLs need redirects, and which integrations must be rebuilt. Costs fall into three groups: the infrastructure you run, the internal or partner time to move and check content, and any paid support tier. Ask any quote to itemize each driver separately so you can see which ones your content inventory actually raises. Chatwoot's self-hosted plans page lists per-agent support tiers, and Zammad's pricing page lists self-hosted support subscriptions, so confirm which support level you need before comparing totals.
How long does it take to move an Intercom help center?
The duration depends mostly on how much of the content must be reviewed before it goes live, not on the platform installation. Installing and configuring the software is usually the shorter part, while checking article accuracy, approving translations, and deciding which outdated articles to retire depend on your content owners' availability. Build the schedule around a content review gate, with named reviewers and a deadline for each collection. Ask any proposal to state its timeline in writing, with the assumptions about article count and review rounds listed, so you can see what changes the date.
Can our internal staff move the help center without a partner?
Yes, a capable internal team can do it, provided it has someone who owns the server, someone who owns the content, and time set aside for both. The tasks that usually need engineering skill are installing the application stack, configuring PostgreSQL and Redis, setting up backups, DNS and TLS, and rebuilding the site-facing widget. Chatwoot's deployment requirements list Ruby 3.2 or later, Node.js 20.x, PostgreSQL only, and Redis 7.0 or higher, so confirm your team can operate that stack. DeployOpen plans, implements, hardens and documents self-hosted platforms in your infrastructure under a written, fixed scope, which is one option if your staff lacks capacity. Compare an internal plan and a partner scope against the same checklist.
Which Chatwoot help center features need a paid self-hosted plan?
The Help Center portal for articles, FAQs and guides is listed in Chatwoot's README as a core feature, so it is part of the free Community Edition. Paid tiers add features around it. Chatwoot's self-hosted plans page places Captain AI, custom branding, roles and permissions, and priority support in Premium Support at $19 per agent per month, and places SSO with SAML and SLA policies in the Enterprise Edition at $99 per agent per month. Confirm on the plans page whether a specific help center setting you need, such as custom branding of the portal, sits in Premium before you design the site. Chatwoot's code is MIT licensed apart from the enterprise/ directory, so review the license file if your legal team asks.
What does the Zammad migrator cover for a non-Zendesk source?
Zammad's built-in migrator covers Freshdesk, Kayako, OTRS and Zendesk, so a source outside that list needs a different route. Zammad's documentation says other systems can be imported through the Zammad API or through custom development from Zammad. The built-in migrations are all or nothing, work only on a new instance, and accept one source system per migration, so plan for a clean target rather than a merge. Zammad's knowledge base itself supports draft, internal and public answers in several languages, which you must map from your current structure by hand or with a script. Confirm with Zammad whether your source appears on the supported list before you commit to a route.
What must our team provide before the migration starts?
Four inputs decide whether the work can start on schedule: administrative access to the current Intercom workspace and to the target hosting account, named content owners for each collection, DNS control for the help center domain, and a written sign-off process. Admin access lets the export or API pull happen, and content owners approve accuracy and translations. DNS changes control cutover and redirects. The sign-off process should define who approves each collection, what counts as ready, and who approves the final switch. Ask any proposal to list these inputs with owners and dates, so gaps show up before work starts.
How do we keep the self-hosted help center secure and maintained?
Treat the server as production software that needs patching, backup and monitoring from day one. Chatwoot publishes release history on GitHub, with v4.18.0 dated September 18, 2026, and Zammad publishes security releases on both its 6.5 and 7.x lines, so assign someone to watch those release channels. Zammad documents package, Docker Compose and Kubernetes installations, and its support on Kubernetes covers only the Zammad application. Document the backup and restore procedure and test it. Confirm with your security team which controls they expect for the hosting environment, and ask any partner how upgrades and retainers are scoped.
What changes for editors, support agents and readers
Editors are the group that feels the largest change. Intercom's article editor, its collections and its translation handling will not carry over as they are, so the editing team needs to learn whichever tool is chosen before the first article is moved. With Chatwoot, the Help Center portal covers articles, FAQs and guides, and the team should check how it organizes them and how it handles drafts and review. With Zammad, the knowledge base adds draft, staff-only and public answers in the languages chosen at setup, plus per-category permissions that decide who can see or change each answer. Editors should write a few test articles in each format, including one translated answer, and confirm in a trial instance that the editor features, the translation workflow and the analytics they rely on today are all available. Ask the vendor or the implementation partner to document any gap in writing before the migration plan is signed off.
Support agents gain something they may not have had in Intercom. In Zammad, knowledge base answers can be linked to tickets, so an agent working a request can open the relevant internal answer and point the customer to the public version of the same answer from one place. In Chatwoot, the same linking idea applies to conversations, so agents can reuse articles and canned responses while keeping the conversation in the shared inbox. The practical check is whether agents can find and insert answers without leaving the conversation or ticket, and whether internal-only content stays hidden from customers. Run a short test with a few agents on realistic but illustrative cases, and record where they still need to switch screens.
Readers, meaning customers who visit the help site, will see a different search and URL structure. Article addresses change, so the team should plan redirects from old Intercom links so that links in emails, social posts and product screens keep working. In-widget search in the chat widget also needs to be rebuilt against the new knowledge base, and its results depend on how articles are titled, tagged and grouped. Before cutover, ask the implementation partner to confirm the URL pattern for each language, how the search indexes article content, and how search analytics will show which queries return no answer. Zammad documents a custom knowledge base domain for self-hosted instances, which may help keep the public address under the organization's own brand, but the setup should be confirmed on the chosen version.
How DeployOpen scopes and delivers a help center migration
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up and documents self-hosted platforms inside your own infrastructure. The cards below describe how a help center move is scoped in writing, what gets built and checked, and how support continues after cutover.
Company scope and boundaries
DeployOpen plans, implements, customizes, integrates, hardens, backs up and documents self-hosted platforms in your cloud accounts, data centers or air-gapped networks. For a help center move, the work covers the Chatwoot or Zammad installation, the portal domain, the article structure and the search setup. Ask in writing which of these components are in scope and which remain with your own team.
Fixed-scope agreement first
Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. For an article migration, the written scope should list the article count, languages, collections to rebuild and the public or internal visibility rules for each group. A change in content volume or languages is a scope change and should be priced as one.
Content mapping and cutover checks
Map each Intercom collection to a Chatwoot category or a Zammad category before moving anything, and decide which articles stay draft, staff-only or public. Check that internal answers are never exposed through the public portal, and confirm that links between articles and conversations still resolve after import. Test in-widget search against the moved content before switching the public URL.
Hardening and backups
Self-hosted help centers need a hardened host, controlled database access, TLS on the custom domain and tested restores for the PostgreSQL and Redis data behind the portal. DeployOpen configures these inside your environment and documents the backup schedule and restore steps. Ask the vendor which components of the platform hold article content, so backups cover every store that matters.
Retainers for upgrades and support
After go-live, optional retainers cover platform upgrades, security patches, ongoing support and continuous testing of the portal. Open-source platforms publish releases on their own schedule, so a retainer keeps the upgrade path planned rather than reactive. Agree in writing who handles vendor support tickets and who approves each upgrade window.
Quote from the written scope
DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that drive it are the article volume, languages, integrations, hosting model and documentation depth. Ask for the quote to separate one-time migration work from recurring retainer work, and to state which costs stay with your team, such as hosting and internal review time.
