Wie macht man Informationen, die in proprietären Datenbanken gespeichert sind, langfristig verfügbar und zugleich für KI-Systeme zugänglich? Diese Frage dürfte viele Unternehmen, Organisationen und Personen beschäftigen. In diesem Artikel zeige ich an einem konkreten Beispiel, wie man eine FileMaker-Datenbank in einen Obsidian-Vault überführen kann, sodass die Daten am Schluss als Markdown-Dateien vorliegen.
Die Ausgangslage
Vor ziemlich genau 30 Jahren habe ich mit FileMaker eine Datenbank für mein persönliches Wissensmanagement entwickelt. Ich studierte damals Geschichte, Informatik und Filmwissenschaft und schrieb meine Lizenziatsarbeit zum Thema «Der Zweite Weltkrieg im Schweizer Film». Entsprechend musste ich eine grössere Menge an Literatur und Filmen verwalten und entwickelte dafür eine FileMaker-Datenbank, die ich wenig phantasievoll StudyMaster nannte.
StudyMaster verwaltete im Wesentlichen fünf Arten von Informationen:
- Publikationen (Bücher, Artikel u.ä.)
- Filme
- Notizen zu Publikationen und Filmen
- Personen
- Themen
Die Besonderheit dieser Datenbank war, dass sie Verweise erlaubte. So konnte man beispielsweise vom Film «Füsilier Wipf» direkt auf die beiden Regisseure «Hermann Haller» und «Leopold Lindtberg» springen, oder auch auf das Buch «Der Spielfilm als historische Quelle» von Peter Neumann, oder auf das Thema «Schweizer Filme 1933–1945». Die Datenbank funktionierte also gewissermassen wie ein Wiki.
Da ich mich auch nach meinem Studium mit dem Schweizer Film beschäftigte, war ich weiterhin an den Informationen interessiert, die in StudyMaster steckten. Die Form einer FileMaker-Datenbank hingegen wurde zunehmend zu einem Problem, und zwar aus unterschiedlichen Gründen:
- Durch meine Arbeit für die Wikipedia lernte ich in den frühen 2000er-Jahren das Prinzip eines Wikis kennen und schätzen. Gerade für die Verwaltung von Notizen mit zahlreichen Querverweisen erschien mir ein Wiki das bessere Werkzeug als eine Datenbank – insbesondere nachdem neue Apps wie Roam Research, Obsidian oder Logseq das Wiki-Konzept auch für das persönliche Wissensmanagement nutzbar machten.
- FileMaker nutzt ein proprietäres Dateiformat. Würde Apple entscheiden, FileMaker einzustellen, wären meine Daten verloren. Obsidian und ähnliche Apps nutzen dagegen Textdateien im Markdown-Format, die man zur Not mit jedem Texteditor lesen kann.
- Apple verlangt stolze Preise für FileMaker-Lizenzen, und diese Kosten summieren sich über die Jahre. Somit war ich auch aus finanziellen Gründen auf der Suche nach einer Alternative.
- Eine FileMaker-Datenbank ist nicht ideal, wenn man Informationen mit einem KI-System durchsuchen und bearbeiten möchte. Markdown-Dateien sind für diesen Zweck wesentlich besser geeignet.
Ähnliche Überlegungen dürften sich heute viele Unternehmen, Organisationen und Einzelpersonen machen, die Daten in älteren, proprietären Systemen verwalten. Im Kern geht es immer um folgende Aspekte:
- Man möchte eine Software ablösen, die nach heutigen Massstäben nicht mehr die beste Wahl ist – weil es inzwischen bessere Produkte oder ganz neue Software-Kategorien gibt.
- Man will sicherstellen, dass man langfristig Zugang zu seinen Daten hat – unabhängig vom Software-Anbieter, der möglicherweise die Weiterentwicklung der Software einstellt, Preise erhöht, den Umzug in die Cloud erzwingt oder aus politischen Gründen den Datenzugriff unterbindet.
- Man möchte die Möglichkeit haben, seine Daten mit einem KI-System zu verbinden, auch wenn der Software-Anbieter keinen MCP-Server bereitstellt.
Schritt 1: Analyse von Datenstruktur und Daten
Bei einem Migrationsprojekt lohnt es sich, genügend Zeit und Gedanken in die Vorbereitung zu investieren. Insbesondere muss man die vorhandenen Datenstrukturen und die darin gespeicherten Daten sorgfältig analysieren. Ziel ist es, einen Datenexport zu erhalten, der für den Import in das Zielsystem optimiert ist, ohne dass Information verloren geht.
Eine solche Analyse ist anspruchsvoll, mühsam und fehleranfällig – oder vielmehr: Sie war es, als es noch keine KI-Systeme auf dem heutigen Niveau gab. Denn mit Claude Code oder ähnlichen Systemen ist diese Aufgabe wesentlich einfacher geworden. Bei meiner FileMaker-Datenbank bin ich dabei wie folgt vorgegangen:
Zunächst habe ich Claude Code eine Kopie(!) der Datenbank zur Verfügung gestellt und ihm sowohl das Konzept der Datenbank als auch das Ziel unseres Migrationsprojekts erläutert. Es empfiehlt sich, solche projektbezogenen Informationen immer auch zu dokumentieren – eine Aufgabe, die man direkt Claude übertragen kann.
Anschliessend habe ich Claude gebeten, die Daten aus der Datenbank auszulesen und in einen Obsidian-Vault zu überführen. Wenig überraschend war es nicht ganz so einfach, denn eine FileMaker-Datenbank besteht aus Binärdateien im *.fmp12-Format, die Claude nicht direkt lesen kann. Immerhin erhielt ich eine gute Anleitung, wie man Daten aus FileMaker im XML-Format exportiert.
Der XML-Export bildete eine gute Grundlage, um sich mit den Details der Datenstruktur zu beschäftigen. Für Claude ist dieses Format sehr gut lesbar, und er konnte aufgrund der XML-Dateien problemlos das Datenmodell rekonstruieren. In der Folge legten wir im Dialog Regeln für den Import der XML-Dateien in Obsidian fest, beispielsweise:
- Konventionen für die Benennung der Notizen
- Ordnerstruktur innerhalb des Obsidian Vaults
- Abbildung der Datenbank-Felder als Obsidian-Properties
- Abbildung der Verweise als Links
- Umgang mit Sonderzeichen
- Umgang mit Duplikaten und leeren Feldern
Danach haben wir zahlreiche weitere Details miteinander geklärt, die für den reibungslosen und verlustfreien Import wichtig waren. Ich verwende hier sehr bewusst das Wort «miteinander», weil gewisse Punkte von mir, andere Punkte aber von Claude eingebracht wurden. Claude hat nicht nur ein sehr gutes Verständnis von meiner Datenbank entwickelt, sondern auch viele potenzielle Probleme beim Import in Obsidian vorhergesehen und eliminiert. Das ist grundsätzlich nicht überraschend, weil Software-Entwicklung bekanntlich zu den Stärken von LLMs gehört. Aber wenn man es konkret erlebt, ist es immer noch eindrücklich.
Insbesondere wenn man seine Daten nicht nur einmalig migrieren möchte, lohnt es sich, alles zu dokumentieren. Auch das ist eine Aufgabe, die Claude akribisch und schnell erledigt – teils auf eigene Initiative, teils nach einer kurzen Nachfrage. Diese Dokumentation umfasst in meinem Fall drei Dateien:
- eine Auflistung aller Datenbank-Tabellen und -Felder inklusive der Anzahl der Datensätze
- eine detaillierte Beschreibung des Vorgehens beim Import der XML-Dateien in Obsidian
- eine CLAUDE.md mit allgemeinen Anweisungen und Verweisen auf die weitere Dokumentation
Schritt 2: Import in Obsidian
Für den ersten Schritt habe ich rund drei Stunden investiert. Der zweite Schritt hingegen – der eigentliche Import – war dann in wenigen Minuten erledigt: Claude hat zwei Python-Skripte generiert, welche meinen XML-Export in ein Verzeichnis mit rund 4’000 Markdown-Dateien konvertiert haben, das ich dann direkt als Vault in Obsidian öffnen konnte. Und das Resultat war einwandfrei.
Ist die Vorarbeit einmal geleistet, kann man seine Daten mit wenig Aufwand in weitere Formate konvertieren. Zu Testzwecken habe ich mir aus dem XML-Export auch noch eine SQLite-Datenbank generieren lassen. Diese kann man dann über LibreOffice Base via ODBC abfragen – oder man lässt sie sich von Claude direkt in eine *.accdb-Datei für Microsoft Access konvertieren.
In beiden Fällen braucht es allerdings noch einiges an Arbeit, um die passenden Masken zu erstellen, mit denen man wieder so komfortabel arbeiten kann wie in der ursprünglichen FileMaker-Datenbank. Zudem wäre insbesondere die Migration zu Access nicht unbedingt ein Fortschritt gegenüber FileMaker.
Fazit: KI eröffnet neue Möglichkeiten – auch bei der Datenmigration
Ich habe im Verlaufe der Jahre viele Datenmigrationen durchgeführt. Ich kann somit ziemlich gut abschätzen, wie aufwändig und schwierig eine solche Aufgabe ist, wenn man sie manuell erledigen muss. Noch vor sechs Jahren habe ich beispielsweise für unsere Plattform MusicLink mühselig eine MySQL-Datenbank als Custom Post Types in WordPress nachgebildet und alle Daten transferiert. Auch Migrationen zwischen Mailchimp, MailerPress und HubSpot sind häufige Aufträge, die Metoki für Kunden ausführt.
Im Vergleich dazu war die Migration von StudyMaster ein Spaziergang: Das Ganze brauchte erstaunlich wenig Zeit, und ich konnte mich ganz auf die konzeptionelle Arbeit konzentrieren, während Claude Code die XML-Dateien analysierte, die Python-Skripte schrieb, die Resultate überprüfte und alles dokumentierte.
Künstliche Intelligenz revolutioniert nicht nur die Software-Entwicklung, sondern auch die Datenmigration. Ohne Know-how geht es allerdings auch hier nicht: Man braucht ein gutes Verständnis von Datenstrukturen und von den Eigenheiten von Quell- und Zielsystem.
Natürlich kann man Claude Code auch einfach blind vertrauen und sämtliche Vorschläge unbesehen abnicken. Bei unternehmenskritischen Daten scheint mir das allerdings gefährlich, denn wie es unter dem Eingabefeld so schön heisst: «Claude ist eine KI und kann Fehler machen.»
Ausserdem: Wenn es das Ziel einer solchen Migration ist, sich aus der Abhängigkeit von einem Software-Lieferanten zu befreien, dann ergibt es wenig Sinn, sich nun einfach von einer KI abhängig zu machen, die als einzige die Datenstrukturen versteht.