Migrate your Notion data

The primary container object in Notion. Pages nest freely inside other pages and can hold an arbitrary number of block children. We traverse the full page tree recursively, preserving parent-child relationships and page-level properties like icon and cover image.

Databases are pages containing a structured table of rows. We extract all property schemas (title, rich_text, number, select, multi_select, date, people, files, checkbox, url, email, phone_number, relation, formula, rollup, etc.) and their current values per row. Schema parity is not guaranteed across platforms because Notion's property types are extensive and include formula outputs that may not translate.

Every visible element — paragraph, heading, list, callout, code block, image, embed, toggle, quote, table, divider — is a block with its own type and content. We extract all blocks with their formatting metadata and nested children arrays up to the API's 2-level-per-request depth limit, using follow-up append calls for deeper nesting.

Notion databases support over 20 property types including rollups, formulas, and relations. Custom property names and select/multi_select option sets vary by workspace. We map each property to the closest equivalent in the destination and flag any formula or relation chain that breaks across platform boundaries.

Notion databases support table, board (kanban), gallery, list, timeline, calendar, and gantt views. Each view stores its own filter, sort, and group configuration. We extract view configurations and apply them to the destination database where supported, noting that board and timeline views map most cleanly while gantt requires destination-specific handling.

Relations link records across databases; rollups aggregate data from related records. Both are first-class Notion concepts but require the linked databases to exist at the destination for full reconstruction. We detect relation chains during discovery and warn if cross-database links cannot be preserved in the target platform.

Notion workspaces contain full members, guests, and connections. User objects appear in created_by, last_edited_by, and people property fields. We extract user IDs and display names but note that user identity (avatars, emails) is workspace-scoped and may not map 1:1 in the destination.

Comments live in a separate endpoint from page content and reference specific block IDs. We extract comment text, author, and block association. If the destination lacks a comment-on-block model, we flatten comments to a dedicated section on the target page.

Notion retains page history: 7 days on Free, 30 days on Plus, 90 days on Business, unlimited on Enterprise. History is not accessible via API — only the current revision is exportable. We flag this limitation and recommend the customer export versions manually via the UI before migration if history preservation is required.

Files and images are hosted by Notion and referenced by URL in the block data. We extract the media URLs and re-host them in the destination or on a cloud storage layer. Notion's file upload limits are tier-dependent (unlimited on Plus and above), but the destination may impose its own limits.

Private teamspaces are available on Business and Enterprise plans. Each teamspace contains its own set of pages and databases with independent permission sets. We extract the full workspace tree including teamspace boundaries and replicate permission hierarchies where the destination supports workspace-level access control.

Notion templates are pages or database rows saved as reusable structures. We extract template content but note that the 'use as template' metadata is Notion-specific and may not translate to a template概念 in the destination platform.

Tags are implemented as multi_select or select property options within databases, or as inline page tags. We extract all option labels and their color metadata and map them to the destination's tagging system.