Thanks to Adam Marshall of Oxford – the Sakai developer list recently started a discussion about an exit strategy for an organization which adopts Sakai.
Not because Oxford is thinking about exiting Sakai before it even enters – but because planning and documenting an exit strategy from any IT choice is a responsible thing to do – and is best done *before* you adopt the software :).
Here is my response – feel to use/adapt this text in any way you like.

This is a great question and one (as others have said) where open source should have the best possible answer IMHO.
Here are several theme areas:
(a) IMS Common Cartridge in the future will be a great vehicle once it is widely adopted and it has sufficiently rich content types. Of course Sakai only has limited IMS CC import (Thanks Mark, Zach, Unicon, and others) – wanting a good exist strategy for any LMS is a good reason for folks to get involved in IMS CC efforts in the standards making or in the software development (yes I am an IMS contractor :) ). But IMS is not the sure solution for now. In the future if we can get IMS CC adopted widely – it can be both you exit strategy and entrance strategy all rolled into one.
(b) Sakai from the very beginning has provided its own proprietary archive/export tool for the system admin – this is our own format – but it gets 100% of the content for those tools that properly support archive. If I were to switch from Sakai right now – this is the route I would take – make a gigantic export – getting all of the files and metadata and then write some Python scripts to munge this into whatever form you needed. Because Sakai is open – you are 100% encouraged to reverse-engineer this format and bend it any way you like – even though you are exiting – we would be happy to host that code in our contrib repository – so others could follow out the same door with less effort.
(c) Write a special bit of code in Sakai to export into whatever format you needed. This is how Indiana got from OnCourse to OnCourseNG (now called OnCourse Classic and OnCourse respectively) – they added a special export bit to their old system that made stuff importable in the new system. The advantage of this approach is that if the new system is not particularly standards compliant or the standards based import does not transfer 100% of what you want – you simply make the connection with all the data that is fit to transfer. In addition if there are tools (some) in Sakai that do not participate in the system archive capability – then you just call the APIs in your tool and export the bits you want. Again if you want to develop this code – please put it in contrib so all can benefit.
(d) One last and more long-term approach which I would like us to think about is the HTML-only option (Luke alluded to this). We have no support for this right now in Sakai :( :(. This is one of (many) things that impressed me about Stellar and impresses me about LAMS. All tools have a way to produce HTML Stellar uses this for materials that are several versions old – Stellar runs several versions of its services and UI at the same time (kind of like running Sakai 2.3, 2.4, and 2.5 on one system) – but for older versions that are no longer running in Stellar – stellar converts the sites to flat HTML – and since Stellar has a very good REST-style URL naming scheme – the HTML simply lives at the same URL as it did when the data was live and editable – in effect what you see is a non-editable version of the site at the same URL as before. For LAMS the thinking is more of a tool-by-tool basis and is intended for portfolio applications – you do something great in a discussion in a class – you snag that discussion as a bit of HTML and pull it into your portfolio. Brilliant. Taking this approach would also allow bits of comments/metadata to be in the HTML so that the HTML could be somewhat imported into a new system – kind of like blog programs scrape each other’s HTML to convert you from one blog program to another. Note that Sakai has none of these HTML features — yet.
Frankly IMHO we should be developing these kinds of things regardless of whether schools want to “exit” Sakai or not. Because as faculty move from organization to organization – they end up “exiting” in the small – as faculty depend increasingly on systems like Sakai and Moodle – a move to a new school, losing all one’s content is pretty not good.