Document360 to Zendesk Guide has no native path. You need API/ZIP extraction, HTML transformation, hierarchy flattening, image re-hosting, permission rebuilds, and 301 redirects. CSV export won't work.
There is no native migration path from Document360 to Zendesk Guide — neither platform offers a built-in importer or exporter for the other, and the existing Document360 Zendesk app is only a sidebar search integration, not a content mover. The fundamental data model difference centers on hierarchy: Document360 supports arbitrary-depth category nesting while Zendesk Guide enforces a strict Category → Section → Article structure (with nested subsections only on Enterprise plans, up to six levels). Custom migration work is required to extract content via Document360's API or ZIP export, transform rich formatting (callouts, tabs, accordions, code blocks) and hierarchy into Zendesk-compatible HTML, re-host all media assets, map reader group permissions to Zendesk user segments, and implement SEO redirects for changed URLs.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Document360's CSV export does not contain article content
It exports metadata only (titles, status, URLs). Use the ZIP export or the API to extract actual article bodies.
If your Document360 project has categories deeper than six levels, you must flatten the
If your Document360 project has categories deeper than six levels, you must flatten the hierarchy before migration. Map deep categories into a shallower structure and update all internal cross-links accordingly.
Audit non-reader content before migration
Document360 private notes are intended for team members and do not appear to readers. If you export blindly, those notes could become public Zendesk article text. Strip or reroute them before import. (docs.document360.com)
Suite Team plans do not support custom user segments
If you need private or restricted content in Zendesk Guide, you need at least Suite Growth or Guide Professional.
Recreate Zendesk organizations, user tags, and agent groups before you publish private content
Otherwise your imported articles may default to the wrong audience or force last-minute permission fixes. (support.zendesk.com)
Migration throughput is bounded by the slower side of the pipeline
Document360 export rate, transform time, or Zendesk import rate. Budget for throttling and retries on both ends. (apidocs.document360.com)
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Decide what content deserves to move before you plan how to move it.
Objective A content inventory with a keep/rewrite/retire decision on every article and an agreed URL strategy.
Keep these open
-
Inventory all content in Document360
Count articles, categories, attachments, images and embedded media, and pull page views and last-updated dates for each article. Usage data is what makes the next decision defensible rather than political.
Data Profiler Get real record counts instead of estimating from memory -
Make a keep, rewrite or retire call on every article
Most knowledge bases are half stale. Migrating everything imports the staleness and doubles the work; use views and last-updated to triage, and get the owning team to confirm. This usually removes 30-50% of scope.
Migrating stale content is the most common knowledge-base migration mistake — it costs effort and actively degrades the new site.
-
Agree the URL and redirect strategy
Decide the Zendesk URL structure and whether you can serve 301 redirects from the old paths. Public help centres carry real search traffic and inbound links; losing it is a measurable commercial impact.
Without 301 redirects from old article URLs you lose accumulated search ranking and every external link and bookmark breaks.
-
Map the information architecture
Document the current category tree and design the target one, checking whether Zendesk supports your nesting depth. Deeply nested hierarchies frequently have to be flattened, which changes navigation for everyone.
-
Confirm permissions, audiences and localisation scope
Establish which content is public, internal or restricted, and how Zendesk models that. Then confirm how many locales you have and whether translation relationships between articles survive the move.
Document360 → Zendesk specifics
- 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.
- Article count comparison
- Query GET /api/v2/help_center/articles?per_page=100 and paginate to get a total article count. Compare it against your Document360 source count. Any delta is a missing article.
Don't move on until
- Full content inventory with page views and last-updated dates
- Keep / rewrite / retire decision recorded per article
- URL and redirect strategy agreed with whoever owns SEO
02 Data Audit Audit the markup, the links and the assets — that is where KB migrations break.
Objective A content export with markup, internal links and every embedded asset accounted for.
Keep these open
-
Export content and assess markup fidelity
Export articles in the richest format available and inspect what survived: tables, code blocks, callouts, nested lists, anchors and embedded video. Rich formatting is where fidelity is lost, and it is lost quietly.
HTML-to-Markdown conversion routinely mangles nested lists, tables and code blocks. Inspect the output rather than trusting the converter.
Data Profiler Profile the Document360 export for nulls, outliers and type drift -
Inventory every internal link and cross-reference
Extract all internal links, anchor links and article cross-references. These break by default: the target URL structure differs, so every internal link needs rewriting as part of the load, not afterwards.
Internal links left pointing at old URLs turn the new knowledge base into a maze of 404s on day one.
-
Inventory images, attachments and embedded media
List every asset with its URL, size and type, and confirm each still resolves. Assets hosted on the old platform's CDN will 404 the moment you decommission it, so they must be rehosted, not referenced.
Images referenced from the source platform's CDN break when the old account closes. Download and rehost every asset.
-
Find and fix broken links and orphans
Crawl for existing broken internal and external links, and find articles no category links to. Fix them before migrating — a migration is a bad time to discover pre-existing rot.
-
Check for PII and internal information in public content
Scan for customer names, internal hostnames, credentials in code samples and screenshots containing real data. Republishing these on a public help centre is a disclosure, and screenshots are the usual culprit.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Normalise metadata
Standardise authors, tags, timestamps to UTC, and locale codes. Author mapping needs a decision for people who have left — attribution to a deleted user usually fails the import.
Don't move on until
- Content exported with markup fidelity assessed
- Every internal link and asset reference inventoried
- Broken links and missing assets fixed or logged
03 Field Mapping Map structure, metadata, permissions and — above all — URLs.
Objective A mapping covering article fields, taxonomy, permissions and a complete old-to-new URL map.
Keep these open
-
Map the article schema
Map title, body, excerpt, author, dates, status, tags, SEO metadata and any custom properties. Confirm which fields Zendesk lets you set on import versus which it computes — computed dates are a common surprise.
Schema Mapper Opens pre-loaded with the Document360 → Zendesk field pair -
Map the taxonomy and hierarchy
Map categories, sections and tags to the target structure, resolving any nesting-depth limit explicitly. If you must flatten, decide how the lost level is preserved — usually as a tag or a title prefix.
JSON to CSV Converter Flatten nested API responses into a reviewable sheet -
Map permissions and audience segmentation
Map public, logged-in, and role-restricted visibility to Zendesk's model. Verify the mapping deliberately: internal content accidentally published publicly is the highest-severity failure in this whole category.
Permission mapping errors publish internal documentation to the open web. Verify visibility on every restricted article after load.
-
Build the complete old-to-new URL map
Produce a row per article mapping the old URL to the new one, then confirm exactly where the 301s will be served — Zendesk, a CDN, or your own web layer. Without this artifact the redirect step cannot be executed at all.
-
Define the markup conversion and link-rewrite rules
Specify how each markup construct converts and how internal links are rewritten using the URL map. Write it as a repeatable transform, not manual edits — you will run it more than once.
Data Format Converter Reshape the export into the format Zendesk's importer expects -
Plan localisation and freeze the spec
Confirm how translated articles link to their source language in Zendesk, then version and sign off the mapping spec.
Don't move on until
- Article schema and taxonomy mapped
- Permission and audience model mapped to target equivalents
- Complete URL map produced and redirect method confirmed
04 Test Migration Pilot the hardest articles, then read them.
Objective A pilot load whose formatting, links, assets and search all hold up under human review.
Keep these open
-
Configure Zendesk with the agreed structure
Create the category tree, permission groups, locales and branding before loading. Articles loaded before their categories exist land uncategorised and have to be moved by hand.
-
Pick the most difficult articles as the pilot
Choose 20-50 articles for difficulty: the longest, the most heavily formatted, ones with tables and code blocks, deep internal linking, many images, embedded video, restricted visibility, and non-Latin scripts. Easy articles prove nothing.
-
Run the conversion and load with link rewriting
Apply the markup conversion, rewrite internal links from the URL map, upload and re-reference assets, then load. Log every conversion warning rather than suppressing it.
-
Read every pilot article side by side
Open source and target together and compare rendering. This step is manual on purpose: no automated check catches a table that collapsed into a paragraph or a code block that lost its indentation.
-
Click every link and load every asset
Verify each internal link resolves, each image loads from the new host, each attachment downloads and each embed plays. Assets still served from the old CDN are the defect that surfaces only after decommissioning.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Test search and permissions
Search for known terms and confirm the right articles rank, then verify every restricted pilot article is invisible to an anonymous browser. Test permissions from a logged-out session, not an admin one.
Document360 → Zendesk specifics
- Redirect smoke test
- Take a sample of your highest-traffic legacy Document360 URLs and confirm each returns a 301 to the correct Zendesk article. Automate this with a script that reads your redirect map and checks response codes.
Don't move on until
- Complex articles render correctly with formatting intact
- Every internal link and asset in the pilot resolves
- Search returns sensible results for the pilot content
05 Cutover Publish, redirect, and keep the search traffic.
Objective All in-scope content live in Zendesk with redirects serving and search engines informed.
Keep these open
-
Load the full content set ahead of the switch
Run the full conversion and load into Zendesk, unpublished or on a staging domain. Content migration differs from data migration here: you can stage the whole thing before anyone sees it.
-
Publish the runbook with the redirect step first-class
Sequence the freeze, final delta, publish, redirect activation, sitemap submission and link updates, with owners for each. Redirect activation is the step with lasting commercial consequences, so it gets explicit ownership.
-
Freeze editing and migrate the delta
Stop editing in Document360, then convert and load anything changed since the full load. Announce the freeze to every team that publishes — content teams are used to editing whenever they like.
-
Publish and verify permissions live
Publish the content set, then immediately verify restricted articles are not publicly reachable using an anonymous session. Do this before announcing the new site, not after.
Verify restricted content from a logged-out browser. An admin session will show you everything and tell you nothing.
Migration Validation Tool Confirm the final delta landed before you reopen -
Activate 301 redirects and submit the sitemap
Turn on the redirects from the URL map, then spot-check a sample of high-traffic old URLs and confirm each returns 301 to the right article. Submit the new sitemap and keep the old one reachable until search engines have recrawled.
Redirect chains and redirect loops both leak ranking. Verify each redirect resolves in a single hop.
-
Repoint in-product and support links
Update help links embedded in your product, in support macros, in email templates and in onboarding material. These are the links your existing customers actually use, and they are easy to forget.
Don't move on until
- All content loaded, categorised and correctly permissioned
- 301 redirects live and verified from a sample of old URLs
- Sitemap submitted and support links repointed
06 Validation Watch traffic, links and search rankings for weeks, not hours.
Objective Verified content completeness, healthy redirects, and search traffic recovered to baseline.
Keep these open
-
Reconcile content counts and assets
Compare article counts by category and status, plus asset counts, against source. Confirm every article in the keep list is present and every retired one genuinely is not.
Migration Validation Tool Reconcile Document360 and Zendesk record-for-record -
Crawl the new site for broken links and assets
Run a full crawl for 404s, broken images and missing attachments, and fix everything it finds. Repeat the crawl after the fixes rather than assuming they worked.
-
Verify the redirects at scale
Test every mapped old URL for a single-hop 301 to the right destination. Chains and loops both leak ranking and are invisible unless you check the whole map, not a sample.
-
Monitor organic traffic and rankings for four to eight weeks
Track organic sessions, impressions and rankings for your top articles against baseline. A dip in the first two weeks is normal; one that has not recovered by week six is a redirect or indexing problem to investigate.
Do not decommission the old platform until search traffic has recovered — you may still need the old URLs to diagnose a ranking loss.
-
Verify search, permissions and feedback loops
Confirm on-site search returns good results for real queries, re-verify restricted content from a logged-out session, and check article feedback and analytics are collecting.
-
Sign off and decommission on a delay
Get acceptance against the Discovery criteria, keep Document360 available read-only until traffic has recovered, take a final export, and only then close the account.
Document360 → Zendesk specifics
- Image 404 scan
- Crawl every migrated article and check that all <img src> attributes return HTTP 200. A single batch of un-reuploaded images will surface here.
- Internal link validation
- Parse all <a href> values in migrated articles and verify they resolve within your Zendesk help center. Document360 paths that weren't rewritten will 404.
- Locale visibility check
- For each translated article, confirm it appears in the correct language help center by fetching GET /api/v2/help_center/articles/{id}/translations and verifying the expected locale codes are present and published.
- Permission spot-check
- For private content, verify that articles with a user_segment_id are not accessible to unauthenticated requests.
Don't move on until
- Article counts reconciled and no broken links remain
- Redirects returning 301 with no chains or loops
- Organic traffic recovered to within tolerance of baseline
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
Document360 Guide (Enterprise)
| Document360 field | Zendesk field | Notes |
|---|---|---|
| Top-level category | Category | 1:1 mapping |
| Sub-category (level 1) | Section | Direct mapping |
| Sub-category (level 2) | Subsection | Enterprise only |
| Sub-category (levels 3–5) | Nested subsection | Enterprise only, may require theme code changes |
| Sub-category (levels 6+) | ❌ No equivalent | Must flatten or restructure |
| Article under category | Article under section | Must create an intermediate section |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Article Body Content | medium | Article HTML/Markdown content exports reliably via ZIP or API, but Document360-specific markup (callouts, tabs, accordions) requires custom transformation to render correctly in Zendesk Guide. |
| Category Hierarchy | high | Document360's arbitrary nesting depth cannot map directly to Zendesk Guide's limited hierarchy, requiring manual flattening decisions that alter the information architecture. |
| Images and Media | high | All media must be downloaded from Document360's CDN and re-uploaded to Zendesk, and any missed assets will result in broken images once the source subscription expires. |
| Content Reuse Elements | high | Templates, variables, snippets, and glossary terms are explicitly excluded from Document360's ZIP export and have no equivalent in Zendesk Guide, requiring manual recreation or inline expansion. |
| Reader Permissions | high | Document360's granular per-category and per-article Reader Group restrictions must be manually reconstructed using Zendesk's User Segments and Permission Groups, which operate on a different access model. |
| SEO Metadata and URLs | medium | URL structures differ between platforms, requiring redirect mapping for all existing article URLs to preserve search engine rankings and inbound links. |
| Multi-language Content | medium | Multi-language exports use a different JSON structure than single-language exports, and translation associations must be correctly mapped to Zendesk Guide's locale-based translation system. |
| Article Metadata | low | Titles, statuses, dates, and slugs are available via both CSV and API exports and map straightforwardly to Zendesk Guide article properties. |
| Private Notes | medium | Document360 private notes intended for internal team use can inadvertently become public article content in Zendesk if not explicitly stripped during the migration process. |
| Custom CSS and Styling | medium | Document360 allows per-article custom CSS, while Zendesk scopes CSS to the theme level, meaning inline styles may clash with the theme and require auditing and cleanup. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Category Hierarchy Depth Mismatch
Document360 supports arbitrary-depth category nesting, while Zendesk Guide limits structure to Category → Section → Article (or up to six levels on Enterprise), requiring flattening or restructuring of deep hierarchies.
Rich Text Formatting Translation
Document360's callout blocks, tabs, accordions, custom CSS, and syntax-highlighted code blocks rely on platform-specific markup and JavaScript that Zendesk Guide strips or does not support, requiring manual conversion and theme-level CSS updates.
Image and Media Re-hosting
All images hosted on Document360's CDN must be downloaded and re-uploaded via Zendesk's Article Attachments API, as source URLs will break when the Document360 subscription ends.
API Rate Limits and Export Caps
Document360's project export API is limited to 2 requests per day, and article-level API calls are capped at 60–100 requests per minute, severely constraining iteration speed for test exports and large-scale extraction.
Permission Model Mapping
Document360's Reader Groups with workspace-, language-, category-, and article-level access controls must be translated into Zendesk's User Segments and Permission Groups, which use a fundamentally different tag- and organization-based model.
Mixed Export Format Handling
Document360's ZIP export produces a mix of .md, .html, and .json files depending on the editor type and language configuration, requiring the migration pipeline to detect and normalize multiple formats.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can I export full article content from Document360 as CSV?
No. Document360's CSV export only includes metadata — titles, categories, status, dates, and URLs. It does not include article body content. Use the ZIP export (which outputs .md, .html, or .json files depending on editor type) or the REST API to extract actual content. (docs.document360.com)
How deep can Zendesk Guide's category hierarchy go?
Zendesk Guide supports Category > Section > Article by default. On Enterprise plans, you can nest sections up to five levels deep (six total levels including the category). Articles cannot appear directly under categories — they must be in a section. If your Document360 hierarchy exceeds six levels, you must flatten it before migration.
What is the Zendesk Help Center API rate limit for migrations?
The Help Center API rate limit depends on your Zendesk Suite plan: 200 RPM (Team), 400 RPM (Growth/Professional), 700 RPM (Enterprise), or 2,500 RPM (Enterprise Plus). Help Center API requests are counted separately from Support API requests, so migration traffic won't compete with your ticket API usage.
How do I migrate Document360 Reader Groups to Zendesk?
There is no automated migration path for permissions. You must manually recreate Document360 Reader Groups as Zendesk User Segments based on tags, organizations, or groups. Zendesk sets permissions at the article level (not section or category), so each article needs the correct User Segment applied individually or via bulk update.
Will I lose analytics data when migrating from Document360 to Zendesk Guide?
Yes. Document360 analytics (views, reads, likes, time spent) cannot be migrated to Zendesk. Zendesk Explore starts tracking from zero on migrated articles. Export your Document360 analytics data before canceling your subscription.