Can you export everything from Document360 before the contract ends?
Yes for the core articles, but not for everything. The offline HTML site and the ZIP and JSON project exports carry your published article content, which is the part most teams need to rebuild elsewhere. Treat these exports as a copy of your content, not as a full record of the workspace. How each format handles structure, categories, metadata and language versions is set out in Document360's export documentation for your plan, and those details can change. Confirm the current formats, any size or item limits, and what your plan includes with Document360 and its support team, and ask for the answer in writing before you rely on it.
Three categories need separate handling. The exports leave out inline comments, so record any open discussion threads that matter before the contract ends. Attachments need their own inventory: list every file referenced by your articles in the Document360 interface, then download and store the files directly, and check which attachments the exports actually include. Private notes and content restricted to internal audiences need an owner decision for each item: keep, archive or delete. Ask Document360 to confirm exactly which of these appear in each export, because the answer determines how much manual work your migration needs.
Run a test export now, not in the final weeks of the notice period. Compare the article count against your Document360 workspace, then open a sample of pages to check links, images, tables and code blocks. Decide how the output maps to your target: books, chapters and pages in BookStack, spaces and pages in XWiki, or the page tree in Wiki.js. Confirm each import route with the platform's own documentation before you build a plan around it. Store a dated copy of every export and the written answers from Document360 with your contract records, so you can show what you took out and when.
Which Document360 exports are documented and what each one contains
This table lists the three export paths to check, plus the content types that often need manual work: comments, attachments, private notes, translations and who may run an export. Treat each row as a question to answer from the current Document360 documentation before you export. Run a test export from a non-production project and compare it with the live site before the contract ends.
| Export path | What it covers | Format and method | What to confirm before the contract ends |
|---|---|---|---|
| Offline HTML site | Published articles as browsable pages | HTML files opened from a local folder | How navigation, images and search behave offline |
| ZIP project export | Article content and project structure | Archive of project files | Folder layout and how images and links are referenced |
| JSON project export | Articles, categories and metadata | Structured JSON for scripted processing | Field names, body encoding and how categories map |
| Inline comments | Reviewer comments on article text | Not confirmed in the export paths above | Whether any export path includes them, and a manual copy plan |
| Attachments | Files linked from articles | Not confirmed in the export paths above | Whether files download separately and keep their links |
| Private notes | Internal-only notes on articles | Not confirmed in the export paths above | Whether they are excluded, and where to copy them by hand |
| Multilingual content | Translated versions of each article | Depends on the export path chosen | Whether every language is exported and how each is labeled |
| Who can run an export | Users with export rights | Set by role and plan permissions | Which roles and plan tiers can run each export path |
What the offline HTML, ZIP and JSON exports are each good for
The offline HTML export gives you a browsable copy of published content that opens in a web browser without a Document360 login. It suits a read-only reference archive for auditors, departing staff, or teams that need access to procedures during a cutover. Its main value is that people can read the content. It is a weaker source for importing into a wiki, because the reading experience is built for the browser and not for data transfer.
- Read-only archive: Keep a reference copy of published articles so that knowledge stays available after the subscription ends.
- Navigation as published: Check whether menus, categories and internal links still work in the copy, since these are what readers rely on.
- Metadata: Confirm which details such as authors, dates, tags and revision history appear in the pages, because a browser view may show less than the source system holds.
- Hosting: Serve the folder from an internal web server so the archive stays inside your network and under your access controls.
Open the export in a browser, follow several internal links and check an image-heavy article before you treat the copy as complete.
The ZIP export packages project content as a set of files that you can unpack, review and convert. Teams usually start here when they plan an import, because the files can be sorted and cleaned before anything reaches BookStack, XWiki or Wiki.js. Document360 defines the folder layout, file types and naming, so confirm them in its export documentation and in your sample rather than assuming a structure.
- Content files: Identify how article bodies are stored and which formats they use, since each target wiki accepts different import formats.
- Attachments and images: Confirm whether images and files referenced in articles are included in the archive and whether the references still resolve after unpacking.
- Hierarchy: Check how categories, article order and parent and child relationships are represented, because you will rebuild them as books, chapters, spaces or page trees.
- Exclusions: Record what the archive leaves out, such as inline comments, private notes or access settings, so you can recreate or accept each gap before the contract ends.
Unzip the file set into a separate working folder, compare the article list with the live project and open a sample of files against the published pages.
The JSON export carries project content as structured records, so scripts can read titles, identifiers, relationships and timestamps without parsing HTML. It suits teams that write a conversion script for BookStack, XWiki or Wiki.js, teams that need an inventory for an audit, and teams that must confirm every article has moved. Field names and object structure are defined by Document360, so take them from a real sample before you write any code that depends on them.
- Inventory: Build a list of every article with its status, category and last update to track migration progress and to find content that needs an owner.
- Conversion scripts: Map source fields to the target model, such as pages, books and chapters in BookStack or spaces and pages in XWiki, and test the mapping in a non-production instance first.
- Identifiers: Keep source article identifiers and URLs so that redirects and cross-references can be rebuilt after the move.
- Version drift: Record the export date and the field list, because a later export may use different field names or add new objects.
Validate the file with a JSON parser, run your script on a small sample and compare the output with the live article before you process the full set.
What Document360 exports leave out and how to recover it
The export gives you page bodies and structure, but several kinds of content sit outside them. Each card names one gap, a workaround that fits it, and the item to confirm with Document360 before you rely on the export. Settle these gaps while the account is still active.
Inline comments
Inline comments attached to specific sentences hold the review trail for many articles. Check whether the ZIP and JSON project exports carry them at all, and whether the offline HTML site shows them. If comments are excluded, ask Document360 whether they can be read through an admin console report or a documented API. If not, record the open threads before the contract ends and carry the unresolved ones into the new page's change notes by hand.
Attachments and embedded files
Files linked from articles, such as PDFs, spreadsheets and downloadable images, are the gap most likely to break pages after migration. Confirm whether the ZIP export includes the attachment binaries or only links back into Document360. Ask for a list of attachment URLs and file names, then download them from the admin console, or script the pull if an API documents file retrieval. Store the originals in your own object storage so migrated links still resolve.
Private notes
Private notes are the internal annotations authors keep on articles that readers never see. They may sit outside the content that the offline site renders. Confirm whether notes appear in the JSON project export, and in which field, before you assume they survive. If they are excluded, plan a manual pass with each article owner and decide in writing which notes move to the new wiki and which are discarded.
Access rules and visibility
Article visibility, role-based access and the split between internal and customer-facing content are the settings most often lost in a content export. Confirm which access settings, if any, appear in the project exports. Where they do not, rebuild the access model using the role and permission system of the target platform, and test it with one account per role before cutover. Record each rule in a table so the new permissions can be audited.
Templates, settings and redirects
Custom templates, reusable snippets and workspace settings are configuration rather than article text, so exports may omit them. Redirect mappings from old article addresses matter most, because customers, bookmarks and search engines still request those URLs. Ask Document360 which of these the export contains, including whether redirect mappings are included. Build a URL map from the published sitemap before cutover, and set redirects at the reverse proxy of the new platform.
How to run a complete export and verify it before the contract ends
This sequence turns Document360 content into a dated, checked archive that you can import into BookStack, XWiki or Wiki.js, with every excluded item accounted for before access ends.
Inventory the knowledge base and its languages
The content owner lists every project, category, article and language version in Document360, and separately lists drafts, private articles, attachments and any content shared through the knowledge base's access settings. Record the total article count per language in a spreadsheet. Done means the inventory total matches what the admin console reports for each project, and the content owner has signed off on it. Keep this sheet, because the later page count check depends on it.
Confirm export options and limits in the documentation
The platform administrator reads Document360's current export documentation and notes which formats are offered (offline HTML site, ZIP and JSON project exports), what each one contains, and any size or language limits. Ask Document360 in writing to confirm which items are excluded from each format, including inline comments, attachments and private notes. Done means a written list of formats and exclusions is filed with the inventory, and the knowledge base owner has signed off that nothing else is assumed.
Run a test export on one project
The platform administrator exports one representative project, ideally one with multiple languages, images, tables and internal links. Unzip the output into a folder outside any production system and open it in a browser and in a text editor. Done means the test archive opens, the page count for that project matches the inventory, and the team has recorded any broken images or missing files as known gaps to resolve before the full run.
Run the full export and store it with checksums
Run the complete export for every project and language listed in the inventory, then copy the files to storage that your organization controls. Generate a SHA-256 checksum for each archive with a command such as
sha256sumand store the checksum file next to the archive. Done means every archive has a matching checksum, and the security or IT lead has signed off on where the copies live and who can access them.Retrieve excluded items separately
Because the exports do not include inline comments, attachments or private notes, the content owner pulls each of these through the admin interface or the vendor's support channel, then saves them with the project they belong to. Keep a register that lists each excluded item, its source article, and where it is now stored. Done means every row in the register has a stored file or a documented decision to discard it, and the content owner signs off on the register.
Check the output against counts and a sample
Compare the page count in the full export with the inventory from step one, language by language. Then review a random sample of articles, including several with links, images and tables, and confirm they render correctly and the links resolve inside the archive. Record each mismatch. Done means the counts match or each difference is explained, and the content owner and a second reviewer have both signed the sample results.
Confirm the archive before the contract closes
Before the contract ends, the executive sponsor and the platform administrator confirm in writing that the archive, checksums and excluded-items register are complete and stored in an approved location. Keep a copy of the signed-off checklist with the contract file. Done means the signed checklist exists, and the team knows which archive will be the input for the import into BookStack, XWiki or Wiki.js.
Which exported content fits BookStack, XWiki or Wiki.js
BookStack organizes content in a fixed hierarchy: shelves group books, books contain chapters and chapters contain pages. Exported Document360 categories and articles will need to be mapped onto that hierarchy before import, so decide early whether top-level categories become shelves or books and whether subcategories become chapters. BookStack runs on PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later, and its official installation scripts cover Ubuntu 26.04, 24.04 and 22.04. Official Docker images are not published, so a container deployment relies on a community setup.
- Hierarchy: Plan a shelf, book, chapter and page map from the Document360 category tree before writing any import code.
- Editors: Pages can be written in the WYSIWYG editor or the optional Markdown editor, which helps when converting exported HTML or Markdown.
- Media: Images and attachments need to be uploaded into BookStack and their references rewritten to the new locations.
- Internal links: Links between exported articles will point to Document360 URLs and must be remapped to BookStack page addresses.
- Runtime: Confirm the PHP and database versions on your target OS before provisioning.
Confirm with BookStack, or with the community that maintains the import tooling you choose, whether any import path accepts Document360 output directly, since none is documented here.
XWiki organizes content in spaces containing pages, and its data model supports structured objects and applications for teams that need more than free text. A Document360 export usually maps to one space per knowledge base or category group, with nested pages beneath. The official Docker images come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, for amd64 and arm64v8. Three release lines are published: stable, long term support and an intermediate LTS, so choose a line that matches your upgrade cadence before you build the target.
- Spaces and pages: Map each exported category to a space and keep article hierarchy as parent pages, so navigation survives the move.
- Database choice: Pick MySQL, PostgreSQL or MariaDB to match your standard operations, since the Docker image variant follows that choice.
- Media: Attachments are carried as page attachments, and image references must be checked after import.
- Internal links: Rewrite links to XWiki page references, because exported URLs will not resolve on the new site.
- Import tooling: Confluence import tooling exists as a paid extension, but no Document360 import path is documented here, so confirm options with XWiki SAS.
Confirm the release line and database variant with your own support requirements before loading content.
Wiki.js organizes content as a flat tree of pages addressed by path, which makes it straightforward to keep Document360 category paths as URL structure. It needs a dedicated domain or subdomain because it cannot be mapped to a subfolder of another site, so plan the hostname before exporting. The stable 2.x line recommends PostgreSQL 9.5 or later and also supports MySQL 8.0 or later, MariaDB, MS SQL and SQLite. The PostgreSQL search module requires the pg_trgm extension, and Linux systems need at least 1 GB of RAM.
- Domain: Reserve a dedicated subdomain and confirm certificates and DNS before import.
- Database: Enable the pg_trgm extension on PostgreSQL if you want the built-in search module.
- Media: Store uploaded assets in the local store or in a supported storage module, and rewrite image paths to match.
- Internal links: Convert links to the new page paths, since Wiki.js relies on path-based addressing.
- Version: Use the stable 2.x line for production, because the 3.0 code in the main repository is marked beta and not for production use.
Confirm with the Wiki.js project whether any import tooling accepts Document360 output, and test the storage module you choose against your media volume.
Why the export plan has to start before the notice date
An export is a migration project with its own dependencies, and it should start well before any deadline in your Document360 contract. The export itself is the cheap part. Before you can run it, someone with the right role has to confirm that the export permissions are granted, and that the people doing the work can see every project, workspace and language version you need to move. Then the export has to be checked against what it actually contains, because the offline HTML site, the ZIP and JSON project exports, and the items they leave out, such as inline comments, attachments and private notes, are not the same thing. Each excluded item needs an owner, a decision on whether it is worth keeping, and staff time to rebuild it on the target platform.
Plan for three stages after the export runs: a test migration, a rebuild of the excluded items, and a parallel run in which readers and editors use both systems while you compare results. A test migration into BookStack, XWiki or Wiki.js will show broken links, lost page structure, image paths and permission gaps that a raw export hides. Ask your editors and admins to estimate, in writing, how many hours the rebuild and review will take, and confirm who approves the cutover. Each of these steps depends on the others, so a late start compresses all of them at once.
The exact notice period and the end date are set in your own agreement with Document360, not in this guide. Read the termination, notice and data return clauses, and confirm with your account contact in writing what export formats, timelines and support you are entitled to at the end of the term. Start the inventory early enough that you can compare each export with the target platform before the notice date, and keep the outcome of that comparison as a written record for the decision to proceed.
What to plan before the Document360 renewal or termination
Most of the export work is simple once the decisions are made. The cards below cover the contract terms, scope and ownership questions to settle with Document360 in writing before the renewal date or termination notice, so the export runs on a known timeline and nothing is lost in the handover.
Data return and deletion terms
Ask Document360 in writing what happens to your content, attachments, user records and analytics after termination, how long a copy remains available to you, and when deletion takes effect. Confirm whether the export formats you need are included in your contract or charged separately. Check whether the agreement says who may request a final export and in what format.
Export window and access end date
Ask for the exact date your login, API access and export functions stop, not only the subscription end date. Find out whether a read-only period exists and whether exports remain possible during it. Schedule a full export and a test restore several weeks before that date, because a final export run on the last day leaves no room to fix gaps.
Languages and translations to move
Document360 projects can hold several language versions of the same article. List every language, confirm whether each translation is exported with its source page, and decide which versions the new wiki needs on day one. Ask how language variants are represented in the ZIP and JSON project exports so you can map them to pages or books in your target tool.
Private and internal content
Identify which articles sit behind restricted access, internal-only workspaces or draft status, and ask Document360 whether exports include them with their visibility settings. Inline comments, private notes and attachments may be excluded from some formats, so request a written list of what each export leaves out. Plan a manual review for those items before the source access ends.
Ownership of the rebuild work
Decide who converts exported HTML or Markdown into pages, rebuilds navigation, restores permissions and checks links: your staff, a partner or the target tool vendor. Document the split of effort in a written scope before the export starts. Ask Document360 whether it offers any migration assistance and at what cost, since that answer changes the timeline.
Hosting and identity for the new wiki
Choose where the replacement will run and how users will sign in before the first import. BookStack needs PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later, while Wiki.js requires a dedicated domain or subdomain and cannot be mapped to a subfolder. Confirm that the chosen platform supports your identity provider and that the target environment is ready before the content arrives.
How much effort does exporting from Document360 take, and can our team do it alone?
Can our own team export everything from Document360 without outside help?
Often yes, for a small and simple knowledge base. The export itself is a set of administrator actions in Document360, so one or two people with admin rights can produce the offline HTML site, the ZIP and JSON project exports, and any attachments they can reach. The harder part is deciding what the export means for each article, checking that the output is complete, and rebuilding pages in the new platform. Teams with many languages, custom access rules or many editors usually find that the review work, not the export, takes most of the time. Confirm your admin roles and the export options your plan includes with Document360 before you plan the work.
What drives the cost and effort of a Document360 export and migration?
Effort rises with the size and complexity of what you publish. The main drivers are:
- Article count and depth of folder or category structure
- Number of languages and how translations are linked
- Attachments, embedded media and images that must move with each page
- Inline comments, private notes and draft content that the export may not carry across
- Access rules, customer-facing versus internal visibility and SSO
- Integrations and any AI or workflow features that stored content depends on
- How many editors must check converted pages before cutover
Each driver adds a separate block of work, so ask for the scope to list each one.
How long does it take to export and move content from Document360?
The duration depends on the same drivers as the cost, so no general figure applies. A knowledge base with a few hundred simple articles in one language is a very different job from a multilingual site with restricted pages and years of comments. Your timeline should cover export, inventory of what the export omits, conversion to the target format, review by content owners and a cutover window before the contract ends. Ask any provider to break the timeline into these phases and to name the dependencies, such as when editors are available to review.
What does our staff need to provide for an export project?
Plan for three roles. An administrator needs access to Document360 and the export options. Content owners must review converted articles, because formatting, links and images often need correction after conversion. A technical owner must host the target platform and decide on identity, backups and access. Someone must also confirm which content is current and which is retired, since moving stale pages wastes review time. Name these people before work starts so that review does not stall.
What does a fixed-scope export engagement from DeployOpen cover?
Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For an export project, the written scope would normally describe the source content to be exported, the target platform (BookStack, XWiki or Wiki.js), the conversion approach, the items that will not carry over, the review steps and the handover documentation. DeployOpen plans and implements the self-hosted platform inside your own infrastructure. Ask for the deliverables and exclusions in writing, so you can compare them with what you can do internally.
What should a written quote for exporting from Document360 include?
A useful quote separates one-time work from recurring costs. One-time items include the export, the inventory of omitted content, conversion, the migration of access rules and identity settings, reviews and cutover. Recurring items include hosting, backups, upgrades and support, which you can take in-house or buy as a retainer. Ask for each driver listed above to be priced or scoped separately, and ask what happens if your article count or language count changes after the quote. DeployOpen does not publish a price list, so the written scope is the basis for any figure.
Do we need outside help if we only want to move a small set of pages?
Probably not, if the pages are simple and you have people who can review them. A small move usually needs an export, a test import into the target platform and a short review by content owners. Outside help becomes more useful when the content includes restricted access rules, many languages, large attachment sets or integrations that other systems depend on. You can also ask for a fixed-scope review of an export you have already produced, which keeps the work narrow. Confirm the exact export files and the platform version with the target project before you begin.
How DeployOpen scopes and delivers an export and migration
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Document360 export, we start from a written scope that names which exports you hold, what they omit, and which target platform your pages will land on.
How we scope
- Inventory every Document360 project, language version and public or private article before any export runs
- Record which items the exports leave out, such as inline comments, attachments and private notes, and agree how each is recovered
- Agree the target platform, whether BookStack, XWiki or Wiki.js, and the deliverables in writing before work starts
How we build
- Run the HTML, ZIP and JSON exports and check their contents against the inventory, keeping a record of each run
- Convert and import pages into the target platform in a test environment, then compare structure, links and images with the source
- Configure identity sign-in, roles and permissions in your environment, and test them with representative accounts
How we hand over
- Deliver a migration report listing migrated, transformed and unrecovered items, with the reasons for each gap
- Document the runbook, the rollback steps and the decisions taken on content that could not be carried over
- Provide the export archives and checksums so you keep an offline copy of the source content for your records
How we support
- Engagements are fixed-scope, so changes after handover are agreed as a separate written scope
- Ongoing support, upgrades and continuous testing are available as a retainer for the self-hosted platform
- Ask us to confirm, in your written scope, the export window needed before your Document360 contract ends
