Migrating to a new VLE

[Migrating to a new VLE] | [Planning the implementation] | [Implementation models]
[Migration experiences] | [Migrating content]

Migrating to a new VLE

One of the possible outcomes of your VLE review is that you will be changing to a different product. This is a major undertaking whether the new VLE constitutes a major upgrade to your existing system or is an entirely new product from a different supplier. Full guidance on conducting a system implementation is outside the scope of this Toolkit. Here we aim to give a layperson's view of the tasks to be undertaken in order to help different stakeholder groups understand one another's roles and undertake joint planning.

Planning the implementation

Once you have chosen a new VLE, your work is only just beginning. Your implementation team may include a core of people involved in the selection project but many others will have a part to play. Some institutions have been tempted to hand over responsibility for implementation to information services departments but the clear message from participants in our research is that such projects need a strong learning and teaching focus. You will be working closely with your new supplier and may have a complex set of relationships to manage if you are also winding down a previous contract. Below is our list of points to be considered when starting to think about migrating to a different system. Some of these are covered in more detail below and in other sections of the Toolkit.

Pointers for implementation planning

• Establish a steering group and clear lines of authority and responsibility. You are moving into a phase where you will need timely decisions not a vague indication of direction that might be revisited at some point in the near future.
• Control the project scope. If you used a technique such as the MoSCoW approach to prioritising requirements, review this to identify what you need to do at each stage of the implementation and what activities might form future projects.
• Understand and plan for any business process change that might be necessary to make effective use of the new system.
• Decide what implementation model to use.
• Decide what data needs to be migrated.
• Establish how you will fill any gaps between your stated requirements and the available functionality in the new system.
• Establish where interfaces need to be created with other institutional systems and how this will be achieved.
• Involve the right people in thinking about the technical requirements. This will vary according to whether hosting is in-house or via the supplier or another third party. You will need to give technical specialists a clear idea of what to expect in terms of numbers of users carrying out different functions, projected data volumes and likely peaks and troughs in concurrent usage.
• Develop a data access and security model. Very often some of the benefits of a new VLE relate to the idea that more people can carry out more functions in more locations. This will necessitate a review of existing protocols relating to who can access what data and how the system is secured.
• Develop a testing plan. Various types of testing will be required before the new VLE can go live. Probably the best known is User Acceptance Testing (UAT) but you will need many other forms including: preliminary testing; functionality testing; data migration testing; interface/integration testing; performance and capacity testing; and a plan for regression testing following major updates.
• Ensure that the project is adequately resourced particularly in terms of staff time and staff training and development.
• Avoid customisation of the new system at all costs! More on this topic in the section on Delivering the benefits.
• Have a contingency plan so you know exactly what you will do if your go live is delayed for any reason.
• Have a plan for decommissioning your old system.