Migrate from Notion to monday Work Management

Notion pages become monday.com boards. Each top-level Notion page (or workspace-level database root) creates a separate board in the destination workspace. The page title maps to the board name; the page icon maps as the board emoji if present. We extract page-level properties (status, owner, due date if configured as page properties) and apply them as column values after board creation. Pages nested more than two levels deep are flattened into groups or sub-items inside the parent-page board to respect monday.com's flat item hierarchy.

Notion databases are extracted with their full property schema and mapped to monday.com boards with corresponding column types. Notion text properties map to Text columns; select maps to Dropdown; multi_select maps to Tags; date maps to Date; number maps to Number; checkbox maps to Checkbox; url maps to Link; email maps to Email; phone_number maps to Phone; person maps to People. Select option labels and colors are re-created as Dropdown or Tags options at the destination.

Each row in a Notion database becomes a monday.com item. The item name is set from the database row's title property. All other property values map to their corresponding monday.com column values by type. Item group assignment is derived from the Notion database view configuration: if the source view groups by a select or person property, we create groups matching those values in the destination board. Items are created in batches using the monday.com Items mutation with batch sizing to stay within per-request limits.

Inline block content is extracted from the Notion block tree and mapped to column values or item update text. Paragraphs, headings, and list items within a Notion page that are not part of a database row are mapped to a dedicated rich-text column on the corresponding board item (derived from the page title). Bold, italic, code, and hyperlink formatting are preserved as inline markdown where supported by the monday.com column. Content exceeding 500 characters in a single text block is split across multiple text columns to respect monday.com's column character limits.

Callout blocks (Notion's icon + text container) and toggle blocks (expandable content) are converted to monday.com Item updates with a formatted header for callouts. Quote blocks become italicized updates. Toggle blocks with children are flattened: the toggle label becomes a sub-item title, and children become sub-item updates. This preserves the content hierarchy in a monday.com-native representation without requiring manual expansion.

Code blocks migrate as text updates with a language label prepended (e.g., 'Python: ...'). Images are extracted from the Notion-hosted URL, uploaded to monday.com file hosting, and set as a File column value on the item. External embeds (YouTube, Figma, Loom) are captured as a Link column value with the original URL preserved; the embedded content itself is not re-hosted. We flag any block referencing an unsupported file type for manual handling.

Tables are extracted as text updates with pipe-delimited column headers and rows to preserve tabular structure. Dividers become line-break separators in updates. Bookmarks are converted to Link column values with the page title as the link label and the URL as the target. Notion table-of-contents blocks are not migrated.

Notion database views (table, board/kanban, gallery, list, timeline, calendar) are mapped to monday.com view types where a direct equivalent exists. Kanban view maps to monday.com's Board view grouped by the same property. Timeline view maps to monday.com's Timeline view using the source date columns. Table view maps to monday.com's Table view directly. Gallery, calendar, and gantt views have no direct monday.com equivalent and are converted to the closest available view (Gallery to Board, Calendar to Calendar view, gantt to Timeline) with a note in the migration report.

Notion cross-database relations link records between two databases. In monday.com, this maps to linked item integrations (where both boards exist in the same workspace) or to cross-board item links via the Connect Boards feature. We create the linked-item pairs during migration and document the mapping so the customer's admin can verify the connections post-migration. Rollup fields (which aggregate data from related records) have no monday.com equivalent and are flagged in the migration report with a recommendation to use monday.com's Dashboard widgets or formula columns to approximate the calculation.

Notion formula properties calculate values from other column data within the same database. monday.com supports formula columns only on the Pro plan ($19/seat/month). During scoping, we identify every Notion database that contains a formula property and determine whether the destination workspace is on Pro. If on Standard or below, we flag each formula as a gap and provide a written formula equivalent in monday.com's syntax for the admin to recreate post-migration. Formulas referencing relation fields cannot be rebuilt without restructuring the data model.

Notion comments live on a separate API endpoint and reference specific block IDs. We extract the comment text, author display name, and block association. In monday.com, comments on items are represented as Updates. Each Notion comment becomes an Update on the corresponding item with the comment body and author name. Thread replies are preserved as replies to the same update. Mentions in comments (e.g., @user) are captured as plain-text references rather than active user pings since the mention targets a Notion user who may not exist in the monday.com workspace.

Notion-hosted files are referenced by URL in the block data. We extract the media URLs, download the file content, and re-upload to monday.com's file hosting as a File column value on the item. Externally hosted files (Google Drive, Dropbox, S3) are preserved as Link column values. Notion's per-file upload limit is applied during extraction; files exceeding the limit are flagged for manual download before migration begins.

Notion private teamspaces (Business and Enterprise) are extracted with their contained pages and databases. Each teamspace becomes a separate monday.com workspace in the destination account. If the destination monday.com account does not have sufficient workspace seats to match the teamspace member count, we map teamspace members to board subscribers on the created boards instead. The teamspace hierarchy (nested pages within pages) is flattened as described in the Page-to-Board mapping entry.

Notion templates (pages saved as reusable structures) contain block tree content that we extract and migrate as regular boards. The 'use as template' metadata is Notion-specific and does not have a direct monday.com equivalent. We deliver a template-usage inventory as part of the migration report, listing every template and the number of times it was used in the source workspace, so the admin can create monday.com board templates as a post-migration step.

Tags in Notion are implemented as multi_select or select property options within databases, or as inline page-level tags. We extract all option labels and their color metadata and map them to monday.com Tags column options. Tags used across multiple databases are reconciled: if the same tag label appears in multiple Notion databases, we create a single Tags option in the destination with a note on its multi-database origin.