This guide walks you through a Slab-to-Slite migration in four straightforward steps.
Prepare the destination and preview the migration.
Run the bulk import.
Optionally enrich browser-only data and apply supported Slite fields.
Spot-check the result and switch over.
With Slab having no support, some of the following instructions might not stand the test of time. Contact support@slite.com if you encounter issues.
Before you start: how Slab maps to Slite
Slab topics contain posts and can contain subtopics. In Slite, destination channels must already exist. Each top-level Slab topic becomes a topic index Doc inside its mapped channel; subtopics and posts become nested Docs. Several top-level topics may share one destination channel.
Here is the structure the migration creates:
Slab workspace Slite workspace└─ Top-level Topic └─ Pre-created Channel├─ Post └─ Topic index Doc└─ Subtopic ├─ Post Doc└─ Post └─ Subtopic index Doc└─ Post Doc
The migration preserves this structure even when permissions cannot be reproduced exactly.
A Slab post can be draft or published. Both can be included when enabled and accessible to the Slab API account. Slite has no equivalent draft state, so an included Slab draft is imported as a regular Doc; archived posts retain their archived state.
Posts in more than one topic
Slab allows one post to belong to several topics, while a Slite Doc has one location. The tool imports the post once, chooses one deterministic destination, and adds a Doc card to every relevant topic index. It does not create duplicate Docs.
Step 1 — Prepare the migration
slab-to-slite-migration-customer.zip
23KB, Uploaded last month
Download the migration script above.
Create a Slab API token.Slab API access requires a Business or Enterprise plan.Make sure the Slab API account or Bot can access every topic you want to migrate, including secret topics.
Create a Slite API token for the destination workspace.
Create the destination Slite channels. Use the destinationChannels field in migration.config.json to map each top-level Slab topic ID to a channel ID. The first dry run can list the required mappings if you do not know the Slab topic IDs.
Follow the README to run the tool in dry-run mode first.
Step 2 — Run the bulk migration
The supplied tool reads your Slab data, converts it, and writes the supported data into Slite. Follow its README to approve the dry run and start the import.
The standard run handles all of the following whenever the Slab API account can access it:
- Current post titles and supported content: text, headings, lists, images by URL, separators, code, and tables
- Draft posts when enabled, imported as regular Slite Docs; archived posts when enabled, with archived state preserved
- Topic and subtopic hierarchy, represented as index Docs with native Doc cards
- Posts assigned to several topics, imported once with a card in each relevant topic index
- Users, groups, topic privacy, and membership metadata, recorded for matching and manual permission actions
- Source identifiers and Slab URLs needed for safe retries and matching
- Source owners and creation/update timestamps, retained in slab-export.json for reference rather than applied as native Slite ownership or timestamps
- Native Slab post mentions, comments, verification, direct shares, covers, and editing-history evidence are handled or reported during optional enrichment
- Remote media and unsupported embeds require validation; attachments are not downloaded and re-uploaded automatically
You do not need to choose an import format. The tool reads the Slab GraphQL API directly. Markdown-export and DOCX fallback inputs are not implemented, so a Slab API token is required. Supported Slab content is converted to SliteML before the Docs are created.
When the run finishes, keep these files:
- migration-report.json — counts, errors, warnings, and applied operations
- slab-to-slite-map.json — each Slab object matched to its Slite destination
- slab-export.json — source content and metadata retained from the Slab API
- permission-actions.json — topic permissions that require manual review
- needs-enrichment.json — a schema-v2 worklist containing every imported post and its browser-only fields; items in this file do not make enrichment mandatory
- assets/ — a reserved directory; the current tool does not download or re-upload assets
The source IDs and Slab URLs in the map let the next steps find the right source and destination doc without relying on titles. They also make retries update the mapped item instead of creating a duplicate.
Do not continue until the report shows that the bulk import completed and you have reviewed any failed items.
Step 3 — Complete optional enrichment
Use this step when you want to migrate or report browser-only information such as verification, comments, native Slab post mentions, direct shares, covers, and editing-history evidence. It also applies icons and colors to imported topic index Docs. Because needs-enrichment.json lists every imported post, the presence of items does not mean this step is mandatory.
In a browser already signed in to Slab, give Codex or Claude migration-output/needs-enrichment.json and the bundled prompts/01-export-slab-enrichment.md as inputs. The agent reads Slab without editing it and saves the result as migration-output/enrichment-manifest.json.
Validate the manifest:
npm run validate:enrichment
Review the manifest and correct any obvious identity mismatch.
Connect Codex or Claude to the destination workspace through the Slite MCP. Use the bundled prompts/02-import-slite-enrichment.md with enrichment-manifest.json, slab-export.json, and slab-to-slite-map.json as inputs.
Review migration-output/enrichment-report.json and complete every reported permission or cover action manually when required.
The prompts bundled in the ZIP are the source of truth. Do not copy a prompt from this guide: using the bundled files keeps the prompt and manifest schema aligned with the migration tool.
Run enrichment only after the bulk API import is final. A later bulk rerun replaces full Doc bodies and can remove inline comment anchors; if you rerun the bulk import, repeat enrichment afterward.
Icons and colors
The bundled Slite prompt chooses a supported
iconShape and iconColor for each top-level topic index Doc, keeps that color consistent across its descendant topic indexes, and leaves regular post Docs undecorated. It records the mapping for deterministic reruns and does not overwrite a clearly customized icon without approval. These styles apply to topic index Docs, not destination channels.The public Slite API and MCP do not set channel membership roles, per-Doc sharing overrides, document covers, original ownership, or original timestamps. Treat those results as manual actions or retained source evidence rather than completed native migrations.
Step 4 — Check and switch over
Use the reports and a small representative sample to confirm:
migration-report.json has no blocking errors. When enrichment is used, enrichment-report.json has no unexplained failed actions.
Representative public/private, draft/archived, media, native-link, verification, and comment cases behave as expected. Remember that included Slab drafts are regular Slite Docs.
A workspace admin has completed or assigned every manual permission and cover action, and private content has not become more widely accessible.
Once these checks pass, invite the remaining users, communicate the switch-over date, and keep the Slab workspace read-only until the final review is complete.
Known limitations
- Comments: The Slab browser enrichment can copy visible comment threads into native Slite threads. The Slite migration account remains the technical author; each copied comment includes a short source author/date line, so native authorship and timestamp fidelity are not preserved.
- Editing history: Slab exposes current content and a version number, not the historical snapshots needed to recreate native Slite revisions.
- Permissions: Topic permissions and direct shares can be recorded, but channel roles and per-doc sharing may require manual setup in Slite.
- Multiple topics: A Slab post with several topics is imported once under a deterministic destination, with a Doc card added to every relevant topic index.
- Historical metadata: Original owners and timestamps remain in slab-export.json and unsupported enrichment details remain in the enrichment report when they cannot be represented as native Slite fields.
- Drafts: Included Slab drafts become regular Slite Docs because Slite has no equivalent imported draft state.
- Covers and attachments: Covers are reported for manual recreation. Remote URLs are preserved where possible, but files are not downloaded and re-uploaded automatically.
- Input source: The current tool requires Slab API access; Markdown-export and DOCX fallback inputs are not implemented.