“How to Migrate From Notion to a Project Management Tool”

What actually transfers when you leave Notion?

migrate from Notion is a key topic in modern project management and teamwork. Data moves; behaviour does not. A Notion database is two things stacked on top of each other: rows with properties, and views that decide which rows you see and in what shape. The export writes the first and drops the second.

In practice, titles, text, numbers, dates, checkboxes and select values survive as columns. Board layouts, calendar views, gallery covers, filters, sorts, grouped views and formulas arrive as either nothing or as a frozen value captured at export time. Notion’s own help centre is clear on three points: a database export carries only the current or default view, form views cannot be exported at all, and a CSV re-import creates a new table without relations, rollups or formulas.

That has a direct consequence for planning. Treat the migration as a rebuild with imported seed data. Teams that plan for a rebuild finish in two weeks. Teams that expect a transfer spend two weeks debugging an import that was never going to be complete, and then start the rebuild anyway, two weeks late.

There is a second, quieter loss: the workspace’s social layer. Comments, page history, permissions and the small conventions a team builds over a year — who tags whom, which property means “blocked”, why one column is called Owner 2 — none of that is in the file. Write down the conventions before you export, because you will be asked about them in week two.

Which export format should you use for what?

Three formats, three jobs. Using one format for everything is why so many migrations end with a folder of HTML nobody opens and a CSV nobody trusts.

Two rules make the table usable. First, switch each database’s current view to an unfiltered, unsorted table before exporting; otherwise the CSV contains only the rows that view happened to show, and you will discover the missing 200 rows after you have cancelled the subscription. Second, add a formula property that outputs the row’s unique ID, so every CSV row carries a key you can match relations against later. That one column costs five minutes and saves days.

Export twice: once as Markdown & CSV for the import, once as HTML for the archive. Comments only survive in the HTML copy, and the archive is what you will search when someone asks why a decision was made in March.

How do you map Notion databases to tasks and projects?

Map by shape, not by name. A database whose rows represent units of work becomes a task list. A database whose rows represent containers — an engagement, a build, a campaign — becomes a project. A database whose rows are reference material becomes a document folder, not a task list.

The mapping most teams settle on looks like this:

• Tasks database → tasks. Title, status, due date, assignee, priority. Drop any property with fewer than five filled values; it is decoration.
• Projects database → projects. One project per active engagement, and archive the other forty instead of importing them.
• Relation columns → parent links. The “Project” relation on a task is the most valuable column in the export, because it is what turns a flat list into a hierarchy.
• Sub-items and checklists → sub-tasks. Flatten nested pages by one level. Deep nesting is where imports fail quietly.
• Select properties → status or labels. Single selects usually map one to one; multi-selects usually become tags.
• People property → assignee. Invite real accounts first, then import, or you will be matching names by hand.

Two mistakes account for most cleanup work. The first is importing every historical row, which buries this quarter’s work under three years of finished items and makes the new tool feel worse than the old one on day one. The second is importing people who have left, which produces an assignee list full of ghosts and a round of manual editing nobody scheduled.

A useful constraint: if a database has never been filtered by anyone in the last month, it is probably a document, not a workflow. Import it as a page and move on.

What breaks, and how do you plan for it?

Every migration breaks the same six things. Knowing them in advance turns surprises into a checklist.

Relations deserve the extra sentence. When a task CSV says “Website relaunch” in its project column, it says exactly the same thing for the four projects with similar names, and nothing connects the row to a project record. If you exported a unique ID for every project row and kept it in the task CSV, the rebuild becomes a lookup instead of an afternoon of guessing.

There is also a data-hygiene problem nobody warns about: duplicate titles. Notion tolerates two pages with identical names in the same database, and imports do not. Run a duplicate check before importing, not after, because merging duplicates inside a new tool is slower and destroys comment threads.

How long does the cutover actually take?

Longer than the import dialog suggests, and shorter than most teams fear. The work splits into three blocks: preparation, import, and rebuild.

A realistic model for a 25-person team with four databases and 1,200 open items:

• Preparation: 6–10 hours. Exporting, adding ID columns, resetting views, writing down formulas and permissions.
• Import and cleanup: 4–6 hours. Column mapping, date formats, duplicate titles, re-inviting people, fixing the assignee list.
• Rebuild: 8–14 hours. Statuses, views, one automation, templates, and the project hierarchy.

That is 18–30 hours of one person’s time, or roughly $1,000–$1,650 at a $55 loaded hourly rate. Compare it with the licence: 25 seats at $10 a seat is $3,000 a year. The migration costs about half a year of the subscription, once. That framing is worth putting in front of the manager who asks why the switch takes three weeks.

A smaller example: a six-person studio with one task database and 180 open items spends three hours on export and cleanup, and four hours on rebuild. Seven hours, one working day, roughly $385 of internal cost.

The number most teams forget is the productivity dip. Assume two weeks at 10–15% reduced throughput during the parallel run. For 25 people billing 25 hours a week each at $55, that is 25 × 2 × 2.5 hours ≈ 125 hours, or about $6,875 of soft cost. It never appears on an invoice and it absolutely appears in a quarter’s revenue.

Scale the plan, not the panic: a two-person team with one database should spend a morning, not a sprint, and should not read the rest of this section twice.

Should you move everything, or split Notion and the PM tool?

For many teams the honest answer is a split, and it is not a failure. Notion is excellent at long-form knowledge: specs, meeting notes, onboarding docs, a company wiki. It is mediocre at work with an owner, a due date, and a state that changes five times a week. Those are different jobs, and one tool rarely does both well.

Three patterns work in practice.

Full migration. Every database becomes a project in the new tool and Notion is archived. Cleanest long term, most work up front, and the right choice when the workspace is mostly task data rather than prose.

Split by object. Tasks and projects move; documents and the wiki stay. This is the most common outcome and usually the correct one. It costs an extra system to maintain, so it needs a written rule about what belongs where.

Split by team. Engineering moves to a dependency-aware tool, marketing keeps its board, operations stays in Notion for a quarter. Reasonable only if you can name the date the split ends; otherwise it becomes permanent by accident.

Whatever you choose, write the rule down. “Tasks live in the project tool, anything longer than a page lives in Notion” is a rule. “Use whichever is convenient” is how you end up with two task lists and one argument per week.

What does a five-step cutover plan look like?

Steps in order, with a stop condition on each.

1. Freeze and inventory. Announce the export window and stop editing. Notion warns that large workspace exports can take many hours to process, and the file is a snapshot of when it was processed rather than when you clicked. List every database, formula, automation and integration that writes into Notion.

2. Prepare the files. Add ID columns, reset views to unfiltered tables, export Markdown & CSV, then export HTML for the archive. Verify the ZIPs before cancelling anything: page counts against the sidebar, the largest database, image folders, a nested page.

3. Import open work only. Create the destination structure first — projects, statuses, people — because CSV importers do not build your hierarchy for you. Import, then spot-check ten rows against the source, including one with a relation and one with an attachment.

4. Rebuild the visible layer. Recreate the three to five views people open daily, not all twenty. Restore relations using the ID column. Recreate one automation, watch it for a week, then decide about the rest.

5. Run parallel for one month. Notion becomes read-only. Every new task is created in the new tool, with no exceptions and no “just this once”. At the end of the month, review what broke, fix the templates, and only then archive.

The stop condition matters. If step 3 produces more than about 5% of rows needing manual repair, stop and fix the mapping before importing the rest. Bulk repair is cheap; individual repair is a week of somebody’s life.

What about formulas, rollups and automations?

They are the part of Notion that felt like software, and they are the part that disappears. A rollup counting open tasks per project becomes a number frozen at export time. The new tool will not recalculate it, and re-importing the CSV will not restore the definition.

Two approaches work. Either rebuild the calculation natively — most project tools compute progress from completed sub-tasks, which replaces the most common rollup — or accept the snapshot and stop pretending it is live. What does not work is importing a formula column and expecting it to keep computing, which produces confident-looking, permanently wrong numbers on a dashboard.

Automations are worse, because they are invisible until they stop. A rule that set a due date when a status changed simply will not exist in the destination. Write them down before you leave, in three fields: trigger, condition, action. Most teams discover they had eleven automations and needed three.

Where does Doitify fit in this migration?

Doitify is our product, so read this as disclosure rather than advice. It handles the layer that is hardest to rebuild from an export: projects, tasks, sub-tasks, checklists, owners and due dates in one hierarchy, with Kanban boards, Gantt charts, roadmaps, calendars, workload views and work reports on top. That is precisely the layer a Notion workspace approximates with relations, rollups and hand-maintained views.

For migration specifically, CSV import and export are built in, and documents live beside the work instead of in a separate workspace, which makes the split-by-object pattern less necessary. Doitify Copilot generates tasks and sub-tasks from a stated goal, which is useful in week one when the new structure is still empty and every project looks like a blank page.

It is not a reason to migrate on its own. A team whose work genuinely fits in three Notion boards should keep the boards, skip the rebuild, and spend the money on something that hurts more.

Conclusion

Migrating from Notion to a project management tool is a data export attached to a workflow rebuild. The export takes an afternoon. The rebuild takes two weeks, and it is where the value is, because it is the only chance you get to delete the statuses nobody uses and the fields nobody fills.

Plan it in five steps, import open work only, keep an HTML archive, and run parallel for a month. Budget the hours honestly — 18 to 30 for a mid-size team — and put the number next to the licence cost so the decision is made on both numbers rather than one.

And if the answer turns out to be “keep Notion for docs, use a real tool for tasks”, that is not a compromise. It is the arrangement most teams end up with anyway, reached deliberately instead of by accident.

If this post on migrate from Notion was helpful, you might also enjoy How to Prioritize Tasks at Work (Step-by-Step) and How to Balance Workloads Across a Team (Step-by-Step Guide).