Document360 to Zendesk Guide Migration: The CTO's Technical Guide

There is no native migration path from Document360 to Zendesk Guide. Document360 doesn't offer a Zendesk Guide importer, and Zendesk has no built-in import for Document360 content. The Document360 Zendesk app is a sidebar integration that lets agents search Document360 from within Zendesk Support — it does not move content. (docs.document360.com)

To actually migrate your knowledge base, you need to extract content via Document360's API or ZIP export, transform formatting and hierarchy, and push it into Zendesk's Help Center API. This guide covers the exact constraints, data-mapping decisions, and failure modes you'll hit along the way.

For a broader framework on moving any knowledge base without downtime, see The Ultimate Knowledge Base Migration Checklist.

Why Teams Consolidate Document360 into Zendesk Guide

The most common driver is tool consolidation. If your support team already runs on Zendesk for tickets, maintaining a standalone knowledge base creates friction that compounds daily — agents switch tabs to find articles, analytics stay siloed, and you pay for an extra vendor contract.

The operational case:

• Answer Bot and suggested articles only work with articles in Zendesk Guide. If your KB lives in Document360, agents can't leverage Zendesk's AI-powered article suggestions inside the ticket workflow.
• Single-pane reporting. Zendesk Explore correlates ticket deflection, article views, and agent activity — but only for Guide articles. Document360 analytics stay siloed.
• Agent authoring workflow. Zendesk's Knowledge Capture app lets agents flag, create, and link articles without leaving a ticket. That workflow breaks if the KB is external.
• One fewer vendor contract. License costs, SSO configurations, and training overhead for a standalone KB tool add up when you already pay for Zendesk Suite.

The trade-off is real: Document360 has a richer editor, deeper category nesting, and more granular per-category permissions. You lose some of that flexibility when you move to Zendesk Guide. Go in with your eyes open.

Document360 Export Methods: Why CSV Isn't Enough

Document360 offers three export paths. Each has hard constraints that determine your migration strategy.

CSV Export (Metadata Only)

The CSV export from Document360's All Articles section only includes metadata — titles, categories, status, dates, and URLs. It does not include article body content. If you try to use this as your primary export, you'll get a spreadsheet of titles with no actual articles to import. (docs.document360.com)

ZIP Export (Full Content)

The primary content export method. Navigate to Content Tools → Import & Export → Import and export project and click Export. The format of the exported files depends on the editor type:

• Articles created in the Markdown editor export as .md files
• Articles created in the WYSIWYG or Advanced WYSIWYG editor export as .html files
• If you select multiple languages, everything exports as .json

You can include media files by checking the Include media files option. The ZIP contains a Media folder and a workspace folder with articles, categories, and a JSON manifest.

Key limitations:

• Content reuse elements — templates, variables, snippets, and glossary terms — are not included in the ZIP export
• If your Document360 project uses both Markdown and WYSIWYG editors, the ZIP contains a mix of .md and .html files. Your migration pipeline must detect and handle both formats
• The JSON export format for multi-language projects uses a different structure than single-language exports

API Export

Document360's REST API allows programmatic extraction of articles, categories, and project metadata. The project export endpoint (POST /v2/Project/Export) supports filtering by version, language, and category, and can include or exclude media. It also supports filtering by article modified date — useful for delta runs during a staged cutover. (apidocs.document360.com)

The project export API is limited to 2 requests per day on Business and Enterprise plans — a hard cap that means you can't iterate quickly on test exports.

For article-level extraction, use GET /v2/Articles/{articleId} to pull individual article content, html_content, slug, translation info, visibility, and SEO settings. Article versions are available via /v2/Articles/{articleId}/{langCode}/versions, giving you enough source data to migrate the latest published version and archive older revisions if you need an audit trail. (apidocs.document360.com)

Document360 applies per-token rate limits: 60 requests per minute on Professional and Business plans, and 100 requests per minute on Enterprise and Enterprise Plus. Your extraction script must implement exponential backoff. (apidocs.document360.com)

For more context on Document360's export behavior and API constraints, see Document360 to Notion Migration: Data Mapping, API Limits & Methods.

Mapping Content: Hierarchy Constraints

Category Hierarchy: The Depth Problem

The biggest architectural hurdle is structure mismatch. Document360 supports deep category nesting — categories can contain sub-categories to arbitrary depth, and articles can live at any level. Zendesk Guide is stricter.

Zendesk Guide hierarchy: Category → Section → Article

On Enterprise plans, Zendesk allows nested sections (subsections) up to five section levels deep, giving you a maximum of six levels total: Category > Section > Section > Section > Section > Section. Each section can contain up to 200 subsections. Articles can be placed at any section level but cannot appear directly under a category — they must live inside a section.

On non-Enterprise plans, you get the flat Category → Section → Article structure with no subsections.

Flattening strategy for non-Enterprise plans: Combine parent and child category names into a single Zendesk Section title.

• Document360: Product (Category) > Setup (Subcategory) > Integrations (Sub-subcategory) > "How to connect API"
• Zendesk Guide: Product (Category) > Setup - Integrations (Section) > "How to connect API"

Document360 also has three category types — Folder (no URL or content), Index (auto-generated listing), and Page (editable content). Zendesk sections are containers only — they don't hold content. If you have Page-type categories with content in Document360, that content needs to become a standalone article inside the corresponding Zendesk section. (docs.document360.com)

Rich Text and Custom CSS Translation

Document360's Advanced WYSIWYG editor supports custom CSS, callout blocks, embedded videos, code blocks with syntax highlighting, tabs, and accordions. Zendesk Guide articles accept HTML, but Zendesk automatically sanitizes the payload — stripping <script> tags, unapproved <iframe> domains, and unrecognized CSS classes.

Key formatting translation issues:

• Callout blocks: Document360 uses specific HTML markup (e.g., <div class="d360-callout-info">) for info/warning/tip callouts. These must be converted to styled <div> elements with CSS classes defined in your Zendesk Guide theme, or they render as plain unstyled text.
• Custom CSS: Document360 permits per-article custom styling. Zendesk Guide scopes CSS to the theme level. Inline styles in article HTML will render, but they can clash with the theme's stylesheet. Expect to audit and clean up custom styling.
• Code blocks: Document360 renders code blocks with syntax highlighting. Zendesk Guide's editor has no built-in syntax highlighting. You can preserve <pre><code> blocks, but you'll need to add a library like Prism.js or Highlight.js to your Zendesk theme.
• Tabs and accordions: These rely on Document360's theme JavaScript. Zendesk has no equivalent. Rebuild them as styled HTML in the Zendesk theme or simplify the content structure.
• Embedded videos: <iframe> embeds for YouTube/Vimeo carry over in the article HTML, but Zendesk's editor strips certain iframes unless you edit the source HTML directly.
• Images: All images hosted on Document360's CDN must be re-hosted. If you leave image src attributes pointing to Document360, they'll break the moment your Document360 subscription ends. Download every image and upload it via Zendesk's Article Attachments API.

Your migration middleware must parse the Document360 HTML/Markdown export, identify Document360-specific <div> classes, translate them into Zendesk-compatible HTML, and update your Zendesk Guide theme's style.css to support those translated classes. If you skip this step, your articles migrate as unstyled, flat text blocks.

For a deeper look at how formatting issues compound during migration, review Common Helpdesk Migration Mistakes and How to Avoid Them.

Migrating Permissions: Reader Groups to Zendesk User Segments

Document360 uses Reader Groups to control access to content in private or mixed-mode knowledge bases. Reader Groups can restrict access at the workspace, language, or category level, and article-level restrictions can override category-level access.

Zendesk Guide uses User Segments (for viewing) and Permission Groups (for editing). User Segments are collections of end users and agents defined by tags, organizations, groups, or individual users.

There is no API to bulk-migrate permission logic. A Document360 Reader Group that grants access to a specific language plus category scope might become a Zendesk segment based on organization plus user tag — or it might justify a separate brand if the audience split is structural. (apidocs.document360.com)

The migration path:

1. Map your users first. Reader Groups depend on reader accounts. Those readers need to exist as end users in Zendesk with the appropriate tags or organization memberships before you apply segments.
2. Recreate Reader Groups as User Segments in the Zendesk Admin Center (based on user tags, organizations, or groups).
3. Retrieve the IDs for each new User Segment via GET /api/v2/help_center/user_segments.
4. Apply segments at the article level. Zendesk sets permissions per-article, not per-section. If you had a private category in Document360 with 50 articles, you need to apply the correct User Segment to all 50 individually (or use Zendesk's bulk update feature).

{
  "article": {
    "title": "Internal API Documentation",
    "body": "<p>Private content here.</p>",
    "locale": "en-us",
    "user_segment_id": 123456789,
    "permission_group_id": 987654321
  }
}

SEO Continuity: 301 Redirects and Slug Mapping

SEO is where teams most commonly take damage during this migration. Document360 and Zendesk Guide use completely different URL structures:

• Document360: https://docs.yourcompany.com/docs/article-slug
• Zendesk Guide: https://yourcompany.zendesk.com/hc/{locale}/articles/{article_id}-{slug}

Zendesk Guide URLs include a numeric article ID assigned at creation time. You cannot control this ID. You can customize the slug portion, but the full URL will always differ from Document360. Old slugs still resolve as long as the ID is present, because the ID is the durable part of the Zendesk URL. (support.zendesk.com)

If you do not implement 1-to-1 redirects, every existing link to your documentation — in customer emails, external blogs, and Google search results — returns a 404.

What you must do:

1. Build a redirect map before cutover. Export every Document360 article URL and map it to the new Zendesk Guide URL. This requires creating articles in Zendesk first (to get the article IDs), then generating the redirect rules.
2. Implement 301 redirects at the DNS/proxy layer. If you used a custom domain for Document360 (e.g., docs.yourcompany.com), configure your CDN or reverse proxy to 301-redirect old paths to new Zendesk URLs. Zendesk itself cannot host redirects for your old Document360 domain.
3. Use Zendesk's Redirect Rules API for paths on your Zendesk domain. It supports up to 50,000 redirect rules per brand. (developer.zendesk.com)

POST /api/v2/guide/redirect_rules
 
{
  "redirect_rule": {
    "redirect_from": "/docs/api-authentication",
    "redirect_to": "/hc/en-us/articles/360012345678",
    "redirect_status": 301
  }
}

4. Handle meta descriptions. Zendesk Guide doesn't expose a dedicated meta description field. The article body's first ~140 characters effectively become the meta description in search results unless you customize the theme's <meta> tags. If your Document360 articles had custom SEO meta descriptions, rewrite the opening paragraph of each article to carry the same intent. (support.zendesk.com)
5. Update internal links. Every cross-reference between articles must be rewritten from Document360 paths to Zendesk Guide URLs. Miss this, and you'll have broken links inside your own help center.

Load the redirect map before DNS or navigation cutover, then crawl-test against a sample of your highest-traffic legacy URLs.

For more on Zendesk Guide's data model and URL structure, see How to Export Data from Zendesk Guide: Methods, Limits & Formats.

Zendesk Help Center API: Rate Limits and Locale Handling

Rate Limits by Plan

The Zendesk Help Center API shares rate limit tiers with the Support API, but requests are counted separately. Your migration scripts won't compete with your support team's ticket API traffic.

The High Volume API add-on replaces your plan's limit with 2,500 RPM. It's available on Growth+ plans with a minimum of 10 agent seats. Enterprise Plus includes it by default.

Creating an article, uploading an inline image, and applying a translation each count as separate API calls. A single article with five images requires six API requests. For a knowledge base of 500 articles with images at 700 RPM (Enterprise), expect the article creation step alone to take 10–15 minutes. Add image uploads, translation creates, and section/category setup, and a full migration pipeline runs 30–90 minutes of API time.

Build retry logic with exponential backoff — 429 responses include a Retry-After header.

Multilingual Content and Locale Mapping

If your Document360 project supports multiple languages, each language version must be mapped to a Zendesk locale code. Zendesk Guide displays localized content based on the locale in the URL path (e.g., /hc/en-us/, /hc/fr/).

Key constraint: any translated article must have its parent section and category also translated in the same language. If you create a French translation of an article but don't translate its parent section and category into French, the article won't be visible in the French help center — even if it's published. This is a silent failure mode that trips up most migration scripts.

The correct import order:

1. Enable Help Center locales
2. Create categories in the default locale
3. Add category translations
4. Create sections and subsections plus their translations
5. Import source-locale articles
6. POST article translations via POST /api/v2/help_center/articles/{id}/translations

If you create articles first and navigation later, QA becomes messy fast. Document360's multi-language export outputs content in JSON format, where each article includes language variants that must be mapped to the Zendesk Translations endpoint.

Analytics Continuity: What You Lose

There's no way to migrate Document360's historical analytics into Zendesk. Document360 tracks views, reads, likes, dislikes, time spent, and geographic distribution per article. Zendesk Guide analytics are powered by Zendesk Explore and track different metrics (article views, search terms, ticket deflection).

What this means:

• Historical article performance data stays in Document360. Export it before canceling your subscription.
• Zendesk Explore starts tracking from zero on your migrated articles.
• Any A/B testing or content optimization workflows based on Document360 analytics need to be rebuilt.
• If you report on KB performance to leadership, set expectations that you'll have a data gap during the transition.

Migration Methods Compared

DIY API Scripts

When it works: Small knowledge bases (<100 articles), flat hierarchy, single language, engineering team has bandwidth.

The workflow:

1. Export content via Document360 ZIP export or API
2. Parse .md/.html/.json files into a normalized format
3. Create categories and sections via Zendesk Help Center API
4. Create articles with HTML bodies, handling image re-hosting
5. Apply translations for each locale
6. Set user segment permissions per article
7. Build and deploy redirect map

The risk: Most teams underestimate the edge cases — mixed editor types, image re-hosting, internal link rewriting, locale parent-chain requirements. A "two-week script" becomes a two-month project.

Help Desk Migration (HDM)

HDM offers a self-serve tool for Document360 migrations. It handles basic article and category transfers but has notable gaps:

• No custom CSS or callout block translation
• Limited hierarchy mapping (doesn't handle deep nesting)
• No 301 redirect generation
• No permission/segment migration

For a flat, public, single-language knowledge base, HDM can work. For anything more complex, you'll finish the job manually.

ClonePartner Managed Migration

This is what we do. Our team builds custom migration pipelines for knowledge base moves, handling the full scope:

• Content extraction via Document360's API and ZIP export, with mixed editor-type detection
• HTML transformation — translating Document360's callout blocks, code blocks, and custom CSS into Zendesk-compatible markup
• Hierarchy flattening — mapping deep Document360 categories into Zendesk's section structure without losing content logic
• Image re-hosting — downloading every media asset from Document360's CDN and uploading to Zendesk's Article Attachments API
• Internal link rewriting — every cross-article reference updated to the new Zendesk URL
• 301 redirect map — generated automatically from the old/new URL mapping
• Permission mapping — Reader Groups translated to User Segments with article-level application
• Multilingual locale mapping — including parent section/category translation chain validation

We've completed 1,500+ migrations across helpdesks, CRMs, and knowledge bases. Knowledge base moves are particularly sensitive because a single broken redirect or missing image degrades customer self-service immediately. We run every migration with a full test pass on a staging help center before touching production.

For common migration failure modes, see Common Helpdesk Migration Mistakes and How to Avoid Them.

De-Risking the Move

Migrating from Document360 to Zendesk Guide is a bet on platform consolidation. The operational upside — unified analytics, AI article suggestions, single-pane agent workflow — is real. The cost is losing Document360's richer editor, deeper hierarchy, and more granular permissions model.

Before you touch production, build three artifacts: a hierarchy mapping file, a permissions matrix, and a redirect map. If you don't have those, you're still scoping the migration, not executing it.

1. Audit your content first. Count articles, languages, editor types, private categories, and embedded media. Migration complexity maps directly to the asset inventory.
2. Export Document360 analytics before you cancel. That historical data doesn't transfer.
3. Build the redirect map early. SEO damage from a botched URL migration takes months to recover.
4. Test on a staging Zendesk instance. Create articles in a sandbox, verify formatting, check locale parent chains, and validate user segment behavior before go-live.
5. Don't underestimate image re-hosting. It's tedious and invisible, but if you skip it, your help center breaks the day your Document360 subscription ends.

The shortest migration path is usually the path with the most rework. The safe one is boring: extract fully, transform deliberately, recreate permissions first, import by locale and section order, and launch with redirects already live. If your Document360 workspace is public-only and fairly flat, a script can be enough. If it includes private content, deep hierarchy, multilingual variants, or SEO dependency, bring in people who do this all the time.