Guidelines for Migrating

TUTORIAL 4

GUIDELINES FOR MIGRATING TO AN OPEN SOURCE LEARNING CONTENT MANAGEMENT SYSTEM

To improve the tutorial, please add comments at the end of this page. To obtain additional information, please write to Tony Bailetti at bailetti@sce.carleton.ca.

ACKNOWLEDGEMENT

Thanks to Sinead Averill (Ireland), David Bolter (Canada), Jan Donio (Canada), Claude Martin (Italy), Glen McInnis (Canada), Vitaliy Rabotnik (Canada), Steve Roberts (Australia), Ken Udas (New Zealand). They made insightful comments on a previous version of this tutorial.

ACRONYMS

FOSS = free open source software

IT = information technology

LCMS = learning content management system

OBJECTIVES

The objective of an open source LCMS migration project is to substitute a proprietary LCMS for an open source LCMS in an organization.

Upon completion of this tutorial, you will know about the roles or functions involved in the migration to an open source LCMS and the work that needs to be done. You will also be able to contribute to the planning of an open source LCMS migration project.

The objective of the tutorial is to identify what can be done rather than be prescriptive of what should be done. The tutorial provides a good start to the process of migration. However, it should not be expected to provide answers to all migration-related questions.

TARGET AUDIENCE

This tutorial has been designed to help information system managers, senior administrators, and advocates of open source guide their organization’s migration to an open source LCMS. It may be also benefit the members of the members of the project team responsible for the migration.

EXCLUDED

This tutorial is not a technical reference manual. It has been designed so it can be easily modified as more experience with OPEN SOURCE LCMS migration is gained.

This tutorial focuses specifically on LCMS migration, not on a large scale, enterprise-wide infrastructure migration. Individuals interested in knowing about large-scale open source migrations are encouraged to read Dedrick and West (2003), Fitzgerald and Kenny (2003a, 2003b, 2004), and netproject (2003).

The tutorial assumes that the objective of the migration project is to operate an open source LCMS. If the objective is to concurrently operate an open source and a proprietary LCMS, the tutorial needs to be modified.

RELEVANCE

Open source migration is not just about technology and open source software licenses. It is also not about people with good intentions working together. The open source migration project is part of a serious effort to change an organization.

Organizational-wide efforts to migrate to an open source LCMS, should be established as a project. The migration project should be managed as an important organizational project, not as a technical project. A migration project team identifies the stakeholders served by the migration, defines the requirements, and writes a plan of how to complete the project.

A stakeholder refers to an individual or group who stands to gain or lose due to the migration to an open source LCMS. Throughout the open source migration project, the team needs to be in contact with the project’s stakeholders to ensure that the it stays aligned with organizational goals, priorities, and expectations.

ROLES IN AN OPEN SOURCE MIGRATION PROJECT

In this section the five functions or roles of an open source migration project are identified. These roles are: leadership group, champion, project leader, project team member, and process owner.

Leadership group

The leadership group is comprised of senior managers gathered in a forum (e.g., Steering Group, Coordination Committee). The leadership group plans and executes the open source migration plan.

The leadership group:

• develops a strong rationale for migrating to an open source LCMS that is specific to the organization’s needs
• creates a vision for the migration plan and promotes change inside the organization
• sets clear objectives
• selects and supports the champion of the open source migration project
• appoints the open source migration team leader and the process owner
• holds itself and others accountable for the migration project’s success
• demands results
• communicates results

Champion

The migration project champion is a senior manager who oversees the migration project and is accountable to the leadership group. The champion’s role is a delicate one.

The champion:

• defines the rationale and goals for the open source migration project that align with the organization’s priorities
• approves changes to the migration project
• finds resources and data for the project team
• advocates the project team’s efforts
• overcomes bureaucratic roadblocks
• works with other managers to ensure that the migration to open source proceeds smoothly

Project leader

The migration project leader is responsible for the day-to-day roll out of the open source migration project.

The project leader:

• clarifies the rationale for the project migration
• develops the open source migration plan and the work breakdown structure
• recruits and trains members of the migration project team
• works with migration project team members and supports them
• ensures the migration project team uses its time effectively and maintains project schedule
• documents project progress and final results
• supports the project champion
• obtains buy-in for the migration project from stakeholders.

Team member

A migration team member is responsible for doing the work required to migrate from a proprietary LCMS to an open source LCMS. A few of the team members are assigned to the project full time, most team members work in the migration project part-time. Team members are drawn from various functions and departments of the organization.

A team member:

• carries out work assigned to him/her
• participates actively in team’s decisions
• listens to others and adjusts his/her actions to what others say
• reviews the efforts of the team.

Process owner

The process owner is responsible for managing the change across the organization that goes hand in hand with the migration to open source.

The process owner:

• communicates plans
• assists the development of training materials
• plans and executes training
• ensures that support for staff, student, administrative and technical staff is adequate
• documents organizational progress
• assesses how the migration to open source affected the organization’s pedagogy, technical infrastructure, and innovative capability.

OPEN SOURCE MIGRATION PLAN

The organization-wide migration from proprietary to open source LCMS should be undertaken as a project with clear outcomes. The migration project plan needs to address technical, pedagogical, and socio-political concerns, not just technical concerns. The open source migration plan describes the set of initial relevant conditions, the set of target conditions, and the way the organization will move from the existing to the target conditions.

The open source migration plan is comprised of four stages:

1. Project definition
2. Establish beachhead
3. Expand beachhead
4. Deploy widely

At each stage, the project plan includes activities that can be grouped into six types:

1. LCMS and IT infrastructure
2. Learning objects
3. Support and training
4. Project
5. Organizational
6. External

The remainder of this tutorial identifies the main activities included at each stage of the open source migration project.

STAGE 1: PROJECT DEFINITION

LCMS and IT infrastructure

1. Define initial and target conditions in terms of system architecture (i.e., operating system and databases) applications, protocols and standards used, hardware, security, remote user identification, backup policy, mobile user support, and the physical environment (i.e., network bandwidth, location).
2. Select the open source LCMS and publicize the reasons for the selection.

Learning object

1. Define initial and target conditions in terms of data, learning object architecture, and types of output that the LCMS will support (e.g., Web output, XML output, CD-ROM, offline courses, print-based, formatted lesson plan, Word output, PowerPoint?? output, Pocket PC, Formatted student guide, and PALM).

Support and training

1. Identify the stakeholders that need to be supported and trained as well as their expectations.

Project

1. Identify a senior manager responsible for the migration project -- the more credible, the better.
2. Identify a project team leader –the more experience in FOSS and learning pedagogy, the better.
3. Set clear outcomes for the end of each stage.
4. Allocate budget.

Organizational

1. Develop a clear understanding of the reasons for the migration.
2. Develop a clear business case for the migration including the cost of the existing proprietary solution, the cost of the proposed open source solution, and the strengths and weaknesses of the proprietary vs open source solutions.
3. Establish a multidisciplinary migration project team with the right skills that has senior management’s support.
4. Obtain buy in from key stakeholders, particularly top managements, IT personnel, and owners of courses that need to migrate.
5. Agree on migration path (e.g., by programs, by location) and on an approach to cut-off the old proprietary LCMS (e.g., phased, big-bang).
6. Agree on one or more pilots designed to test the migration plan and the justification for the migration.

External

1. Develop access to external expertise.
2. Develop links into the open source community, particularly the community that supports the open source LCMS selected.

STAGE 2: ESTABLISH BEACHHEAD

LCMS and IT Infrastructure

1. Examine the portability of file formats.
2. Produce templates for outputs and use them to check whether or not the open source LCMS does what the old proprietary LCMS does.
3. Integrate LCMS with administrative systems.
4. Formally evaluate the system and interactions with other systems.
5. Decide on types of outputs the LCMS should support.
6. Demonstrate functionality that could not be done before.
7. Experiment with the grid and the tools for migration.

Learning object

1. Low level design of learning objects.

Support and training

1. Define the level of support and training that is required.
2. Identify internal and external personnel who will deliver administrative and technical support as well as user training.
3. Identify the internal and external communities that can be relied upon for troubleshooting.
4. Prepare training manuals, highlighting changes between proprietary and open source LCMS.
5. Provide lead projects strong support and training.
6. Obtain data from lead projects on user reaction and costs, and then validate or modify target conditions.
7. Provide users pedagogical support and training via workshops, documentation, and a helpdesk (i.e., telephone, e-mail).
8. Establish internal open source community.

Project

1. Assign a project team to drive the open source migration project. The team makes final decisions on what new features to be added, priority, and evaluates code submitted by the external community.
2. Decide on the speed of the migration process and how long both LCMS will run concurrently.
3. Consult with the users, take their concerns seriously, and modify the project plan to incorporate their feedback.
4. Monitor actual outcomes vs. expected outcomes and undertake action to improve project.

Organizational

1. Understand the target environment, including licensing schemes.
2. Provide incentives to use open source for internal projects and collaborative teaching and research.
3. Select lead projects in contained environments with a small number of users.
4. Encourage all users to experiment with the open source LCMS.
5. Highlight benefits and successes of new open source LCMS.
6. For each unit, define how the new open source LCMS will support teaching and research activities and the implications to them of the open source migration.
7. Identify details of roll out plan.

External

1. Undertake teaching and research activities using the open source LCMS with external partners.

STAGE 3: EXPAND BEACHEAD

LCMS and IT infrastructure

1. At each stage of the expansion, verify that the open source LCMS functions properly and interoperates properly with other organizational systems.

Learning object

1. Transform a course to run on open source LCMS, test, and when convinced it is running properly, cut it off from the old system.
2. Move the difficult things first (e.g., conditions in WebCT).
3. Migration of legacy materials, including course materials and website materials.
4. Develop migration tools and templates (e.g., convert MS SQL data to MySQL data).
5. Convert MS SQL stored procedures to PHP procedures (e.g., WebCT course structure to open source course structure).
6. Define templates for the transition for specific proprietary systems (e.g., WebCT and Blackboard) and prioritize steps.

Support and training

1. Establish the help desk as a center of excellence and good practice.
2. Prepare a “tips and how to” material and post on the organization’s intranet and encourage users to update them.
3. Monitor user feedback and immediately fix problems as they are identified.

Project

1. Keep users informed.
2. Help users overcome fears of the unknown.
3. Help system administrators overcome fear that their resumes will be diluted because they no longer work with proprietary systems and thefear that they are losing control over LCMS functions.
4. Monitor actual outcomes vs. expected outcomes and undertake action to improve project.

Organizational

1. Provide incentives for external collaboration.
2. Roll out the FOSS LCMS to the administration first.

External

1. Monitor forums that support the open source LCMS.
2. Undertake teaching and research activities using the open source LCMS with external partners.
3. Host courses with functionality not supported by the new open source LCMS, and superficially integrate the host system into the open source LCMS.

STAGE 4: DEPLOY WIDELY

LCMS and IT infrastructure

1. Discontinue the old proprietary LCMS.

Learning objects

1. Ensure library capability is adequate.
2. Support and training
3. Technical and pedagogical support for institution wide use of open source.

Project

1. Evaluate actual project outcomes vs. expected outcomes and establish improvement plans.

Organizational

1. Evaluate actual organizational outcomes vs. expected outcomes and establish improvement plans.

External

1. Develop external networks comprised of service providers and advanced users of the open source LCMS.

REFERENCES

Dedrick, Jason and Joel West (2003) Why Firms Adopt Open Source Platforms: A Grounded Theory of Innovation and Standards Adoption. Proceedings of the MIS Quarterly Special Issue Workshop Standards Making: A Critical Research Frontier for Information Systems. Seattle, Washington, December 12-14.

Fitzgerald, Brian and Tony Kenny (2003a) Open Source in the Trenches: Lessons from a Large Scale OSS Implementation. Twenty Fourth International Conference on Information Systems, p. 316-326. http://is.lse.ac.uk/events/ESRCseminars/fitzgerald.pdf Accessed July 9, 2004.

Fitzgerald, Brian and Tony Kenny (2003b) Open Source Software can Improve the Health of the Bank Balance – The Beaumont Hospital Experience. http://www.netproject.com/docs/Beaumont.pdf Accessed July 9, 2004.

Fitzgerald, Brian and Tony Kenny (2004) Developing and Information Systems Infrastructure with Open Source Software. IEEE Software. January-February, p.50-55.

McMullin, Barry and Morag Munro (2004) Moodle at DCU. Dublin City University. April 22. http://odtl.dcu.ie/wp/2004/odtl-2004-01.html Accessed July 9, 2004.

Netproject Ltd. (2003) The IDA Open Source Migration Guidelines. European Communities, OSPL/EEC-01.10, November 8. http://europa.eu.int/ISPO/ida/export/files/en/1618.pdf Accessed July 9, 2004.

Pande, Peter S., Neuman, Robert P. and Roland R. Cavanagh (2002) The Six Sigma Way: Team Fieldbook. McGraw Hill: New York.

---

PLEASE PROVIDE YOUR COMMENTS IN THIS SECTION

Suggestions on the topic of Accessibility

• When discussing assembly of a multidisciplinary team, you might mention that at least one member should have awareness of accessibility requirements (legislated and/or other requirements).
• In the text about the LCMS and IT infrastructure (in stage 1, project definition) add accessibility: "Define initial and target conditions in terms of data, learning object architecture, accessibility, ..."
• Possibly make accessibility testing part of the BEACHHEAD sections, at least in terms of making sure the migration is not causing a problem with accessibility (but is ideally improving it).
• (all for now, please let me know what you think)

Tony's reply to David: Excellent points, thank you. I will incorporate these points. Please let me know your e-mail so I can thank you. Please send e-mail to bailetti@sce.carleton.ca

---

Suggestions on the topic of champions, communication plan, change agents and deployment

First thing I noted was the Champion being a Senior Manager - not always the case. I didn't notice much about evaluation or quality assurance as an ongoing process. The implementation seems to be a 'forced' change, driven from the top, and I didn't see a lot of activities built into a communication plan (project website, newsletters, showcase days, informal lunches, internal and external collaboration). There could also be room for external evaluation at key stages (ie known 'experts' for both presentations and evaluation - meeting with key groups).

Involvement by change agents in conferences, presentations to create interest and visits from other organisations. Create the atmosphere that it is an EXCITING change, positive. What are the benefits? Shout them out loud. Be PROUD of the decisions and change, and people will start to believe. If external interest comes (media, conferences, other organisations) then internal staff will more likely want to be part of the journey.

The vision is not the mission statement. What would a successful open source implementation look like? If we could have a successful OS implementation, what are the factors that would tell us it was successful? What would bring other organisations running to our door to find out how we've been successful? What does that look like - visualise.

A lot depends on the existing deployment, whether it is central or fragmented. The drivers and growth areas need to be recognised. Effort needs to be put into smaller projects to showcase the change, good new articles. If it's a hard sell, then the seller doesn't really understand or believe in the change.

Steve

Tony's reply to Steve. Thanks Steve. You make good points. I will highlight the communications plan, deployment characteristcs, etc. and address all the points you raise.

---

Suggestion on standards

There is no mention of learning technology standards...even when mentioning "learning objects" which is a typical expression coming from standards

Claude

Tony's reply to Claude: Yes, you are correct. I need to fix this part. Thanks a lot for pointing out the oversight.

---

Suggestions on positioning as general framework and add tools, cases, etc.

I think that perhaps a little disclaimer that we re describing a very general framework in the Tutorial #4 and that each migration and each institution will likely have different methods, vocabulary, etc. Perhaps this is just widely understood. I have no strong comments at this point about the content included in the tutorial. It all seems useful and is probably at the appropriate level of detail. I do think that examples of documents used, scenarios, cases, etc., could make the tutorials more immediacy accessible and useful for practitioners. As mentioned, we will share our blueprint and I will gladly write a short description of our experience. In addition, as we push forward, Richard and I will likely have a lot of insights based on our experience.

Ken

Tony's reply to Ken: Great. I agree, the more tools, documents, cases, tips, and lessons learned that we add the greater the impact that we will make. Thanks lots. Tony

---

Suggestions on cost/economics

Tutorial 4 is very informative, I would include the cost/economic element as part of the migration plan, comparitive analysis with various providers and perhaps a SWOT analysis.

Sinead

Tony's reply to Sinead: SWOT is a tool to which we can add. Adding tools, documents and case studies is a great idea. I will add the economic element as you suggest. Thanks lots.

---

We really like tutorial 4 and would suggest the following small changes as it would be relevant to our group.

1. Secure the services of an external evaluator with expertise in open source who will do formative assessments at various stages and let you know where issues are arising so you can be proactive in addressing them. If this is not possible find a grad student that will at least document the implementation as a case study for others to benefit from.

2. Test against all the required standards, especially accessibility standards as this is a huge issue for many institutions right now, the lack of accessibility of some LMS.

3. In stage one it might be useful to complete a risk assessment identifying possible lack of compatibility, lack of buy in to open source, etc. so that the risk can be managed effectively throughout.

4. In the first stage where you identify the champion, it may be useful under training and development to do an orientation to open source with a rational for those that will be affected by the migration. The idea of building an online community dialogue within the institution about the move and the rational will allow ease of monitoring for issues and also could build momentum.

5. It seemed that the training and development was the only real communications device, seems to us a communications plan for any large systems implementation is always useful.

Jan

Tony's reply to Jan: Thank you for the very useful feedback. I will incorporate the five points you made into the tutorial. Thanks again.