As yet we have no perfect solution to this problem, and we likely will not for some time, if ever. There is sadly not much incentive to do so. There are projects like atJSON that aim to make more sophisticated interchange formats beyond simple markdown:
The Tools for Thought Interchange discussions are talking about this and other potential solutions:
So there is certainly interest in and work toward solving these problems. But again the incentives for adoption are questionable, especially at larger, established companies like Google, or even Notion, etc.
That being the case, my own personal approach starts with trying to estimate how much value (in e.g. time saved, or capabilities enabled) a given system or tool brings to my life and work, and that helps establish a baseline for how much risk it is worth taking on any proprietary aspects of that system/tool. In general for personal tools I accept less lock-in than for business, which is interesting, and honestly not something I have really introspected much about. It’s just kind of how it has developed in my life… Something to think more on!
Anyway, then to try to backup as much data as possible, I focus on determining the most important aspect(s) or qualities of the content (usually the actual text, i.e. not the formatting), and then trying to backup/export content from any tools I use into a format that supports those aspects. In some cases this necessarily results in e.g. images (for situations where the visual representation is most important), or PDFs, but mostly it means markdown. I lose some things this way, but it feels like the best trade-off between preservation of key qualities of content, and time spent building, maintaining, and using systems to preserve more qualities of that content.
Basically I ask myself: “If I lost X quality of this content tomorrow, how much would that affect my ability to utilize this content?” In most cases the answer is “not much” or “some, but not critically”. The actual text content is almost always the most important quality. But in some instances, such as a highly formatted and complex legal document, the actual text structure and formatting, while not critical to its value, is still extremely important. If you’ve ever tried to copy/paste some of the contents of e.g. a PDF contract into another doc to reuse it, you probably know what I mean! So these get preserved either in PDF, or if I have access to the original document, then in e.g. MS Word or GDocs. I accept the limitations of those proprietary systems and formats by necessity.
I think my greatest unresolved concern right now probably arises in relation to information held in databases, especially when there are proprietary models of interaction involved, such as “embedded blocks/references” (Roam, RemNote), or particular functionality that arises from how a system handles relationships (Fibery). Some of these systems don’t even provide e.g. CSV export for their database structures, only markdown, so there I think it’s more important to assess the lock-in risk. I don’t have a really great way of handling these things yet, to be honest. I simply accept the risk and try to stay up-to-date on and involved in the communities of the tools I use so that if there is any sign of e.g. the company going under, being bought, or even increasing stability/availability issues, then I can start to work on moving my data if needed. But moving data in these systems is often a manual process, at least in part. That is simply one of the costs of accessing the advantages these systems bring.
Having said all that, another thing that factors into my perspective here is a philosophy I have developed over the last few years, as I have moved between systems. I used to see this as a major headache and source of inefficiency, especially since most of the time I ended up having to resort to copy/paste between tools, or at best a lot of manual cleanup of text after an import process. I moved from Redmine to Quip to Notion/Roam, a brief diversion into Logseq, then to my current focus on Obsidian (markdown is, at least, common between them, but there are still formatting differences at the least, and sometimes worse).
What I came to realize is that, although it is time consuming and sometimes frustrating, moving to a new system is as much an opportunity as it is a problem. It is an opportunity to improve and refine your content, structure, and systems. “Touch” each document and folder, see it anew, with fresh eyes. Consider how it is currently organized, how easy it has been to find, access, and utilize to-date, and whether you could make improvements to any of those aspects, especially if any of the new capabilities of your destination system can help, or allow some new way of doing things. Consider, too, whether you even need this object anymore - can it be archived, or even outright deleted? Or are you holding onto it for someone else and can give the responsibility back to them?
Obviously this kind of optimization can be done piecemeal after a more bulk or automated export/import process, and there is value in that too. However we humans are notoriously bad at just intuiting where things can be improved. Being forced to actually engage with each piece of our knowledge architectures surfaces more well-hidden (but often no less important or transformative) areas for improvement.
So, even though I still get frustrated by having to move to a new tool, I also try to look at it as an opportunity, and try to imagine how much things may be improved and be more enjoyable and efficient to access when I am done. The honest truth is I am still in progress on a prior migration, and this has been the case for quite some time, so my philosophy is interesting and valuable but not necessarily always easy to implement. But I think it’s a good thing to at least keep in mind, and try to strike a balance between the efficiency of migrating, and the value of actually engaging with everything that you are moving.
The thought occurs to me that I left out at least one consideration that can be useful, which is to try to estimate how likely a given company/service is to A: be around in a few years and B: either gain or lose export (or import) options.
So for example with Google, I know that they are likely to be around for quite some time, and they actually have a fairly long-lived and sophisticated export system with “Google Takeout”. And that might make one feel a bit more secure trusting them with one’s data, to a point (setting aside issues of privacy). But on the flip side Google frequently “retires” products, sometimes ones that seem to even be successful and well-liked (GReader). To be fair they usually give a decent amount of warning time and provide aforementioned export options, but this is a risk one really needs to keep in mind with Google products.
Now some random early-stage (in the first 1-2 years) startup, while I might really like the product, has a high likelihood of actually not succeeding and going under completely within a 5 year time horizon. I would estimate a company like Notion falls somewhere in the middle as far as likelihood of longevity: they have a lot of interest and users, but a rocky last couple of years of development. I could see them being acquired and the service ended or merged into something else within 5 years, but I could also see them lasting that long. It’s maybe 50/50, as an off-hand guess.
It’s not always easy to estimate these things. Evernote might be a good example. They have established longevity, yet their long period of stagnation seemed to almost lead to their end, at least as a relevant platform. They’re trying to claw their way to competing in today’s market again, but it’s questionable whether they’ll succeed. Still, they have enough loyalists that they’ll probably stick around. But I’ve seen companies in their situation do desperate things like kill all export options to try to retain users by locking them in, and this becomes increasingly likely with changes of leadership who often come in wanting to make sweeping changes to try to “right the ship” quickly.
In the end one’s access to a system that one does not control can be taken away at any time. There are fair estimates of the likelihood of that, but it can never really be put at zero. So backing up/exporting regularly is always a good idea.
Also I should say that I generally don’t lay out all of these considerations in a formalized way like a spreadsheet for comparison, at least not in most cases. If the decision seems especially complex or unclear, then I may, but mostly it’s just an intuition that tries to take these factors into account.