Notes from Saturday July 11th Sakai 3 Migration BOF
Scribe: Steven Githens
These notes are still raw and haven't been updated to Confluence markup yet.
Accepted Statement: Hybrid mode is the only acceptable mode for early adopters.
Q. What is Hybrid Mode?
A. Sakai 3 with collaborative sweetness having the ability to run Sakai 2 tools inside of the set somehow.
We have 25 minutes to set some goals:
1. 'Expose' Sakai 2 tools in Sakai 3.
2. Key data will be migratable, other data can be exported in some archivable format.
3. You can eventually turn off your Sakai 2 server.
4. Investigate Common Cartridge and parts that can be supported for this task.
Migration is not necessarily a binary state, it will be more of a fluid evolution, moving faculty classes over in bits and bits. This is not really 1 migration, but many mini migrations.
The ability to "embed" or "expose" Sakai 2 tools in Sakai 3 is an important goal.
This is sort of what LTI stuff does. However, thinking from a UX perspective...
There are lots of custom tools that are just not going to get rebuilt. And these need to be made available.
Each institutoin will have to consider the technical and UX ramnifications.
Just using the Sakai 3 portal may actually improve some Sakai 2 issues (hidden tool divs with back buttons etc)
Specific tool migration questions. We need to break down the assumptions of specific tools items. (Will Assignments port straight over? Resources?)
Assumption: We will need to retrain our users under a new UI, even if the data and functionality are all transfered.
The Botimer Differentation and Model Shift Corollary:
1. Finding course stuff, and...
2. Doing specific tasks, a conceptual shift between 2 and 3.
A big issue:
How can we get this Sakai 2 server shut down? Running a legacy system side by side a new system is a huge resource drain and challenge. The data migration has to go in hand wit the UX change.
Schools have varying data retention policies? How long does a particular thing have to stick around with full parity. The difference between just keeping the data and keeping the exact same UI and workflow around.
Portfolio is a good place to start research on how long data can go before we can drop it off the map.
The concept of porting some data will not work with new paradigms. Some stuff might have to be left behind.
We could think about having more firm standards for data storage so that the schema of storage is not so specific to Sakai 2 that it can't be used in a tool that operates under a different paradigm workflow.
Can we find a data portability standard that we can use for moving these things over. (This is an open philosophical question in addition to pragmatic ).
Some of the data could be moved over read only. You could still access the data from a threaded discussion, but not add to it and continue it in the newer system.
What if you can move the structure and pretemplated data for a faculty member, so they don't have to retype their discussion topics etc. (Even if the forum thread data itself didn't all move.
We should look at the Moodle import/export format for inspiration since it is pretty sweet and thought out. We don't want to be in the business of trapping users.
Single Portal, no code changes for Sakai 2 Tools.
LTI enables this
The Nico Profoundness:
This shouldn't only be a technical issue, at least half of this data migration should be really thinking about how this data will transfer and the new innovation that can be made in the UI to support it.
Also, we must make sure Sakai 3 doesn't just turn in to a Sakai 2 wrapper.
This is not the ultimate answer, but a means to make the transition.
This upgrade Model is unlike anything you have ever experienced!!
This avoids the Osborne Effect. Our upgrade is so awesome, you shouldn't be afraid to adopt Sakai 2 now.
The BOF is almost over. It's really over now.