Confluence vs Zendesk Help Center: Architecture, TCO & Migration

Confluence vs Zendesk Help Center: Architecture, TCO & Migration

Confluence is an internal wiki built for team collaboration inside the Atlassian ecosystem. Zendesk Help Center (Guide) is a customer-facing knowledge base bundled with Zendesk's ticketing suite. They solve fundamentally different problems, but teams compare them constantly because both appear in "knowledge base software" searches. This guide breaks down the architectural differences, real cost of ownership, and exactly what it takes to migrate content between the two.

What is Confluence?

Confluence is Atlassian's enterprise wiki platform for internal documentation, project pages, and knowledge management. It organizes content into spaces (top-level containers) and pages (nested in a tree hierarchy within each space). Content is stored in a proprietary XHTML-based storage format that includes custom XML elements (<ac:> and <ri:> namespaces) for macros, layouts, and structured data — not standard HTML, and not fully compliant with the XHTML specification despite the name Atlassian uses.

Confluence Cloud has two active API versions: the legacy v1 REST API (/wiki/rest/api/content) and the newer v2 REST API (/wiki/api/v2/pages), which Atlassian has been pushing for Cloud since 2023. The v2 API returns body content in a different structure and supports additional expansion parameters; migration tooling written against v1 will not work against v2 without changes. Data Center deployments primarily use v1.

Confluence Cloud supports up to 150,000+ users on its Enterprise plan. Atlassian ended Server sales and support in February 2024, making Data Center the only remaining self-hosted option. Confluence integrates with Jira, Bitbucket, and the broader Atlassian stack. Its Rovo AI product focuses on internal knowledge discovery across connected Atlassian apps.

Note on the Fabric editor: Confluence Cloud is progressively migrating from the legacy editor (which uses the XHTML storage format described above) to the Fabric editor, which uses a different underlying content model. As of 2025, most Cloud spaces still export in the legacy storage format, but this will change. If you are building a migration pipeline today, validate which editor your source space uses before assuming storage format behavior — the export structure differs.

What is Zendesk Help Center?

Zendesk Help Center (also called Zendesk Guide) is the knowledge base component of Zendesk's customer service platform. It is purpose-built for external, customer-facing help centers with custom domains, white-label branding, embeddable widgets, and approval workflows. Its core job is ticket deflection — surfacing relevant articles before customers submit support requests.

The critical constraint: Zendesk Help Center cannot be purchased standalone. It comes bundled with Zendesk Suite, which starts at $55 per agent per month (billed annually as of 2026). The $19/agent/month Support Team plan exists but does not include the Help Center feature — so for knowledge base purposes, $55/agent/month is the real floor.

Zendesk's content hierarchy follows a strict three-layer model: Categories → Sections → Articles. Articles are stored as standard HTML with inline images hosted on Zendesk's CDN.

Note on API naming: Zendesk has been consolidating its Guide-specific endpoints into the broader Help Center API. The older "Knowledge Base API" label still appears in some Zendesk documentation but refers to the same /api/v2/help_center/ endpoints. There is no separate Knowledge Base API for Guide content.

How does the content architecture differ?

This is the most important technical distinction, and it drives most of the complexity in any migration.

Confluence uses a tree-based hierarchy: Spaces contain pages, and pages can nest infinitely deep with child pages. Content bodies use Confluence's XHTML-based storage format with custom XML namespaces.

Zendesk Help Center uses a flat three-layer hierarchy: Categories hold Sections, and Sections hold Articles. There is no nesting beyond three levels. Article bodies are standard HTML.

The hierarchy gap is the primary structural problem in any Confluence → Zendesk migration. A Confluence space with five levels of nested pages has no direct analog in Zendesk's flat Category → Section → Article model. The decision of how to flatten that tree — typically mapping top-level parent pages to Sections and leaf pages to Articles — requires editorial judgment, not just scripting.

Localization is a secondary structural problem that most migration guides skip entirely. Confluence spaces have a single language setting; Zendesk Help Center supports per-article locale variants, a designated source locale, and a translation workflow. If your Confluence content includes pages in multiple languages (common in global teams), you need a mapping strategy for which Zendesk locale each page maps to before you write a single API call. Getting this wrong means articles published under the wrong locale, which breaks Zendesk's translation management UI and search indexing.

How does pricing compare? What is the real TCO?

The sticker prices are misleading for both platforms. Here's what you actually pay.

Confluence pricing (2026)

Confluence Cloud offers four tiers (Atlassian pricing page):

• Free: Up to 10 users, unlimited pages, 2 GB storage
• Standard: ~$5.16–$6.40/user/month (per-user cost decreases with headcount); includes 250 GB storage, basic admin controls, and audit logs
• Premium: ~$12.30/user/month for 100 users; includes analytics, admin insights, and Atlassian Intelligence features
• Enterprise: Custom pricing; includes multi-site, SIEM integration, and advanced security controls

Confluence Data Center (self-hosted) starts at approximately $28,000/year for a 500-user license. Data Center is the only self-hosted option following end-of-life for the Server edition in February 2024.

The hidden cost: Confluence's Marketplace contains hundreds of paid add-ons that fill gaps in the base product — diagramming tools (Gliffy, draw.io), reporting (Table Filter and Charts), and automation tools. Teams that invest in these can pay $2,000–$8,000/year in Marketplace apps on top of base licensing, depending on user count. This cost is almost always underestimated in initial budgets.

Zendesk pricing (2026)

Zendesk Suite plans (Zendesk pricing page):

• Suite Team: $55/agent/month (annual billing) — includes Help Center, basic AI agents, live chat
• Suite Professional: $115/agent/month — includes multilingual content, community forums, custom reports
• Suite Enterprise: Quote-only — includes sandbox environment, custom agent roles, advanced AI

The 2026 AI billing shift: Zendesk now meters AI Agent interactions per automated resolution rather than purely per seat. Each plan includes a small monthly allowance (approximately 5 automated resolutions per agent on Team, 10 on Professional). Overages have been charged automatically with no grace period since January 2026. Independent estimates from Zendesk partners put the overage rate at approximately $1.50–$2.00 per resolution — Zendesk has not published an official per-resolution rate in its public pricing pages. Copilot (AI assist for human agents) is an additional $50/agent/month add-on. Quality Assurance and Workforce Management modules are additional line items.

TCO example: 25-person support team

This comparison is not apples-to-apples: Zendesk Suite includes ticketing, live chat, omnichannel routing, and reporting that Confluence does not provide. If you need those capabilities, the Zendesk price covers a full platform, not just a knowledge base. If your only requirement is internal documentation, Confluence is cheaper by roughly an order of magnitude.

When should you use Confluence vs Zendesk Help Center?

Choose Confluence when:

• Your audience is internal (engineering, product, operations, HR)
• You need deep page nesting and flexible, evolving content hierarchy
• You're already using Jira, Bitbucket, or other Atlassian tools
• You need real-time collaborative editing across large teams
• Budget is a primary constraint and you don't need customer-facing features

Choose Zendesk Help Center when:

• Your audience is external customers seeking self-service support
• Ticket deflection and CSAT impact are the primary success metrics
• You need multi-brand help centers managed from a single admin console
• You want content approval workflows, user segments, and scheduled publishing for public articles
• You need a knowledge base tightly integrated with ticketing, live chat, and AI-assisted support

Don't force one platform into the other's role. Confluence lacks custom domain support for external delivery, white-label branding, and the per-article approval workflows that customer-facing documentation requires. Zendesk Help Center's rigid three-level hierarchy and per-agent pricing make it a poor fit for internal collaboration across a 200-person engineering organization.

How do you migrate from Confluence to Zendesk Help Center?

There is no native one-click migration path between these platforms. Every approach requires extraction from one API, transformation of the content format, and loading via the other API.

Step 1: Extract content from Confluence

Determine your API version first. If migrating from Confluence Cloud, check whether your spaces use the legacy editor or Fabric. For legacy editor content, use the v1 API with the body.storage expansion. For Fabric editor content, use the v2 API — the body is returned differently and cannot be processed the same way.

Confluence v1 API (legacy editor, Data Center):

# List all pages in a space with body content and hierarchy
GET /wiki/rest/api/content?spaceKey=DOCS&type=page&limit=25&expand=body.storage,ancestors,children.page
 
# Get a single page with storage format body
GET /wiki/rest/api/content/{id}?expand=body.storage,version,ancestors

Confluence v2 API (Cloud, recommended for new tooling):

# List pages in a space
GET /wiki/api/v2/pages?spaceKey=DOCS&limit=25&body-format=storage
 
# Get a single page body
GET /wiki/api/v2/pages/{id}?body-format=storage

Rate limiting: Confluence Cloud uses a points-based model — each API call consumes points proportional to operation complexity. Burst limits are enforced over short windows (seconds); quota limits are evaluated hourly. For Data Center, rate limiting is admin-configurable; Atlassian recommends allowing at least 20 requests per second as a baseline. Build exponential backoff with jitter into any extraction script.

Step 2: Transform the content

This is where most migrations fail. The transformation layer requires:

1. Convert Confluence XHTML storage format to standard HTML. Strip all <ac:> and <ri:> custom elements. Each macro type requires specific handling:

Macros that silently drop content are the most dangerous. A table-of-contents macro renders nothing visible in the exported HTML — you need to detect it explicitly and decide whether to generate a replacement or flag the article for manual review.

2. Flatten the hierarchy. Map Confluence's nested page tree into Zendesk's Category → Section → Article model. A common mapping for a typical Confluence documentation space:

• Confluence Space → Zendesk Category
• Confluence top-level pages (depth 1) → Zendesk Sections
• Confluence child pages (depth 2+) → Zendesk Articles

Pages at depth 3 or deeper have no natural Zendesk home. Options: consolidate them into their parent article, create a naming convention that signals depth (e.g., "Advanced: Topic Name"), or reorganize the content hierarchy editorially before migrating. This decision cannot be automated away.

3. Re-host images. Confluence images are stored as page attachments and served from Confluence's own storage. The migration process for each image:

1. Download the attachment via Confluence API (GET /wiki/rest/api/content/{pageId}/child/attachment/{attachmentId}/download)
2. Upload to Zendesk as an unassociated attachment: POST /api/v2/help_center/articles/attachments with inline: true
3. Capture the content_url from the Zendesk response
4. Rewrite the <img src> in the article HTML to the new content_url

Any migration that skips image re-hosting produces articles with broken images the moment the source Confluence instance is deactivated or CDN URLs are rotated.

4. Handle localization. If your Confluence space has pages in multiple languages, map each page to its Zendesk locale before upload. In Zendesk, the first-created version of an article sets its source locale; translation variants are added as separate localized versions. Creating an English article and then uploading a French article as a "new" article instead of a translation is a common mistake that breaks Zendesk's multilingual workflow.

5. Map metadata. Confluence labels → Zendesk article labels. Confluence page authors → Zendesk agent user IDs. Authors must exist in Zendesk as agents before articles can be assigned to them.

Step 3: Load into Zendesk Help Center

Zendesk's Help Center API enforces a strict creation order: Users → Categories → User Segments (optional) → Sections → Articles → Attachments → Comments. Each step depends on IDs from the previous step. Getting this sequence wrong causes bulk import failures that are tedious to diagnose.

Rate limits: Zendesk publishes rate limits per plan tier for the Support API (Zendesk Rate Limits documentation). The Help Center API shares the same per-account rate limit bucket. Confirmed limits as of 2025: Suite Team accounts are subject to the standard rate limits (up to 700 requests/minute across most endpoints for accounts on Growth plans and above; lower-tier accounts may be subject to stricter limits depending on endpoint). If you are migrating 2,000+ articles with attachments, plan for several hours of upload time with proper retry logic.

# Create a category
POST /api/v2/help_center/categories
{"category": {"name": "Product Docs", "locale": "en-us"}}
 
# Create a section in that category
POST /api/v2/help_center/categories/{category_id}/sections
{"section": {"name": "Getting Started", "locale": "en-us"}}
 
# Create an article (defaults to draft — must explicitly publish)
POST /api/v2/help_center/sections/{section_id}/articles
{
  "article": {
    "title": "Quick Start Guide",
    "body": "<p>HTML content here</p>",
    "author_id": 9873843,
    "locale": "en-us",
    "draft": false
  }
}

Draft state warning: Articles created via API default to draft: true. If you do not explicitly set "draft": false at creation time (or run a publish pass afterward), your entire migrated knowledge base will be invisible to end users.

Step 4: Validate

Automated validation checks to run against every migrated article:

• Image render check: Scrape the published article HTML and confirm all <img src> URLs return HTTP 200
• Internal link integrity: Confluence cross-page links use page IDs in the format /wiki/spaces/DOCS/pages/123456; these must be rewritten to Zendesk article URLs
• Article count parity: Compare source page count (excluding drafts, archived pages, and personal spaces) against published Zendesk article count
• Macro content survival: Flag any article where the character count dropped by more than 30% during transformation — a heuristic signal that macro content was silently dropped
• Locale assignment: Verify each article is assigned to the correct Zendesk locale, particularly for multilingual migrations
• Author assignment: Confirm author_id values on Zendesk articles map to the intended source authors

Manual review of a 10–15% random sample is recommended in addition to automated checks. Automated checks catch systematic failures; manual review catches one-off rendering issues and content quality problems.

How do you migrate from Zendesk Help Center to Confluence?

The reverse direction has a different challenge profile. Zendesk stores articles as standard HTML, which is easier to parse — but loading into Confluence requires converting that HTML into Confluence's XHTML storage format with its custom XML namespace elements.

Extraction

# List all articles (paginate with per_page up to 100)
GET /api/v2/help_center/articles.json?per_page=100&page=1
 
# List categories and sections for hierarchy reconstruction
GET /api/v2/help_center/categories.json
GET /api/v2/help_center/sections.json

Critical note: Zendesk's standard account data export (/api/v2/export) does not include Help Center content — articles, categories, and sections are excluded from that export package. You must retrieve all Guide content through the Help Center API or a migration tool that calls it directly. If you are closing a Zendesk account, retrieve Help Center content via API before cancellation; CDN-hosted images will eventually become inaccessible after account closure.

Transformation

Convert HTML article bodies to Confluence's XHTML storage format:

• Ensure all elements are valid XML (self-close <br/>, <img/>, <hr/> — HTML's unclosed void elements are invalid XML)
• Convert internal Zendesk article links (/hc/en-us/articles/123456) to Confluence <ac:link> elements with <ri:page> resource identifiers
• Strip or replace JavaScript-dependent widgets, iframes, and Zendesk-specific dynamic elements (Confluence will reject inline JS)
• Map Zendesk's Category → Section → Article hierarchy to Confluence Spaces → Parent Pages → Child Pages using the ancestors array in the Confluence API

Loading

POST /wiki/rest/api/content
{
  "type": "page",
  "title": "Quick Start Guide",
  "space": {"key": "DOCS"},
  "ancestors": [{"id": "parent-page-id"}],
  "body": {
    "storage": {
      "value": "<p>Converted XHTML content here</p>",
      "representation": "storage"
    }
  }
}

Setting the ancestors array reconstructs hierarchy. Zendesk's flat three-tier structure maps cleanly to two levels of Confluence page nesting (Section pages as parents, Article pages as children under them), which is a simpler mapping than the reverse direction.

What are the common migration pitfalls?

These are the failure modes that appear most frequently in Confluence ↔ Zendesk migrations:

Macro loss (Confluence → Zendesk). Confluence macros — table of contents, expand/collapse, code blocks, Jira issue embeds, page properties — have no Zendesk equivalent. Without explicit pre-processing, these macros either drop silently (leaving no visible content gap) or produce raw XML in the rendered article. The most dangerous are content macros like "include page" (<ac:structured-macro ac:name="include">) that pull content from other Confluence pages — if not resolved at extraction time, that content is simply absent in Zendesk.

Image breakage. Both platforms host images in their own storage systems. Images referenced by relative paths or attachment URLs become broken the moment the source account is deactivated. Every migration that skips the download-rehost-rewrite cycle will produce broken articles. This is not an edge case — it affects every article with an inline image.

Hierarchy flattening (Confluence → Zendesk). Confluence spaces with 4+ levels of page nesting require editorial decisions, not just scripting. The common failure mode: mapping every page at depth 3+ to an Article and losing the hierarchical context entirely, leaving users unable to navigate related content. This is an information architecture problem that requires human judgment before the migration script runs.

Rate limit throttling. With 2,000 articles and an average of 3 images per article, a migration involves at minimum 2,000 article creates + 6,000 image uploads = 8,000+ API calls. At any rate limit, this takes multiple hours minimum. Migrations without exponential backoff and retry logic fail partway through and require partial re-runs with duplicate-detection logic.

Author mapping gaps. Zendesk requires every article author to be an active agent. If your Confluence space has 50 contributing authors and you have 10 Zendesk agent seats, you face a choice: consolidate all migrated content under a single "Migration" service account, map to the closest existing agent, or purchase additional light-agent seats. Light-agent seats in Zendesk are a lower-cost license tier (contributing-only, no ticket handling) that can be used for authorship — they are priced separately from full agent seats.

Draft state mismatch. Confluence pages are live as soon as they are saved (absent space-level restrictions). Zendesk articles created via API default to draft: true. A migration that does not explicitly publish articles creates a help center that appears empty to customers even after a "successful" import.

Localization mismatch. If source content exists in multiple languages, failing to set the correct locale on each Zendesk article during creation results in all content defaulting to the account's primary locale. Correcting this after the fact requires updating every affected article individually — the API does not support bulk locale reassignment.

Aggregate patterns from knowledge-base migrations

Based on migrations involving Confluence as a source or target:

• Hierarchy depth: The majority of Confluence spaces that require migration to a three-tier system (like Zendesk) have 3–5 levels of page nesting. Fewer than one in five have a flat enough structure to migrate without any editorial hierarchy decisions.
• Most common silently-dropped macro types: Table-of-contents macros, "include page" macros, and Jira issue macros account for the majority of content loss in Confluence → Zendesk migrations when transformation is done naively. These three macro types should be detected and flagged before any migration script runs.
• Image volume: Articles with embedded screenshots or diagrams (common in technical documentation) average 3–7 images per article. A 1,000-article Confluence space may require 3,000–7,000 separate image download-and-rehost operations.
• Author consolidation: In migrations from large Confluence instances (500+ pages, 50+ contributors) to Zendesk, the number of unique page authors almost always exceeds the available Zendesk agent seats. Budget for author mapping decisions before the migration begins, not during.
• Engineering time: For a 500-article migration with images and moderate macro usage, expect 20–40 hours of engineering time for the transformation layer alone — not counting extraction, validation, and post-migration fixes. Migrations with heavy Jira macro usage or multi-locale content take longer.

Can you run Confluence and Zendesk Help Center together?

Yes, and many organizations do. A common architecture: Confluence for internal docs (engineering runbooks, product specs, internal processes) and Zendesk Help Center for customer-facing articles.

Zendesk offers a Knowledge Connector to Confluence that lets support agents search Confluence content from within the Zendesk agent workspace. This surfaces Confluence search results in the agent interface without migrating content — Confluence pages are indexed for agent search but not published to the customer-facing Help Center.

Evaluate this connector before committing to a full migration. If the goal is letting support agents reference internal documentation while handling tickets, the connector may be sufficient. If the goal is consolidating customer-facing content onto a single platform with Zendesk's ticket deflection workflow, a full migration is necessary.

Making the Right Call

The Confluence vs. Zendesk Help Center decision reduces to two axes: audience (internal vs. external) and workflow integration (wiki-style collaboration vs. ticket deflection).

For internal knowledge management with deep hierarchy and Atlassian integration, Confluence is the clear choice at a fraction of the cost. For customer-facing self-service tightly coupled to a ticketing system, Zendesk Help Center earns its price through ticket deflection workflows and AI-powered support automation.

If you are migrating between the two, the technical work lives primarily in the transformation layer: converting Confluence's XHTML storage format to standard HTML (or the reverse), flattening or reconstructing content hierarchy, re-hosting images, and handling localization. The API calls themselves are well-documented. The content transformation, hierarchy mapping, and editorial decisions around macros and structure are where projects run over time and budget.

Key decisions to make before writing any code:

1. Which Confluence API version (v1 or v2) does your source content use?
2. Is your source space using the legacy editor or the Fabric editor?
3. How will you flatten or restructure page hierarchy to fit the target model?
4. How will you handle macros that have no equivalent in the target platform?
5. Do you have multi-locale content, and if so, what is your locale mapping strategy?
6. How will you map source authors to target user accounts?

Answering these six questions before migration begins is the difference between a predictable project and one that discovers structural problems mid-execution.