Should I export everything from Notion or just the active subset?

Just the active subset — typically pages and databases the team has opened in the last 60 days. Most Notion workspaces are 80 percent stale archive. Migrating the archive triples the work for nearly zero value. Keep Notion as a read-only searchable archive for 90 days, then export the rest to cold storage.

What about embedded Loom videos, Figma frames, and other embeds?

The URL is preserved on export but the live embed is not. After import, embedded blocks become regular links. Most teams accept this as a one-time fix-up: re-paste the link in the new workspace and the embed re-renders. Plan a half-day of cleanup for a workspace with many embeds.

How long does a typical Notion migration take?

For an active 10-person workspace: about 1-3 weeks of elapsed time, with maybe 8-15 hours of actual work. The big variable is the number of databases with custom formulas and rollups — those are the slow part. Pages, simple databases, and rich text move quickly.

When should I NOT migrate from Notion?

If your team's primary workflow is heavy custom database modeling — wikis with 50+ databases, complex automation between them, or deeply customized templates as a knowledge base for hundreds of people — Notion is genuinely the right tool for that and migrating away is a downgrade. Migrate when Notion has become your project tracker, scheduler, comms scratchpad, and notes app simultaneously and the seams between those uses are losing you hours per week.

How to Migrate from Notion to an All-in-One Workspace Without Losing Your Databases

Most teams that consider leaving Notion stop themselves halfway through the export wizard. The fear is straightforward: years of pages, databases, formulas, embeds, comments, and sharing permissions, and a vague sense that all of it will silently rot in the destination. The honest version of the migration is narrower than that fear, and the work that matters is concentrated in a handful of specific places. This post is the operational guide.

Why teams are leaving Notion in 2026

Notion is a beautifully flexible tool for one job — building your own knowledge base from databases — and a serviceable tool for several others. The teams that are leaving in 2026 are not the ones using Notion as a wiki. They are the ones using Notion as the catch-all for everything that didn't have an obvious home: project tracking, meeting notes, partial CRM, sprint planning, lightweight task lists, brain-dumps from client calls.

That second job is where Notion shows its seams. Project tracking in Notion tends to drift into "we have nine views of the same database and nobody is sure which one is the source of truth." Meeting notes in Notion tend to drift into "the important decisions are in someone's private page nobody knows to read." And the AI assistants that are now standard in connected workspaces have trouble taking action when the source data is in a tool that doesn't know about your inbox, calendar, or chat.

The migration question, then, is not "is Notion bad?" — it is "is what we built in Notion still the right shape for how we actually work in 2026?"

What Notion's export actually preserves

From Notion: Settings & Members → Settings → Export & Backup → Export all workspace content → Export format: Markdown & CSV → Include subpages: yes. That export gives you a zip with two file types:

One .md file per Notion page. Headings, paragraphs, bullets, numbered lists, code blocks, quotes, callouts (rendered as blockquotes), toggles (rendered as headings), and inline links all come out in clean Markdown.
One .csv file per database. Each row is a database item. Each column is a property. Property values that were text, number, select, multi-select, date, person, file URL, or checkbox come through correctly typed.
One folder per page-with-subpages. The directory structure mirrors your nested page structure.

That is genuinely a lot. For a normal team, maybe 80 percent of what is in your Notion workspace lands cleanly in any destination that understands Markdown and CSV.

What gets lost (the honest list)

The other 20 percent is what trips teams up. The export does not preserve:

Formulas. Database formula columns export as their computed value at export time, not as the formula. The logic is gone.
Rollups. Same — computed value only, not the relation that produced it.
Linked databases and synced blocks. They become standalone copies. If the source updates later in Notion, the copy does not.
Embedded content. Loom videos, Figma frames, Tweets, YouTube videos — the URL is preserved as a link but the live embed becomes plain text.
Page-level permissions and sharing settings. Notion's per-page ACL model doesn't map to most other tools' workspace-wide model.
Comments. Discussion threads on pages and database items don't export.
Page version history. The export is point-in-time. There's no way to bring history with you.
Custom emoji and cover images. Emoji icons usually export as Unicode (fine), but custom uploaded icons and cover images often do not.
Database views. The data behind the views exports; the view configurations (filters, sorts, groups, gallery layouts) do not.

Most teams over-rotate on the loss of these features and stall the migration. In practice, formulas and rollups are the only ones that require deliberate rebuilding work. Everything else is a one-time cleanup of a few hours.

The five-step migration sequence

The single biggest mistake teams make is trying to migrate everything in one weekend. Below is the sequence that consistently works for active 5-to-25 person workspaces.

Step 1: audit your active workspace before you export

List the pages, databases, and views the team has actually opened in the last 60 days. Most Notion workspaces are 80 percent stale archive — old project debriefs, dead playbooks, experiments nobody finished. You do not need to migrate the archive. Only what is in motion.

Step 2: document the workflows that depend on Notion-specific features

Walk through every active database. Note which ones use formulas, rollups, linked databases, or synced blocks. These are the only items that will need rebuilding in any destination — they are not portable. Knowing the count up front prevents the most common mid-migration surprise: "wait, this database needs three formulas and we forgot to budget time for that."

Step 3: export the active subset as Markdown + CSV

In Notion, go to Settings → Export → Markdown & CSV with subpages enabled. The export download takes 5-30 minutes depending on workspace size. Markdown preserves page content; CSV preserves database tabular structure. HTML export looks prettier in preview but breaks the database structure on import.

Step 4: run a two-week parallel pilot in the new workspace

Import the active subset into the new system. Move forward all new work in the new system. Keep Notion fully functional but stop creating new pages there. After two weeks of parallel operation, the team has working knowledge of the new system and you have direct evidence of where it fits or does not fit. This is also when you'll discover the things you forgot to migrate.

Step 5: decommission Notion gradually, not all at once

After the pilot succeeds, switch Notion to read-only. Keep it as a searchable archive for 90 days while the new system absorbs anything you missed. Then export one final dump to cold storage (Markdown + CSV again) and cancel the subscription. Never delete in week one — discoveries always come later.

The five hardest cases and how to handle them

Five specific patterns cause more than half of all migration friction. Worth budgeting for them explicitly.

1. Databases with formulas and rollups

No destination — including all-in-one workspaces — can import Notion's formula language. Plan to rebuild each formula as the destination's equivalent (a formula column, a query, or a view filter, depending on the destination). For most teams this is 5-15 formulas total and takes one focused afternoon. The work is mechanical, not intellectual — keep your formula definitions documented somewhere outside Notion before you start.

2. Embedded Loom, Figma, and YouTube

The URL exports as a link but the live embed dies. Treat this as a one-time cleanup pass: the destination will re-render the embed automatically when you re-paste the URL. A workspace with 50-100 embeds takes about a half-day. Skip embeds in archived pages — re-embedding old Looms is rarely worth it.

3. Per-page sharing and external guest access

Notion's per-page sharing doesn't map to other tools. The fix is to set up workspace-wide permissions in the destination first (everyone gets default access to the right scopes), then add per-page exceptions only where you actually need them. Most teams discover they had way more per-page sharing configured than they actually needed.

4. The "everything in one mega-database" pattern

Some Notion workspaces have a single database with 50+ properties because over time everything got added to "the tasks DB." Resist the urge to migrate that mega-database as-is. The migration is the right time to split it into the two or three actual entities it represents (tasks, projects, decisions). Future-you will thank present-you.

5. Comments and decision history

Notion's comments don't export and are usually lost. Before the cutover, review your most-used pages for important decisions captured only in comment threads. Copy those decisions inline into the page body. Most teams find 10-30 decisions worth preserving this way; the rest were conversational and can stay in Notion's read-only archive.

How to choose the destination

The right destination depends on which Notion job you actually wanted to keep:

If Notion was your wiki / knowledge base and you mostly want it to load faster and have better search: Confluence, Coda, or specialized wiki tools (Outline, Slab) are the natural answers.
If Notion drifted into project tracking and that's the pain: Linear, ClickUp, Asana, or an all-in-one workspace.
If Notion was your team's catch-all for projects, notes, scratchpads, lightweight CRM, and meeting agendas all at once: the catch-all problem is the actual problem. An all-in-one workspace replaces several Notion roles at once and connects them to the email and chat that are already part of the team's day. ADLR is built explicitly for this case.

When you should not migrate

The honest cases where Notion is the right tool to keep:

Heavy custom database modeling. If you've built a 50-database internal system that the team uses daily and nobody complains about, the migration cost is real and the upside is small. Stay.
Public-facing knowledge bases. Notion's public sharing for help docs, team handbooks, and roadmaps is genuinely good and most generalist workspaces don't have a clean equivalent.
Workspaces where the database structure IS the workflow. Some teams' work is "look at the right view of the right database every morning." Notion is built for this. Don't move just to move.

Migrate when Notion stopped being the wiki and became the place where every kind of work landed because it didn't have a better home. Stay when Notion is doing the one specific job it was built for.

Frequently asked questions

Does Notion's export preserve formulas, rollups, and linked databases?

No. Markdown + CSV export preserves data values and database tabular structure, but Notion-specific compute (formulas, rollups, relations, synced blocks) does not survive. Plan to rebuild that logic in the destination — usually 1-3 days for an active workspace.

Should I export everything or just active stuff?

Active subset only — typically pages opened in the last 60 days. Most Notion workspaces are 80 percent stale archive. Keep Notion read-only as a searchable archive for 90 days, then export the rest to cold storage.

What about embedded Loom and Figma?

The URL exports as a link; the live embed dies. After import, re-paste the URL in the destination and most workspaces re-render the embed automatically. Plan a half-day of cleanup for an embed-heavy workspace.

Will permissions and sharing come over?

No. Notion's per-page model doesn't translate. Set up workspace-wide permissions in the destination first, then re-grant per-page exceptions where actually needed.

How long does a typical migration take?

1-3 weeks elapsed, 8-15 hours of actual work for an active 10-person team. The slow part is rebuilding formulas and rollups; the rest moves quickly.

When should I NOT migrate?

If your team uses Notion as a heavy custom database, public knowledge base, or the database structure literally is the workflow — stay. Migrate when Notion became the catch-all and the seams started costing real hours per week.