Moving a Notion workspace into a local LoreDocs vault feels like moving a house from a rented apartment to a plot of land you own. The address changes, the walls stay, but some of the built-in furniture does not fit the new foundation. For data engineers and AI practitioners who need full control over their knowledge base, the move is worth the effort. This post walks through exactly what arrives intact, what needs a little restructuring, and what Notion features simply do not have a local equivalent.
Getting the data out of Notion #
The first step is to ask Notion for a copy of the workspace. Its built-in export tool produces a zip file containing a folder for each top-level page. Inside each folder you will find a markdown file holding the page content, a set of image files, and a CSV file for any embedded tables. The hierarchy is represented by nested folders, so a page that lives under "Project / Data / Ingestion" becomes Project/Data/Ingestion/ on disk.
LoreDocs expects a directory it can walk recursively. The import command vault_import_dir points at the root of the Notion export and automatically discovers markdown files, images, and CSV tables. No additional configuration is required. The tool reads the front-matter tags that Notion stores in YAML blocks and turns them into vault tags, so the basic skeleton of the workspace -- pages, subpages, plain text, images, and tags -- arrives ready for use.
Performance is predictable: in our testing on a standard developer laptop, a single Notion page imported in roughly three seconds, and a small database export covering three pages finished in about two seconds. The bottleneck is reading from disk and writing to SQLite, not network latency, so larger workspaces scale proportionally rather than erratically.
What transfers cleanly #
Pages and their nesting come through without loss. Each markdown file becomes a document in LoreDocs and the folder path is preserved as the document's location, so the original hierarchy is fully searchable with the same depth it had in Notion. Plain text content -- paragraphs, headings, bullet lists, and code blocks -- survives unchanged because these are native markdown constructs.
Images attached to Notion pages are copied into the vault's assets/ folder and the markdown reference is updated to point at the local copy. The image data stays under your control and never passes through a third-party server. Notion's "properties" that you used as tags appear as YAML front-matter entries, which LoreDocs reads and indexes, so you can filter or search by tag across all vaults immediately.
Version history starts fresh from the import. The import creates a single version for each document, and from that point forward LoreDocs' built-in versioning records every edit. Rolling back to any prior state takes a single call. Because LoreDocs stores metadata in a local SQLite file and the document bodies in the vault directory you own, the entire knowledge base is portable: copy the loredocs.db file and the vaults/ folder to a new machine and you have an identical workspace without any cloud dependency.
What does not transfer cleanly #
Notion's flexibility comes from a database engine that has no direct counterpart in a file-based vault, so several features require manual handling after the import.
Notion tables are exported as CSV files. LoreDocs can ingest a CSV as a plain document, but the relational view, filters, and roll-up formulas disappear in the process. If you need searchable, queryable tables, load the CSV into a separate SQLite table or a vector store and link to it from the markdown document that originally contained the view.
Synced blocks, embed links to external services, and inline PDFs are stored as references in the markdown. The raw file is not automatically copied, so you must place the referenced assets in the vault's assets/ folder and adjust the paths by hand. Notion's formula and roll-up fields become static text after export -- if the calculations are still needed, recreate them as Python scripts or Jupyter notebooks that read the CSV data.
Page relations are the trickiest gap. Notion lets you create a property that points to another page; in the markdown export this becomes a plain link with the original page title. The link still works, but the back-reference that Notion shows in its UI is lost. On the Pro tier, LoreDocs can surface these relationships automatically through the auto-discovered document relationships feature, which analyzes cross-document links and makes them queryable. On the free tier, you can rebuild a bidirectional map by adding a small metadata file that records the relationships, then use LoreDocs' vault_prime call to inject the full context when you query.
Understanding these gaps before you start lets you plan a realistic cleanup. For most engineering teams the missing relational features are replaced by code that lives in the same repository as the vault, keeping the knowledge base and the data pipelines tightly coupled.
Finishing the migration with LoreDocs tools #
Once the raw files are in place, a handful of LoreDocs operations turn a collection of markdown files into a searchable, versioned knowledge base.
Calling vault_open_workspace(path) creates a workspace-scoped auto-vault bound to the import directory. The call is idempotent -- the same vault is returned on every subsequent call, which mirrors the low-friction onboarding you expect from a modern data platform. From there, vault_add_doc adds any files that were not part of the original export, such as generated reports or model cards.
Full-text search is powered by SQLite's FTS5 engine. A keyword query scans every document across all vaults and returns matches with highlighted snippets in milliseconds. If you have the Pro tier, you can initialize the hybrid semantic index with vault_rebuild_index. LoreDocs builds a LanceDB index combining BGE-small embeddings with BM25 scores and fuses the results using reciprocal rank fusion, giving you a search experience that understands concepts as well as exact words. This is particularly useful when you remember the intent of a decision but not the exact phrasing it was documented with.
Because LoreDocs registers itself as an MCP server through a project-local .mcp.json file, any AI-enabled IDE that supports the MCP protocol can call vault_search or vault_prime without additional configuration. You can ask a Claude-based assistant to retrieve the paragraph that explains your feature flag strategy, and the response is drawn from the same vault you just migrated.
File types LoreDocs ingests directly #
| Type | Extension | Notes |
|---|---|---|
| Markdown pages | .md |
Primary document format |
| Images | .png ,.jpg ,.jpeg ,.gif |
Copied and path-updated |
| Flat tables | .csv |
Ingested as plain documents |
| Plain text | .txt |
Added with vault_add_doc |
Anything outside this list needs a custom script or a manual copy. After the import, run vault_rebuild_index if you have the Pro semantic layer enabled; this step scans the vault, creates embeddings, and builds the hybrid search index.
Getting started #
The import process is well-defined: export from Notion, point vault_import_dir at the root, and handle the gaps documented above. Pages, hierarchy, tags, and plain text arrive without loss. Tables, embedded blocks, formulas, and page relations need extra attention, but the same tools you already use for data pipelines can reshape those artifacts into a format that fits a local vault.
The result is a knowledge base that lives under your direct control, searchable with both keyword and semantic methods, and queryable by any MCP-compatible development environment. For more on how LoreDocs fits into a local AI knowledge stack, see the LoreDocs deep dive and the local knowledge vault post. To try the import on your own Notion export, visit the LoreDocs tools page.
LoreDocs is available now. If you want early access to upcoming features, join the LoreDocs waitlist.
Get posts like this delivered weekly -- subscribe to Dispatches from the Labyrinth.