How to migrate from Slite to Docmost without losing the page tree
The move from Slite to Docmost is mainly an export, import and rebuild exercise, and permissions and internal links will need the most manual attention. Expect the imported content to arrive as a flat set of pages that you then reorganize into the page tree. In most organizations an internal platform or IT team runs the work, with a named content owner for each area who confirms that pages, links and access look right after the move. Effort depends on page count, attachments, integrations with other tools and the complexity of the permission model. The Slite export formats, options and any limits must be confirmed directly with Slite, because this guide does not cover them.
Start by confirming which export format Slite provides for channels and docs, then test one channel end to end before exporting everything. On the Docmost side, the import dialog accepts Markdown and HTML files, including inside a ZIP archive, and pages or whole spaces can be exported as Markdown or HTML, so keep a copy of your exported content as a fallback. Decide your target spaces first and map each Slite channel to one. Then rebuild the tree by moving pages under their parents. Internal links are the weakest point: links written against Slite addresses will usually still point to the old location, so build a sheet that maps each old address to its new page, and update the most used links first. The Docmost import and export documentation lists the supported formats.
Permissions must be re-created by hand, so inventory who can view and edit each Slite area before you build the Docmost spaces. Access is managed per space and through groups, and the paid edition adds page-level permissions, so decide whether space-level access is enough for each area. Assign access through groups wherever a team shares an area, which keeps the list shorter to maintain. Then check embeds and images on every migrated page. Docmost supports embeds from tools such as Airtable, Loom and Miro, and each embed still depends on its source, so test that it loads and that its access rules still apply. Open the image and attachment on each page to confirm it displays. Ask each content owner to review a sample of pages in their area and record sign-off before you retire the Slite workspace.
What maps from Slite to Docmost and what needs rework
This table compares common Slite capabilities with their Docmost counterparts, based on Docmost's README and documentation. Each row is marked clean, needs rework, or gap, so you can see what carries over directly and what you must rebuild or accept as a change. Confirm the Slite-side details against your own workspace and plan before you finalize the mapping.
| Slite capability | Docmost equivalent | Status |
|---|---|---|
| Documents and page content | Pages with real-time collaboration, page history and file attachments; Markdown and HTML import and export | Clean |
| Channels as organizing units | Spaces with permissions management; channels usually become spaces, and their membership must be rebuilt | Needs rework |
| Search across documents | Built-in page search; search inside PDF and DOCX attachments is a paid-edition feature | Needs rework |
| Page and space permissions | Spaces and groups in Community; page-level permissions are a paid-edition feature | Needs rework |
| Embeds from Airtable, Loom and Miro | Embed support listed in the README; check each embed URL and provider behavior after import | Needs rework |
| Diagrams and whiteboards | Draw.io, Excalidraw and Mermaid diagrams; Slite-native drawings typically need re-creation | Needs rework |
| Comments and page history | Comments and page history are listed in the README; confirm that imported pages keep prior versions | Clean |
| Single sign-on and MFA | Email and password, LDAP, SAML or OIDC and TOTP MFA; SAML, OIDC, LDAP and MFA are paid-edition features | Needs rework |
| Slite AI answers | No direct equivalent in the Community edition; the AI chat in Docmost is a paid-edition feature | Gap |
Which data moves, through which export path
A Slite move is really five separate transfers: document bodies, attachments, channel structure, people and access, and embedded content. Each has a different export path into Docmost, and each needs confirmation from Slite before the migration plan is fixed. The documented Docmost routes are Markdown and HTML files, including ZIP archives, and whole spaces exported as Markdown or HTML.
Document bodies as Markdown or HTML
Page text, headings, lists and tables are the core of the move. Docmost's import dialog accepts Markdown and HTML files, including inside a ZIP archive, so the first question for Slite is whether its export produces one of these formats with the page hierarchy intact. Ask Slite whether exports include every document or only the ones you select, and whether titles and nested structure survive. Test a small sample before a full run.
Attachments and inline images
Files and images referenced from documents are the most common point of loss in wiki moves. Confirm with Slite whether attachments are bundled with the export or only linked to hosted URLs, since links to a service you are leaving may stop working. Check whether image paths in exported Markdown or HTML still resolve after import. Plan a sample page review for images and file downloads on every space.
Channels mapped to Docmost spaces
Slite organizes content into channels, and Docmost organizes it into spaces with their own permissions and page trees. Decide before exporting whether each Slite channel becomes one Docmost space, and whether any channels should merge. Confirm with Slite whether an export preserves channel membership or only document content, because that determines how much of the access model you rebuild by hand.
Users, groups and access
Docmost's permissions, groups and page-level access must be set up again in the new instance, since document exports generally carry content rather than access rules. Ask Slite what user and group data it can export and in what format. Plan to map each Slite membership to a Docmost group before import, and check the access on sensitive spaces after the move. SSO and SCIM provisioning are Docmost paid-edition features, so confirm which ones you need.
Embeds, integrations and Word files
Embeds from tools such as Airtable, Loom or Miro may survive as links or may appear as raw markup, so test each type separately. Docmost's Word DOCX importer is a paid-edition feature, so plan a route for Word files if Slite exports them. Docmost's Confluence importer and Notion export ZIP import do not apply to a Slite export. Confirm with Slite whether it offers any API or connector for bulk export, because this migration path does not assume one.
Rebuilding the page tree, internal links and permissions in Docmost
Imported Markdown or HTML carries the text of your Slite docs, but it rarely carries the structure and links your team relies on. Internal links, image paths and the parent and child hierarchy must be checked after import and often repaired by hand. Treat the import as the start of a structural rebuild, not the finish. Before you run any import, write down the page tree you want in Docmost, with each parent page, its children and the space it belongs to.
Mapping Slite channels to Docmost spaces is a planning decision, not a technical default. A Slite channel may hold a mix of team notes, onboarding material and reference docs that will read better as separate spaces, or as one space with clear top-level pages. Decide this per channel, record the target space name and its owner, and check the result against how people search for content today. Confirm with Docmost's documentation and your own test import how the ZIP archive maps folders to pages, because that determines how much restructuring you do afterward. Re-creating permissions then happens through spaces and groups. Page-level permissions are listed in Docmost's documentation as a paid-edition feature, so decide whether you need them before you design the access model. The Community edition is licensed AGPL-3.0, while code under the ee directories is under the Docmost Enterprise license. Confirm which edition covers each feature you need before you plan permissions around it.
Run a link audit and an embed check as two separate tasks. The link audit compares internal links and image references in a sample of imported pages against the original Slite pages, and records which ones point to the wrong location or to a file that did not come across. The embed check is a different task: list every Airtable, Loom and Miro embed and every Draw.io or Mermaid block, then open each one in Docmost to confirm it renders and still points to the right source. Assign an owner to each task and record the failures in a tracker, so repairs are finished before users are moved to Docmost.
The migration sequence from inventory to Slite decommission
This five-step sequence moves Slite content into Docmost without losing pages, links or access rules, and ends with Slite closed only after readers have confirmed the new wiki works for them.
Inventory every channel, page and permission
Before any export, list each Slite channel with its page count, attachment volume, embedded tools such as Loom, Miro or Airtable, the owner of each channel and who can read or edit it. Record which internal links point between pages, because those links will need rebuilding in Docmost. Flag content that is out of date or duplicated so it can be archived instead of migrated. The output is a spreadsheet with one row per channel that names an owner and a target Docmost space, and a list of permission groups to recreate. You know this step is done when every channel has an owner who has confirmed the inventory row.
Install Docmost and run a pilot channel
Install Docmost with Docker, following the project's installation documentation. Use the compose template, which runs PostgreSQL 18 and Redis 8 images, set an APP_SECRET of at least 32 characters, and enable WebSockets on the reverse proxy so the real-time editor works. Check the current release tag on the Docmost GitHub tags page before pinning a version. Export one low-risk Slite channel as Markdown or HTML, import it into a test Docmost space, and rebuild its page tree and internal links. Ask five to ten real readers to find pages, open attachments and check embeds, then record what broke. The output is a short defect list and a go or no-go decision for the full move. Your internal team confirms the pilot when readers can complete their normal tasks without help.
Run Docmost in parallel with Slite
Keep Slite read-write while Docmost is loaded with the remaining channels in batches. Assign a named owner for each Docmost space who is responsible for the page tree, link repairs and the list of pages that still need attention. Recreate spaces, groups and page-level permissions in Docmost, and confirm that the permission model matches the inventory from step one. Track differences between the two systems in a shared log, including embeds that need re-linking and images that did not carry over. The output is a Docmost workspace that matches the inventory, with each space signed off by its owner. You know this step is done when every owner has signed off their space and the open defect list contains only items with a named fix.
Freeze Slite, do the final import and announce
Announce a freeze date to all readers, then stop edits in Slite for the channels being moved. Take a final export of each channel as Markdown or HTML, import it into Docmost, and run the same link and permission checks used in the pilot. Compare page counts and attachment counts between the two systems and resolve every gap before opening the new space to readers. Send a short announcement that states where content now lives, how to request access and which Slite URLs will stop accepting edits. The output is a Docmost space that passes the checks and a published switch notice. Confirm the cutover by asking each space owner to open their top pages in Docmost and verify that links and images work.
Decommission Slite after a read-only period
Keep Slite in read-only mode for a period your team sets with stakeholders, so readers can find anything the migration missed. Archive a full export of Slite content in a location your records policy covers, and store it with the inventory and defect logs. Before you cancel, read your Slite agreement to confirm the notice terms, auto-renewal conditions and any data return or deletion commitments, and ask Slite to confirm them in writing if the contract is unclear. Cancel the subscription only after the reader sign-off is recorded. The output is an archive, a closed decommission record and a confirmed cancellation date. Ask Slite for written confirmation of the final date on which your data is available or deleted.
How the Slite migration differs by team size and starting point
A small team with a limited number of channels and mostly text pages has the simplest move. The inventory is short enough to review by hand, and most pages will convert cleanly from Markdown or HTML export. The main work is checking that the page tree reads sensibly in Docmost and that internal links still resolve after import.
- Inventory: List every channel and its pages in a single sheet, marking which pages are current, which are stale and which can be dropped.
- Pilot scope: Import one channel first, then open its pages and confirm headings, lists, tables and links look correct.
- Permissions: Recreate a small set of spaces and groups by hand, since there are few owners to confirm.
- Links: Fix internal links manually where the export changed the target path.
Before cutover, ask a few users to find three or four pages they use often and confirm the content and search results match what they expect.
A mid-sized organization with many channels, heavy embeds and external sharing needs a structured inventory before any import. Embeds from third-party tools, images stored outside the page and shared links to external guests are the items most likely to break or need rework. Docmost's README lists embeds from tools such as Airtable, Loom and Miro, but each embed type should be tested rather than assumed to survive the move.
- Inventory: Record each channel, its owners, its embeds and every externally shared page, so each one has a named owner for verification.
- Pilot scope: Pilot with two or three channels that cover the main embed types and at least one external sharing case.
- Permissions: Map Slite sharing to Docmost spaces and groups before import, and decide which external access is still needed.
- Images: Check that images imported from Markdown or HTML still display, and re-upload any that do not.
Confirm with the vendor which embed providers still render in your Docmost version before you commit to a date for the full move.
A regulated organization that needs SSO, MFA and audit controls on the first day of operation faces a different sequence. Docmost's documentation lists SSO with SAML 2.0 or OIDC, LDAP, SCIM provisioning, MFA and page-level permissions as paid-edition features, and lists audit logs on the Enterprise tier. Those controls should be in place before users are invited, not added after the import.
- Edition decision: Confirm with Docmost which edition provides each control your policy requires before planning the import.
- Inventory: Classify each channel by data sensitivity, since regulated content may need stricter spaces or an exclusion from the first wave.
- Pilot scope: Run the pilot with SSO and MFA enforced, so access tests reflect production conditions.
- Permissions: Rebuild access from your identity groups rather than copying Slite sharing, and record who approved each space.
- Evidence: Keep the export files, import logs and access review records together for your compliance assessor.
DeployOpen prepares controls and evidence for assessments, but independent auditors issue any audit report, so confirm the evidence requirements with your assessor first.
A team that wants to keep Slite as a reference archive after the move has a different goal from a full cutover. The aim is to move active content to Docmost while retaining older material in a read-only form. The export step matters more here because the archive must remain usable after the subscription changes, so the team should decide early what the archive is for.
- Inventory: Split channels into active, reference and retire groups, and assign an owner to each group.
- Pilot scope: Migrate only the active group first, so the archive does not block the first wave.
- Permissions: Keep archive access limited to people who need historical records, and record that decision.
- Format: Export archived content as HTML or Markdown files so it stays readable without Slite.
- Links: Add a note in Docmost pointing readers to the archive location for any page that was not moved.
Ask Slite what export options and data retention terms apply to your plan before you rely on the archive, and test that the exported files open correctly.
What drives the cost and duration of the Slite to Docmost move
This table lists the factors that change the effort of moving Slite content into Docmost, with a note on how to keep each one manageable. Read it as a checklist for the inventory you should complete before asking for a fixed-scope quote, because the largest effort usually comes from links, permissions and rebuilt embeds rather than from raw page count.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Page and attachment volume | Every page and file must be exported, imported and checked. Large attachment sets increase transfer time and storage sizing for Docmost's local or S3-compatible file storage. | Archive stale channels before export, sort content into keep, migrate and retire groups, and confirm the storage backend before the first test import. |
| Number of channels and their owners | Slite organizes content in channels, which must be mapped to Docmost spaces. Each channel needs an owner who signs off on structure and content. | Map channels to spaces in a written table, limit the number of spaces, and name one approver per space so review does not stall. |
| Embeds and diagrams needing re-creation | Embeds from third-party tools may not survive export as working links, and diagrams may need rebuilding in Docmost's Draw.io, Excalidraw or Mermaid support. | Inventory every embed and diagram, decide whether to keep, convert or retire each one, and test a sample page before scaling. |
| Permission complexity | Page-level permissions and groups must be rebuilt by hand because an export does not carry them over. Page-level permissions are a paid-edition feature in Docmost. | Document the current access model, reduce it to space-level groups where possible, and confirm early whether page-level permissions are required. |
| SSO and MFA requirements | SAML 2.0 or OIDC, LDAP, SCIM and MFA are listed as paid-edition features, so identity integration changes the edition and the setup work. | Decide the identity source before installation, confirm which edition covers each requirement, and budget the integration as a separate work item. |
| Link density | Internal links are not automatically reconnected when pages move. Dense cross-referencing means many links to check, rewrite and test. | Export a list of internal links, prioritize pages that are most linked, and keep a link-check report as an acceptance step. |
| Integrations to rebuild | Slite integrations, bots and automations do not move with the content. Each one needs a replacement or a decision to drop it. | List every connected tool and its owner, mark each as replace, rebuild or retire, and exclude retired items from the quote scope. |
| Hosting, PostgreSQL and Redis operations | Docmost's Docker template runs PostgreSQL and Redis, and the real-time editor needs WebSockets through the reverse proxy. These are recurring operating tasks. | Use your existing hosting standards, confirm who runs patching and backups, and ask the implementer to document the runbook. |
| Internal review time | Content owners must confirm that migrated pages are accurate. Review often takes longer than the technical import and depends on how many people are available. | Schedule reviewers before the migration starts, sample pages by owner, and agree in writing what counts as acceptance. |
What usually goes wrong when moving from Slite to Docmost
Most problems in a Slite to Docmost move appear after import, not during it. The risks below cluster around links and content integrity, access control, and the self-hosted stack that serves the wiki after cutover. Each card names the check to run at the step where it is cheapest to fix.
Broken internal links and image paths
Links between Slite docs and image references often point at Slite URLs or relative paths that do not resolve once pages land in Docmost spaces. Import a pilot space first, then click a sample of cross-linked pages and confirm every image renders. Build a list of link patterns from the export and fix them in a single pass before the full import, so the page tree and cross-references are rebuilt once rather than patched page by page.
Permissions flattened during re-creation
Slite channel membership and per-doc access do not travel as a set of rules that Docmost reproduces automatically. Map each Slite channel to a Docmost space, then recreate space members and groups, and decide which pages need stricter page-level restrictions. Ask whether a restricted page in Slite is still restricted after import, and test with a non-admin account from each group before users receive access.
Embeds that do not render as expected
Docmost supports embeds from tools such as Airtable, Loom and Miro, and diagrams in Draw.io, Excalidraw and Mermaid. Some embeds exported from Slite may appear as plain links or static text, and third-party frames may be blocked by your browser or proxy policy. Inventory every embed type in the export, open each one in the target environment, and rebuild unsupported diagrams as Mermaid or Excalidraw before cutover.
Attachments left behind in the export
A Markdown or HTML export carries text and often references to files, but attachments may be missing, renamed, or stored separately from the page. Compare the attachment count in Slite with files present in the Docmost workspace after each import batch. Decide whether file storage stays local or moves to S3-compatible storage before the import, because moving files later changes every reference and adds a second verification pass.
Stale content read after cutover
If Slite stays writable while teams begin using Docmost, edits made in Slite after the export silently fail to appear in the new wiki. Set a freeze date, announce it, and make Slite read-only or add a banner pointing to the new location. Plan a delta export for the final days, and confirm the last-modified dates on migrated pages match the freeze point before you retire the old workspace.
Underprovisioned self-hosted stack
Docmost's Docker template runs PostgreSQL 18 and Redis 8, requires an APP_SECRET of at least 32 characters, and needs WebSockets enabled on any reverse proxy for the real-time editor. A missing WebSocket upgrade shows as editing that fails silently, and a weak or reused APP_SECRET weakens sessions. Before the pilot, confirm WebSocket headers on your proxy, generate a unique secret, and restore a test copy of both PostgreSQL and file storage to prove backups work.
Questions teams ask before moving from Slite to Docmost
Can we import our Slite content into Docmost directly?
Probably yes, but confirm the export format with Slite first, because that determines the import path. Docmost's import dialog accepts Markdown and HTML files, including inside a ZIP archive, and it also accepts Word DOCX files. Pages and whole spaces can be exported from Docmost as Markdown or HTML, which gives you a working format for checking the result. Slite does not have a native Docmost importer, so the realistic path is an export from Slite into files, a restructuring pass to match Docmost spaces, and an import followed by a review of every page. Plan for the parts that do not survive conversion cleanly, such as custom blocks, nested layouts and images stored under expiring links. Ask Slite's support team which export formats your workspace can produce, then test the import on one channel before committing to the full set.
How long does a Slite to Docmost migration take?
The duration depends mainly on the inventory: how many channels, documents and attachments you have, how deep the page tree goes, and how many internal links and embeds need manual correction. A small workspace with clean Markdown-friendly content is a very different job from a large one with years of unstructured pages. The most reliable way to size the work is an inventory pass that counts pages per channel, flags embeds from third-party tools, and lists which pages link to which. Ask any implementation partner to base its written scope and timeline on that inventory rather than on a generic estimate. Schedule a parallel run in which both tools are available so that teams can verify content before the cut-over date.
What do we need to provide from our side?
You need a named owner for each space, a complete inventory of what lives in Slite, access to the infrastructure where Docmost will run, and decisions on permissions and single sign-on before import begins. Space owners decide what is current, what should be archived and how the page tree should look after the move. Your infrastructure team provides a host or cloud account, a reverse proxy with WebSockets enabled for the real-time editor, and storage for attachments. Security and identity teams decide whether the Community edition with email and password is acceptable or whether LDAP, SAML or OIDC login is required, since those authentication methods appear in Docmost's paid editions. Records of who can see which content should also be written down, because permissions are re-created by hand in Docmost rather than copied automatically.
Can our own team run the migration without outside help?
Yes, if your team can run Docker, operate a PostgreSQL and Redis pair, configure a reverse proxy and carry out structured content checks. Docmost's installation documentation describes a Docker compose template that runs PostgreSQL 18 and Redis 8 images and requires an APP_SECRET of at least 32 characters, so the installation itself is a manageable task for a platform team. The harder work is verification: opening sample pages from every space, confirming that the page tree and internal links resolve, checking that embeds from tools such as Loom or Miro still display, and confirming that images load after the move. Assign that verification to named people with a checklist, and keep a list of anything that needs rework. Internal teams that lack this capacity often find that the content review, not the software setup, sets the pace.
What does Docmost cost to run after the migration?
The Community edition is free to self-host under AGPL-3.0, so the licence itself has no fee. Docmost's pricing page lists a Business plan at $6 per seat per month billed annually with a 10-seat minimum, and Enterprise is priced by quote and adds SCIM, audit logs, SIEM integration and a page verification workflow. Costs that remain regardless of licence choice include the servers or cloud accounts that run Docmost, PostgreSQL and Redis, storage for attachments (local by default, with S3-compatible or Azure Blob storage as options), backups, monitoring and staff time for upgrades. Compare these with your current Slite plan, which is priced per user with SSO on Pro and SCIM on Enterprise. Ask any provider for a written breakdown of one-time and recurring items, and confirm which features you need before choosing a licence tier.
When should we bring in an outside partner for the move?
Bring in an outside partner when permissions, single sign-on and audit requirements are strict, or when the page count is large enough that manual review cannot finish on time. Regulated teams often need evidence that access was re-created correctly, that SSO and multi-factor authentication are enforced, and that content was moved without loss. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. DeployOpen also prepares systems and evidence for compliance assessments, but it does not issue audit reports or certifications, which independent auditors provide. Ask for a written scope that names the inventory, the permission model, the verification checklist and the handover.
Which Docmost features need a paid edition before we switch?
Several features that teams commonly rely on are paid-edition features, so confirm them before you commit to a licence. Docmost's documentation lists page-level permissions, SSO with SAML 2.0 or OIDC, LDAP, SCIM provisioning, MFA, page verification with approval, the REST API with personal keys, search inside PDF and DOCX attachments, and the Confluence, DOCX and PDF importers as paid-edition features. The Community edition still includes real-time collaboration, spaces, groups, comments, page history, search and file attachments, along with email and password, LDAP, SAML or OIDC single sign-on and TOTP multi-factor authentication as listed in the documentation. Check the current feature list on the pricing page and the documentation, because editions change, and map each feature you rely on in Slite to the edition that provides it.
How DeployOpen scopes and runs a Slite to Docmost migration
DeployOpen treats a Slite to Docmost move as a fixed-scope engagement inside your own infrastructure. We agree the content inventory, permission model and deliverables in writing before any export or import starts, then build, test and document the target Docmost instance for your team.
How we scope
- Inventory Slite channels, docs, nested pages, attachments and embeds to set the migration boundary
- Map Slite groups and access levels to Docmost spaces, groups and page-level permissions in writing
- Agree which content moves, which is archived and which is retired before any export begins
How we build
- Deploy Docmost in your environment using the Docker installation path and its PostgreSQL and Redis images
- Run test imports of Markdown or HTML ZIP archives into a staging space and review the rebuilt page tree
- Rewrite internal links, check embeds and images, and confirm permissions against the approved mapping
How we hand over
- Provide a written record of the content mapping, import steps, exceptions and known gaps
- Document administration tasks for spaces, groups, authentication and backups in Docmost
- Walk your administrators and content owners through verification checks before cutover
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing first
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Ask any quote to itemize scope, environment work, post-migration support and paid Docmost edition needs
