Ich habe über Jahre hinweg mein privates Wissen in Notion gesammelt: Projektnotizen, Buchzusammenfassungen, Recherchen, Ideen für diesen Blog. Über 1.600 Einträge kamen so zusammen. Alles unter dem Second-Brain-Ansatz, mit dem Vorsatz, aus den Inputs im Verlauf auch etwas zu machen - die Daten blieben jedoch unverarbeitet liegen, trotz dieses ersten Versuchs.
Dann wandelte sich Notion und das Thema KI hielt Einzug, allerdings waren die zusätzlichen Kosten für meinen Tarif nicht vertretbar und mir blieb das Potenzial, das in der Nutzung von KI lag, leider verwehrt.
Parallel begann ich mich mit diversen KI-Services zu beschäftigen, OpenAI/ChatGPT, Google/NotebookLM und auch DeepSeek. Diese konnte ich zwar nutzen, ihnen stand aber nicht mein Datenbestand aus Notion zur Verfügung - die Nutzung von entsprechenden MCPs war sehr langsam und eher unzuverlässig.
Also habe ich begonnen ein neues Zuhause für mein Second Brain zu suchen. Und seit 4 Wochen hat es seine neue Heimat in einer lokal gepflegten Obsidian-Vault gefunden, die direkt aus meinen Projektsessions mit Claude heraus wächst und gedeiht. Die wichtigste Frage zu Anfang: wie kommen die Bestandsdaten aus Notion in das neue System? Aus einem vermeintlich simplen Datenexport wurde ein mehrwöchiges technisches Migrationsprojekt.
Die Hürde: Notion-Logik passt nicht 1:1 auf Obsidian
Notion organisiert Wissen in Datenbanken mit Formel-Spalten, Rollups und ID-basierten Relationen zwischen Einträgen – im Hintergrund liegt eine relationale Datenbank, die man über eine Oberfläche bedient. Obsidian dagegen speichert jede Notiz als einzelne Markdown-Datei; Struktur entsteht über Frontmatter (Metadaten am Dateianfang) und Wikilinks zwischen Dateien. Beides sind grundverschiedene Denkweisen, und dazwischen gibt es keine automatische Brücke.
Das dafür naheliegende Community-Plugin Notion Bases hat einen wichtigen Irrtum meinerseits gleich zu Beginn korrigiert: Es ist kein Live-Sync-Werkzeug, das eine bestehende Notion-Datenbank kontinuierlich spiegelt. Es baut lediglich eine Notion-artige Datenbank-Ansicht aus vorhandenem Markdown-Frontmatter nach. Ohne sauber strukturierte Frontmatter-Daten in den Zieldateien gibt es also nichts anzuzeigen – die eigentliche Migrationsarbeit musste vorher passieren, nicht das Plugin übernimmt sie.
Architekturentscheidung: vom Container-Denken zum Type-Modell
In Notion hatte ich in Containern gedacht: Eine Datenbank war im Grunde ein Ordner mit fester Spaltenstruktur. Diesen Ansatz 1:1 zu übernehmen, hätte in Obsidian schnell zu einer ähnlichen Ordner-Fragilität geführt, wie sie sich an anderer Stelle in meinem Projektmanagement bereits gezeigt hat. Ich habe mich deshalb bewusst für ein anderes Modell entschieden: Jede Datei trägt unabhängig von ihrem Ablageort ein eigenes type-Property im Frontmatter (z. B. type: db_input-notizen). Der Ordner ist damit nur noch für die menschliche Orientierung da, nicht mehr die Quelle der Struktur.
Zusätzlich habe ich bewusst nicht versucht, den Altbestand schrittweise zu migrieren. Stattdessen habe ich das Zielschema zunächst mit frischen Testdaten durchgespielt, bis Namenskonvention und Property-Struktur stabil standen – erst danach kam der eigentliche Import. Für diesen Import selbst fiel die Wahl am Ende auf den vollständigen CSV-Export aus Notion statt auf die Notion-API: Die API-Anbindung scheiterte bei diesem Datenvolumen wiederholt an Query-Limits.
Stolpersteine beim Aufbau
Auf dem Weg zum fertigen Schema tauchten mehrere Probleme auf, die auf den ersten Blick klein wirkten, aber jeweils den gesamten Import blockierten:
- Relationen sind titelbasiert, nicht ID-basiert. Im Notion-Bases-Plugin verweist eine Relation auf den Dateinamen, nicht auf eine stabile ID wie in Notion selbst. Jede spätere Umbenennung einer Notiz hätte damit unbemerkt Verweise brechen können.
- Das Raute-Zeichen „#" bricht Wikilinks. In 31 Dateien steckte ein „#" im Titel – strukturell unverträglich mit Obsidians Verlinkungssyntax. Alle 31 mussten umbenannt werden, bevor der Import sauber lief.
- Ein seit 2024 offener Plugin-Bug. Ein bekannter Fehler im Plugin Metadata Menu (Issue #540) verhindert gefilterte Relations-Picker – ich konnte Beziehungen also nicht komfortabel aus einer vorgefilterten Liste auswählen.
- Sanitizing-Drift zwischen alten und neuen Importen. Ältere und neu importierte Datensätze normalisierten Sonderzeichen und Formatierung nicht identisch, wodurch eigentlich gleichwertige Werte unterschiedlich aussahen.
Wie ich die Probleme gelöst habe
Für den fehlenden gefilterten Relations-Picker habe ich einen einfachen, aber zuverlässigen Workaround gefunden: Relationen direkt im nativen Properties-Panel eintippen. Die Autocomplete-Vorschlagsliste wächst dabei automatisch mit jeder neu angelegten Notiz mit, sodass sich die fehlende Filterfunktion in der Praxis kaum noch bemerkbar macht.
Für die Ordner-/Typ-Frage habe ich eine finalisierte Namenskonvention für alle Datenbank-Typen festgelegt (db_input-notizen, db_themenfelder und weitere) – konsistent genug, dass sie auch bei künftigem Wachstum nicht kollidiert.
Und für die aus Notion gewohnten Rollup-Spalten (aggregierte Werte aus verlinkten Einträgen) gibt es in Obsidian keine direkte Entsprechung. Ich habe sie über eine Kombination aus file.backlinks (Obsidians eingebauter Rückverlinkungs-Erkennung) und eigenen Formel-Spalten nachgebaut – nicht 1:1 identisch zu Notion, aber für meine Zwecke funktional gleichwertig.
Ergebnis
Der Vollimport der Input-Notizen – 1.627 Zeilen – ist ebenso abgeschlossen wie die Übernahme von Bücherliste und bereits verarbeiteten Notizen. Der zugehörige Task „Notion-Export umsetzen" steht seit heute auf „erledigt".
Damit ist die technische Kernmigration erledigt – aufwendiger als das reine Kopieren der Daten war am Ende die Entscheidung, welche Struktur diese Daten künftig tragen soll. Genau das ist für mich auch der Kern des Homo-Creator-Gedankens, der diesen Blog durchzieht: nicht ein fertiges Tool eins zu eins übernehmen, sondern die Struktur dahinter wirklich verstehen und selbst anpassen.
Ausblick
Seit dem Umzug nutze ich die Daten aktiv in Sessions mit Claude – das Second Brain ist damit erstmals wirklich nutzbar geworden, nicht mehr nur Ablage. Bis dahin waren allerdings noch deutlich zahlreichere weitere Anpassungen notwendig, als der reine Datenimport vermuten lässt – von der grundsätzlichen Ordnungslogik über die Werkzeuge fürs Projektmanagement bis zur Frage, wie neues Wissen künftig überhaupt hereinkommt und wie das Regelwerk für die KI (Harness) aussieht. Darauf gehe ich in den nächsten Beiträgen dieser Serie ein.
Der Datenimport war damit nur der erste Schritt auf dem Weg zum eigenen LLM-Wiki – nicht der Schlusspunkt.