Migrating from Notion: pages and databases

Create a rollback point

• Keep the original Notion workspace unchanged during migration.
• Record the export date and workspace name in a migration log.
• Download one complete export and store the untouched ZIP separately from the working copy.
• Perform the first migration into a new Kition vault rather than your production vault.
• For team workspaces, choose one person to run the export so permissions and duplicate partial exports do not create conflicting sources.

Export from Notion

In Notion, open Settings, choose the workspace export option, and select Markdown & CSV. Enable Include subpages so nested content is included. Notion produces a ZIP containing Markdown files for pages, CSV files for databases, folders for nested pages, and copied attachments where export permissions allow them.

Large workspaces can take time to prepare. Do not start editing the exported files until Notion has finished and you have preserved the original ZIP. If the export is unexpectedly small, check whether guest pages, private pages, or externally owned content were omitted.

Stage the exported folder

• Unzip into a temporary migration directory and keep the original ZIP read-only.
• Remove obvious trash such as duplicate exports and empty placeholder pages.
• Choose a stable top-level structure such as Inbox/, Projects/, Areas/, Resources/, and Archive/ before moving hundreds of files.
• Avoid mass-renaming files on the first pass. Notion-generated names and identifiers are unattractive, but they help preserve relative links while you validate the import.
• Open the staged directory in a text editor and inspect several Markdown files before opening it as a Kition vault.

Import pages as Markdown documents

Open the staged directory as a new Kition vault. Standard headings, paragraphs, lists, links, images, code blocks, and basic formatting should remain readable because the export is Markdown. Kition does not need to translate those pages into a proprietary block format.

Notion often writes internal links as relative Markdown links whose filenames include generated identifiers. Preserve them through the first verification pass. After confirming that linked pages open correctly, rename high-value pages gradually and update links in the same change. Git is useful here because every rename and link repair becomes reviewable.

Import databases as Kition tables

Each exported database normally includes a CSV representation. In Kition, create a table and use the CSV import flow described in Import CSV. Review the preview instead of accepting inferred field types automatically.

• Map titles and long descriptions to text or rich-text fields.
• Map status, type, and category columns to select fields after checking the distinct values.
• Map tags to multi-select fields and normalize inconsistent capitalization before import.
• Map dates only after confirming timezone and date-format interpretation.
• Keep Notion page IDs in a temporary source-ID column until verification is complete.
• Import attachments separately when the CSV contains file references rather than the files themselves.

What does not migrate one-to-one

A Markdown-and-CSV export preserves content better than behavior. Linked database views are view configuration, not independent datasets. Notion relations and rollups depend on internal object identifiers. Formulas may use functions with no direct equivalent. Buttons, automations, comments, page history, workspace permissions, and external integrations are not portable through a normal export.

Rebuild only the behavior that the team still uses. A linked database can become an embedded Kition table view. A relation can become a link field or a stable source ID. A formula should be re-created and checked against sample rows. Comments that contain decisions should be promoted into the document body before export rather than treated as durable content.

Handle attachments deliberately

Open a sample of images, PDFs, and other attachments from inside the imported documents. Check that relative paths resolve on both macOS and Windows if the vault is shared across platforms. Keep attachment filenames unchanged until links work; cosmetic cleanup comes after correctness.

For a large media library, decide whether every binary belongs in the vault. Git works well for Markdown but poorly for large videos and archives unless Git LFS or another storage strategy is used. Document that choice before teammates start syncing the new vault.

Verification checklist

• Compare page and database counts with the migration inventory, allowing for intentionally excluded archives.
• Open at least ten representative documents, including deeply nested pages and pages with attachments.
• Follow internal links in both directions and search for unresolved Notion URLs or missing files.
• Compare row counts and several important records for every migrated database.
• Test select values, multi-select values, dates, formulas, and attachment fields rather than checking only titles.
• Ask the real owner of each workflow to complete one normal task in the migrated vault.
• Keep the Notion workspace available until the team has completed an agreed verification window.

After the migration

Once the vault is verified, put it under the backup or synchronization system your team actually owns. Then document the folder structure, table conventions, provider configuration, and any rebuilt workflows. Avoid turning the first migration into a simultaneous redesign of every process; stabilize the data first, then improve the system in smaller reviewed changes.

Continue with Create your first vault, the data tables feature overview, and the detailed Kition vs Notion comparison. Those pages explain the target model and the tradeoffs that remain after the files have moved.