Migration Playbook

Confluence Document360

Confluence to Document360: The Complete Migration Playbook

A 35-step runbook across six phases — track your progress, and open the right tool at every step.

0 / 35 steps complete 0%
TL;DR

High-fidelity Confluence to Document360 migration requires API-first extraction to avoid silent data loss from Word exports, the 50-image cap, and dual API rate limits.

There is no native Confluence-to-Document360 importer — no built-in connector, no one-click migration wizard. Document360's official path is a Word export handed to their managed team. Confluence stores content in a proprietary XHTML storage format with unlimited page nesting. Document360 uses a Category → Article hierarchy capped at 7 levels, with strict per-minute API rate limits. Every high-fidelity migration requires API-first extraction, programmatic macro translation, dual rate-limit orchestration, and full internal link rewriting.

Read this first

Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.

Looking for the reverse migration? If you are moving from Document360 to Confluence, the

Looking for the reverse migration? If you are moving from Document360 to Confluence, the architecture challenges are flipped. Read our complete Document360 to Confluence Migration Guide to learn how to handle the export format, map Document360 content types to Confluence, and execute the import.

Depth Limit Edge Case

If your Confluence page tree exceeds 7 levels of nesting, the migration must flatten deeper pages into articles at the 6th subcategory level. This requires a conscious information architecture decision before migration — not during. Audit your deepest page trees first.

Silent Data Loss Risk

The Word export does not warn you about dropped macros or images. You will only discover missing content during post-migration QA — or worse, when a customer reports it. Always run a content audit before relying on this method.

Rate Limit Math

A 1,000-article migration with an average of 3 attachments per article = 4,000 API calls minimum. At 60 req/min (Professional tier), that's ~67 minutes of sustained writes with no margin for error. At 100 req/min (Enterprise), it drops to ~40 minutes. Build your migration scripts with exponential backoff and respect the X-RateLimit-Remaining header on every response.

Include Macros Are the Biggest Risk

If your Confluence pages use {include} or {excerpt-include} to assemble content from multiple source pages, the migration must resolve these references and inline the content. Otherwise, your Document360 articles will have visible gaps where transclusions used to be. Audit for include macros before migration.

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. 0/5

Objective A content inventory with a keep/rewrite/retire decision on every article and an agreed URL strategy.

  1. Inventory all content in Confluence

    Content lead 2-3 days

    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
  2. Make a keep, rewrite or retire call on every article

    Content lead 1-2 weeks

    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.

  3. Agree the URL and redirect strategy

    SEO / web 2-3 days

    Decide the Document360 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.

  4. Map the information architecture

    Content lead 3-5 days

    Document the current category tree and design the target one, checking whether Document360 supports your nesting depth. Deeply nested hierarchies frequently have to be flattened, which changes navigation for everyone.

  5. Confirm permissions, audiences and localisation scope

    Content lead 2-3 days

    Establish which content is public, internal or restricted, and how Document360 models that. Then confirm how many locales you have and whether translation relationships between articles survive the move.

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. 0/6

Objective A content export with markup, internal links and every embedded asset accounted for.

  1. Export content and assess markup fidelity

    Content engineer 2-3 days

    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 Confluence export for nulls, outliers and type drift
  2. Inventory every internal link and cross-reference

    Content engineer 2-3 days

    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.

  3. Inventory images, attachments and embedded media

    Content engineer 2 days

    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.

  4. Find and fix broken links and orphans

    Content lead 2-3 days

    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.

  5. Check for PII and internal information in public content

    Compliance 1-2 days

    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
  6. Normalise metadata

    Content engineer 1-2 days

    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. 0/6

Objective A mapping covering article fields, taxonomy, permissions and a complete old-to-new URL map.

  1. Map the article schema

    Content engineer 2 days

    Map title, body, excerpt, author, dates, status, tags, SEO metadata and any custom properties. Confirm which fields Document360 lets you set on import versus which it computes — computed dates are a common surprise.

    Schema Mapper Opens pre-loaded with the Confluence → Document360 field pair
  2. Map the taxonomy and hierarchy

    Content lead 2-3 days

    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
  3. Map permissions and audience segmentation

    Content lead 2 days

    Map public, logged-in, and role-restricted visibility to Document360'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.

  4. Build the complete old-to-new URL map

    SEO / web 2-3 days

    Produce a row per article mapping the old URL to the new one, then confirm exactly where the 301s will be served — Document360, a CDN, or your own web layer. Without this artifact the redirect step cannot be executed at all.

  5. Define the markup conversion and link-rewrite rules

    Content engineer 3-5 days

    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 Document360's importer expects
  6. Plan localisation and freeze the spec

    Content lead 1-2 days

    Confirm how translated articles link to their source language in Document360, 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. 0/6

Objective A pilot load whose formatting, links, assets and search all hold up under human review.

  1. Configure Document360 with the agreed structure

    Content engineer 3-5 days

    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.

  2. Pick the most difficult articles as the pilot

    Content lead 0.5 day

    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.

  3. Run the conversion and load with link rewriting

    Content engineer 2-3 days

    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.

  4. Read every pilot article side by side

    Content lead 2-3 days

    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.

  5. Click every link and load every asset

    Content engineer 1-2 days

    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
  6. Test search and permissions

    Content lead 1-2 days

    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.

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. 0/6

Objective All in-scope content live in Document360 with redirects serving and search engines informed.

  1. Load the full content set ahead of the switch

    Content engineer 1-2 weeks

    Run the full conversion and load into Document360, unpublished or on a staging domain. Content migration differs from data migration here: you can stage the whole thing before anyone sees it.

  2. Publish the runbook with the redirect step first-class

    Project manager 1 day

    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.

  3. Freeze editing and migrate the delta

    Content lead 2-4 hours

    Stop editing in Confluence, 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.

  4. Publish and verify permissions live

    Content lead 2-4 hours

    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
  5. Activate 301 redirects and submit the sitemap

    SEO / web 2-4 hours

    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.

  6. Repoint in-product and support links

    Content lead 1-2 days

    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. 0/6

Objective Verified content completeness, healthy redirects, and search traffic recovered to baseline.

  1. Reconcile content counts and assets

    Content engineer 1-2 days

    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 Confluence and Document360 record-for-record
  2. Crawl the new site for broken links and assets

    Content engineer 1-2 days

    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.

  3. Verify the redirects at scale

    SEO / web 1-2 days

    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.

  4. Monitor organic traffic and rankings for four to eight weeks

    SEO / web 4-8 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.

  5. Verify search, permissions and feedback loops

    Content lead 1-2 days

    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.

  6. Sign off and decommission on a delay

    Project sponsor 1 day

    Get acceptance against the Discovery criteria, keep Confluence available read-only until traffic has recovered, take a final export, and only then close the account.

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

Risk matrix

Per-object risk for this pair. Plan extra validation around anything marked high.

ObjectRiskNotes
Include/Excerpt Macros high Must inline referenced content — transclusion has no equivalent
Dynamic Macros (Jira, Chart) high No equivalent — must be replaced with static content or removed
Internal Links high All Confluence URLs break without a source-to-target ID map
Deep Page Hierarchy (7+ levels) high Hard ceiling — deeper pages must be flattened into articles
Page Version History high Cannot be migrated — Document360 has no backdating fields
Inline Comments high No migration path — stripped in all export methods
Inline Images medium Word export caps at 50 images; API extraction has no limit
Labels / Tags medium No automatic mapping — must be manually translated
Page Body Content low Text, headings, tables, and lists migrate cleanly via API
Code Blocks low Direct translation to Markdown fenced code blocks

The hard parts

What makes this specific migration difficult, beyond the mechanics.

Category Depth Limit

Document360 caps at 7 levels of nesting. Confluence page trees deeper than that must be flattened or restructured before migration.

Macro Translation

Confluence macros like Jira Issues, Draw.io, and include/excerpt-include have no Document360 equivalent and require custom conversion rules.

Image Cap on Export

Confluence Word export silently drops all images beyond the 50th on a page with no warning in the export log.

Internal Link Rewriting

Every Confluence URL must be remapped to a Document360 slug. Missing a single link means a 404 in your published knowledge base.

Dual API Rate Limits

Confluence and Document360 enforce independent rate limits. Migration scripts must handle 429s from both APIs simultaneously.

Tools used in this playbook

All free, all run entirely in your browser — nothing is uploaded.

FAQ

Is there a native Confluence to Document360 importer?

No. Document360 does not offer a direct API-to-API self-serve Confluence importer. Their public path is Word/PDF import plus a managed migration request, and the self-serve Word importer supports only .docx files under 30 MB — no HTML import. For high-fidelity migration, you need to use the Confluence and Document360 REST APIs directly.

Can I migrate Confluence macros to Document360?

Basic macros like code blocks, info/note/warning panels, and expand sections can be translated to HTML or Markdown equivalents. Dynamic macros (Jira Issues, Chart, third-party Marketplace macros) cannot be migrated as-is — they must be replaced with static content or removed. Include/excerpt-include macros require inlining the referenced content, which is a breaking change if your docs rely on transclusion.

What are Document360's API rate limits for migration?

Standard plans have no API access at all. Professional and Business plans allow 60 requests per minute per API token. Enterprise, Enterprise Plus, and Trial plans allow 100 requests per minute. Each GET, POST, PUT, or DELETE call counts as one request.

How deep can Document360 categories go?

Document360 supports up to 7 levels of categories: 1 root category plus 6 subcategory levels. If your Confluence page tree exceeds this depth, deeper pages must be flattened into articles at the 6th level or the hierarchy must be restructured before migration.

Does Confluence Word export lose images?

Yes. Atlassian hard-caps Word export at 50 images per page to prevent memory errors. Images beyond the 50th appear as empty boxes in the exported file with no warning. The API-based extraction method has no such limit.

Or skip all of this and let us handle it

Book a 30-minute call and we'll scope your migration in a single session.