Data Portability (& Roam Research)

Data Portability (& Roam Research)

Data portability is the idea that you can bring your data “with you”; if you leave a certain SaaS or piece of software, you should be able to export your data.

Many, if not most, companies now allow you to do so.

There’s usually no danger for them to do so because raw data export isn’t the same as having the data end product you’re used to.

I got to think about this a lot again as I’m experimenting with the most excellent Roam Research, and one of their long term promises of assurance is “you can export the data; you won’t lose what you put in”, and I don’t think that’s 100% correct.

To illustrate that, for the remainder of the article imagine you’re subscribed to a service where you 1) upload your photos, 2) which you then edit and mark up


The first thing about data portability is that what we usually end up with when we export our data often isn’t the thing you’ve been working with on a day to day basis.

Evernote exports to an XML format with the file extension ENEX. Roam exports to JSON. For both these services, these are the most powerful, most inclusive export options.

In both cases you’d end up with one large file which contains the raw data of your notes, but not the essence of what you and I think of as a note.

Enex & Json exports. Neither resemble the actual notes you’re used to.

The equivalent in our photo service example is that if you would export your data (your photos), instead of ending up with a set of photos, you receive files with long strings of characters which a programmer could turn into photos but for all sense and purposes they aren’t photos to you. This is not what you’ve been looking at day to day.

The raw data of the enex/json screenshot shown above

Both services — Evernote and Roam — can also export in more readily consumable formats; Evernote in HTML files, Roam in MarkDown files.

Which lead us to the next point.


Depending on the functionality, the features, of the tool you exported data from, the tool’s functionality is the data.

Think of it this way. You upload your photos, you edit them, apply filter, add stamps, annotate, tag, describe. Then when you export your data you get your raw photos, and maybe a series of files describing which edits the system should apply to those photos, and what information. But for all sense and purposes, your photos now look nothing like they did when they were in the tool. They’re unedited, untagged, unannotated.

For a tool like Roam this means that what you built — the carefully built knowledge graph — isn’t what you get when you export your data

If you export to JSON all the data to have another tool that works with exactly the same rules in exactly the same manner rebuild that graph is there — but the JSON export isn’t itself that thing.

If you export to MarkDown the block references aren’t there, the bi-directional annotations aren’t there. Your graph isn’t there.

What a tool does with or for your data can be transformative up to the point where getting your raw data back is almost useless.


Planning, and testing, a Data Exit Strategy, is as important as your Backup Strategy: you don’t want to find out if it works or not by the time the rubber hits the road.

Before you commit to a tool, see what it exports how. Compare that end product to the value you hope to get from the tool; is what it exports of equal value as to what it contains, what you put it?

If not, how would you recuperate that value upon exit?


Of course this goes further than this and touches on the Uniqueness Of A Tool: the less unique the features, the easier to replace, but also the more untouched your data will be.

E.g.: a plain text editor is easy to replace as all it has to do, and all it produces, are plain text files. Using a plain text editor which can insert images would create a Tool Dependency: to see and use the feature you would need that tool.

9 Replies to “Data Portability (& Roam Research)”

  1. I just found Roam Research about a week ago as a candidate to hold my Zettelkasten. Currently, I use The Archive which is plain text and markdown text only. In the Zettelkasten world, “future proof” is of paramount concern. Now, with your critique of Markdown export from Roam, you have really depressed me. I am about ready to go to parchment and a quill pen. But thank you anyway for making this “future proof” issue very open and plain.

  2. I agree that the tool make the data, everything a tool does to make the data more useful is (probably) the reason you are using the tool. If all we want is portable data, we can stop searching for new tool and just use plain text (markdown) files instead.

    In the case of Roam Research it is possible to export your data to Markdown and import these in, for example Obsidian, the data will be usable again.

    For portability nice features would be:
    – Export to html with bi-directional links (for as far as possible)
    – inclusion of images as files
    – better: when uploading images keep them on a storage you ‘own’, tools we use need this integration

    The weird thing is that people, in general, seem less concerned by data portability and/or ownership when uploading data to Facebook or when creating Word or Excel documents.

  3. Considering the export before ther start is a valuable strategy. I don’t agree with the idea that Roam’s graph is your data, however. That is Roams proprietary software analyzing your data. To expect their graph to come with you is inconsistent with the rest of the valid arguments and insight you present. Now, if Roam is using a non-standard bi-directional Link [[]] that would be cause for concern. I will be testing…

  4. After pouring months of effort in building up my Notion footprint, I read your article and tried an export just now – turns out it **doesn’t** even work and had to file a few bugs with Notion. So much for an exit plan – the door hinges are broken!

    Also noticing Notion only exports to PDF, MD, and HTML so once they fix their export, I’m not exactly expecting my exports to pass the test and bracing myself to witness an amazing amount of meta data missing (esp comments and discussions). My biggest concern is without using XML/JSON, I can’t see how they could possibly be exporting Notion databases in a way they will be intact in another tool…

  5. JSON is a nice export model, if you know a bit of scripting.

    I ran into export limitations when I wanted to leave Evernote when it got really buggy. Finally stayed with it because the alternatives are not better, just different. Now I know to do a test run before committing to a tool, knowing that with tools like TheBrain or Roam Research you’re about to lose a lot of what the tool itself delivered, unless you know some scripting *and* can at least recreate some of the display features.

  6. I’m very familiar with the semantic web. So far, unfortunately, it turns into feeding the beast that’s Google. Essentially, nowadays, you’re marking up data so Google can better use it outside of your site

  7. Roam’s markdown export doesn’t contain in-page the block references or block embeds. It does contain ID’s to them; Obsidian does not resolve those on import. So that’s a part you lose. But yes, I’m very happy with the idea there’s at least Obsidian to import the markdown in and make it workable.

Leave a Reply

Your email address will not be published. Required fields are marked *