{"slug": "how-and-why-we-moved-our-knowledge-base-from-notion-to-markdown", "title": "How and why we moved our knowledge base from Notion to Markdown", "summary": "A company migrated its internal knowledge base from Notion to a folder of Markdown files to gain full ownership and control over its content, reduce costs, and improve privacy. The team used the Obsidian Importer plugin and the Notion API to move the data, though the process broke many internal links and required manual fixes. The shift reflects a broader move away from vendor lock-in and toward simpler, more portable file formats.", "body_md": "# How and why we moved our knowledge base from Notion to Markdown\n\nWe used Notion as our knowledge base for years. It served us well. But now we moved everything to a folder of Markdown files.\n\n[ # ](#motivation)Motivation\n\nThere is nothing wrong with Notion. I still enjoy using it privatly. In the beginning, it felt like a very capable Markdown editor with nice abstractions. Over the years though, it got a bit too crowded for my taste. We used Notion as our knowledge base and partially for project management for years. The knowledge base part is what we cared about the most. Hopefully, these thoughts are usefuls for others.\n\nSide note: I can imagine Microsoft buying them at some point. There is a lot about Office that is antiquated and Notion could fill that gap (Hello Notion CoPilot!).\n\n[ # ](#ownership-over-our-content)Ownership over our content\n\nFreedom of tools. Content rules. Some of us use [Obsidian](https://obsidian.md/) to edit, but the same folders open in any code editor. I enjoy writing Markdown. I do it for the blog and the docs every day. Keeping the knowledge base in the same format removes friction.\n\n[ # ](#saving-costs)Saving costs\n\nOur internal structures changed and require less ongoing work on internal policies. We also adopted Linear for project management (hello next vendor lock-in). So Notion was neglected. It can also be hard for humans to find information in a large knowledge base, or to keep parts of it up to date. We already pay for an AI subscription. Paying extra for Notion AI on top was never something I wanted to do.\n\n[ # ](#privacy)Privacy\n\nThe files are ours now. Full data sovereignty. But we still want to share them across the team, so we trust a Git repo provider with the content (Obsidian sync is another option). When we run batch edits with AI, we may leak data to whichever provider we use. But we do not store secrets in our knowledge base — no API keys, no passwords, no trade secrets.\n\n[ # ](#how-we-moved)How we moved\n\nWe used the Obsidian Importer plugin and the Notion API flow. There are plenty of tutorials on how to do that, so we will skip the basics and stick to the gotchas.\n\n[ # ](#missing-internal-links)Missing internal links\n\nA significant number of internal links broke during the import. Incremental imports left links pointing to `NOTION_PAGE:(UID)`\n\nreferences that no longer resolved. I fixed most of them with a local AI agent. About 150 broken links remained. I checked many of them manually and found they were either broken in Notion already or pointed to trashed documents. Good enough.\n\n[ # ](#team-spaces-to-vaults)Team spaces to vaults\n\nIn Notion, we had a few \"team spaces\" with separate access management. In Obsidian, the rough equivalent is a vault - think of it as a Git repo. We decided one mono-vault without access management beats multiple vaults. Searching and linking across vaults is not easy, and a flat structure matches how we actually work.\n\n[ # ](#assets)Assets\n\nNotion abstracts files away. It is all content. With Obsidian, files are real things you have to think about. We created one global `Assets`\n\nfolder and put everything in it. Most of it is images, and we plan to use fewer files going forward.\n\n[ # ](#databases)Databases\n\nNotion databases are very capable and cool. Obsidian recently added databases too, but they are way more basic. The concepts are different. We will see how useful they turn out to be in practice. I already miss the fancy databases.\n\n[ # ](#file-structure)File structure\n\nThe file structure works differently. The relation between a database and its entries shows up in the file system — each entry exists as its own file. That takes some time getting used to, but it makes the content portable.\n\n[ # ](#web-forms)Web forms\n\nWe used Notion web forms to accept job applications. We need a different solution for this. Open task.\n\n[ # ](#no-real-time-collaboration)No real-time collaboration\n\nWe can no longer co-edit a document live during a meeting. We will see how much we miss it. Our hunch: less than expected.\n\n[ # ](#other-notion-features)Other Notion features\n\nWe did not use Mail or Calendar in Notion. We will not miss those.\n\n[ # ](#takeaway)Takeaway\n\nOwning the files matters more than we expected. Plain Markdown in a Git repo means we can search it, edit it with any tool, version it like code, and pipe it through AI when we want to.", "url": "https://wpnews.pro/news/how-and-why-we-moved-our-knowledge-base-from-notion-to-markdown", "canonical_source": "https://blog.fortrabbit.com/moving-knowledge-base-from-notion-to-markdown", "published_at": "2026-06-12 11:16:29+00:00", "updated_at": "2026-06-12 11:51:27.451540+00:00", "lang": "en", "topics": ["ai-tools"], "entities": ["Notion", "Obsidian", "Linear", "Microsoft"], "alternates": {"html": "https://wpnews.pro/news/how-and-why-we-moved-our-knowledge-base-from-notion-to-markdown", "markdown": "https://wpnews.pro/news/how-and-why-we-moved-our-knowledge-base-from-notion-to-markdown.md", "text": "https://wpnews.pro/news/how-and-why-we-moved-our-knowledge-base-from-notion-to-markdown.txt", "jsonld": "https://wpnews.pro/news/how-and-why-we-moved-our-knowledge-base-from-notion-to-markdown.jsonld"}}