Migration

Summary

Sakai has made a firm commitment to developing comprehensive migration paths from Sakai 2 to Sakai 3. The key characteristics of this migration are

  1. To provide the smoothest transition possible for instructors teaching with Sakai -- put the user first.
  2. To allow for varied migration paces among institutions or schools -- not every department will be prepared to make a transition at the same time -- meet the user where they are.
  3. To allow for blended sites where innovation can be introduced piecemeal while still maintaining consistency from previous terms -- to help address the retraining issues, allow implementers to control how and where new functionality is exposed.
  4. To provide data migration tools that will allow for a wholesale transferal of user content from Sakai 2 to Sakai 3.

Approaches

The following approaches are listed roughly in the order in which progress can be made; i.e. Hybrid mode can be accomplished today, while export/import will require longer term development, etc.

  1. Hybrid mode
    1. Two instances running side-by-side -- Sakai 2 and Sakai 3.
    2. Will allow Sakai 2 tools to be exposed within the Sakai 3 portal.
  2. Export/Import
    1. This would allow an instructor teaching a course in Sakai 2 last semester to import that structure into Sakai 3 this semester.
  3. Data Conversion
    1. Will require that the Sakai 3 data model is well understood (i.e. "finished") and thus will be the last phase of the migration project.

Status

The various approaches are in the process of being explored, documented, and developed. Please continue to watch this space for updates.

Bread Making

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Sep 16, 2009

    Lance Speelmon says:

    After some discussion with Clay Fenlason, it became clearer that there are actua...

    After some discussion with Clay Fenlason, it became clearer that there are actually two phases of hybrid mode - one being just separating project sites from course sites and then secondly the exposure of Sakai 2 tools within the Sakai 3 portal.

    1. Sep 17, 2009

      Clay Fenlason says:

      Should this call for a separate set of technical requirements, or are they the s...

      Should this call for a separate set of technical requirements, or are they the same in either case?

      1. Sep 18, 2009

        Lance Speelmon says:

        That is a good question. Can you describe in a sentence or two how you envision ...

        That is a good question. Can you describe in a sentence or two how you envision the initial GT hybrid? Will users need to know which instance to connect to? If not, what happens when a user clicks on a course site from within the Sakai 3 portal? Will it redirect them to the Sakai 2 portal? Thanks, L

        1. Sep 20

          Clay Fenlason says:

          I'm not certain of the right mechanisms, but my naive imagination includes the f...

          I'm not certain of the right mechanisms, but my naive imagination includes the following on the functional side:

          • there will be one URL for the whole system, and users will not need to know which they are connecting to.
          • clicking on a course link in the 3 portal would take you to a single 2 site, i.e. there would be no 'My Workspace' or site tabs for the Sakai 2 portal
          • such course sites should include the header bar available in 3 (i.e. 'My Sakai', 'Courses & Sites', etc.), as a consistent way to return to the dashboard from any given site
          • both the 'My Sites' (or whatever it's called) widget on the dashboard and searching courses/sites from the header bar should work against 2 sites

          I think the header bar will be dangerous in 2 contexts to the extent that it creates an expectation that content is really shared between the systems, so we might need to look for a way to disable certain portions of it with some explanation where needed, and that could be disruptive, but I think a lesser of two evils.

          1. Sep 21

            Lance Speelmon says:

            It seems to me that you want one portal that front-ends both the Sakai 3 hosted ...

            It seems to me that you want one portal that front-ends both the Sakai 3 hosted project sites as well as the Sakai 2 hosted course sites. So regarding the question of technical requirements and whether this was one or two sets of requirements, we need to answer one question: Which portal is responsible for painting the tool list for a course site? I believe this is the only concern which might cause a deviation from the current set of requirements. The current vision outlined by Ian places this responsibility in the Sakai 3 portal (I assume for a better UX). Maybe John has some insight on this particular concern...  Thanks, L

            1. Nov 15

              John Norman says:

              Unfortunately, I don't know if Ian's preference is guided by a technical conside...

              Unfortunately, I don't know if Ian's preference is guided by a technical consideration. But setting technical considerations aside, I see an initial stage where Sakai 2 sites are complete and unchanged (I think this is what you mean with Sakai 2 portal controlling the tools). I assume this is the easiest. The user experience would be "I'm visiting a classic Sakai course site"

              Later, I imagine that we may have a simple course environment working and we just need to add (say) Tests and Quizzes from Sakai 2. At this point the Sakai 3 portal would be in control and place a Sakai 2 tool widget in a Sakai 3 site. In order for this to work I imagine we would need a "shadow" Sakai 2 site, but the user experience would be such that the "classic site" experience would be gone (unless they choose a 1 widget per page layout to reproduce the "classic" site in 3).

              If going straight to the second option is easiest, then let's try it. If not, I suggest we make sure we can do the first option so we have something and try the second option afterwards.