Migrate from Notion to Microsoft Project

Notion pages that function as project containers map to a Microsoft Project project node. We extract the page title as the project name and any top-level blocks (headings, descriptions) as project summary notes. Pages that are purely documentation with no database association are inventoried separately for manual SharePoint attachment because Project does not have a native rich-text document model.

Notion databases with a date or status property map to a flat or hierarchical task list in Project. Each database row becomes a Task row. The database's Title property maps to Task Name. Date properties map to Start and Finish if both are present; if only one date exists we set the other as Start plus a default one-day duration. Status (select) properties map to Custom Field dropdown values rather than native Task Status because Project's Status field is a fixed workflow (Complete, In Progress, Not Started) that does not support arbitrary select values.

Notion Relation properties link database rows across databases. We map these to Project custom fields (Text or Number type) carrying the related record's name or ID. If the destination Project is connected to a Project Online PWA site, the relation maps to a Lookup Table field for cross-project dependency reference. Rollup properties that aggregate related records (COUNT, SUM, average) are decomposed into individual values during migration and stored as separate custom fields because Project has no native rollup formula.

Notion status columns (commonly used as board/Kanban views) map to Project custom fields with the same option set. We preserve the color metadata from Notion as a separate Color custom field. Because Project does not support board-view rendering, the board layout is documented as a written view configuration for the customer's PMO to recreate in Project Online or Project for the web.

Notion People property values map to Microsoft Project Resources. If a single People property contains multiple assignees (multi-select), we create one Resource per person and assign them to the task individually. Resource names are resolved from Notion user display names. If the same person appears across multiple tasks we create a single Resource record and reuse it. Resource cost rates are set to $0 as a default because Notion does not store billing rates; the customer's PMO updates these post-migration.

Notion date properties map to Task Start and Finish fields. If a database has both a Start Date and a Due Date property, they map directly. If only a Due Date exists, we set Start to the Due Date minus the default duration (or minus one day for milestone tasks). Date-only values (no time component) are preserved as-is; Notion does not store time-of-day for date properties, so no time-zone conversion is required.

Notion number properties used for effort estimation (story points, hours, days) map to Project Number custom fields or to Duration if the customer confirms the number represents calendar duration. Budget amounts from Notion number fields map to Cost custom fields. We flag any number property used in a Notion rollup for manual review because the rollup logic does not migrate.

Notion URL properties migrate as Hyperlink custom fields on the Task. If the URL points to an external tool (Figma, GitHub, Google Drive), it is preserved as a live hyperlink. If it references another Notion page, we convert it to a SharePoint or external link at the customer's direction during scoping.

Notion formula properties (including rollups that use formula syntax) do not have a direct Project equivalent. Project supports outline-level rollup on Summary tasks but not cross-task formula fields. We extract the last computed value from the formula at migration time and store it as a static Number custom field. The customer's PMO rebuilds live formulas as Power Automate flows or Project macro calculations post-migration if dynamic recalculation is required.

Rich text blocks inside Notion task rows (paragraphs, headings, lists, code blocks, callouts, quotes) migrate as Task Notes in Project. We preserve inline formatting (bold, italic, code, links) as plain text with markdown notation for readability. Images and embeds in block content are extracted as file URLs and documented in an attachment inventory; actual file re-hosting happens to SharePoint or a cloud storage layer at the customer's direction. Toggle blocks are flattened to plain text because Project does not support collapsible content sections.

Notion database views (board, gallery, calendar, timeline, gantt) are extracted with their filter, sort, and group configurations. Microsoft Project does not support multiple simultaneous views per task list in the same way Notion does. We deliver a written view inventory documenting each Notion view's configuration and a recommended Project view equivalent (Gantt view, Task Sheet with grouping, or calendar view) for the customer to configure post-migration.

Notion templates are pages or database rows saved as reusable structures. Template content migrates as regular pages or databases. The 'use as template' metadata is Notion-specific and does not exist in Microsoft Project. We deliver a written template inventory listing each Notion template's name, type, and recommended Project equivalent (Project Template .mpt file or Project for the web template) for the customer's PMO to create post-migration.