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

DATA ISN’T THE DATA FORMAT

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.

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.

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.

SOMETIMES THE TOOL IS THE DATA

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.

DATA EXIT STRATEGY

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?

UNIQUENESS OF A TOOL

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.