Introduction to launching your LMS

Launching a learning management system can be a stressful process.

A failed launch can cost you both time and money and issues can sever the trust you have with your users, causing them to turn their back on your business.

What’s more, a failed or bumpy launch can stress out your internal team, consultants and external vendors (like Plume), so it’s important to approach your product’s launch with a solid plan.

Having launched over 180+ projects, we’ve learned how to successfully launch an LMS and mitigate the common risks. 

icon
Top tip

If you’re a Plume client and have joined one of our support plans, we’ll be right by your side every step of the way. Just get in touch with your project manager or the support team.

Prepare properly

Preparation is key to a successful launch, and it’s important not to rush it. First, some general rules about preparing for launch:

  • Handover day is not launch day. From handover, we recommend giving yourself 2 weeks to get used to managing the system, train your team, input your content and prepare for an initial Beta launch.
  • You’ll then need to run a Beta launch for a small number of users. This should last 1-2 weeks at a minimum.
  • Fix critical bugs and make “must have” changes way ahead of time. If you leave this too late, there may not be time for us to fully test our code, and this will result in issues that’ll reduce the liklihood of a successful launch.
  • Tell us about your launch date early so that we can allocate sufficient resource to you. If you leave it too late, we may not be able to facilitate this.
  • Never launch on a Friday or in the evenings. Our developers are available Monday – Friday during the hours of 9-5. If you try and launch on a Friday or in the evening, and something goes wrong, we’ll be unable to support you out-of-hours.

So, what will we help you to do in the weeks leading to launch?

Get testing and fix issues early

At Plume, when we develop an LMS, we test as we go. We also dedicate an entire week for testing just prior to handover and will often ask you to review our work. Regardless, for peace of mind and so that you can understand how your content works alongside the technology, we recommend you run your own tests at least 4 weeks prior to launch.

If you’re a Plume client, we’ll be here to resolve critical issues that might arise. There are three types of issues:

Bug fixes

A bug is an error or fault in the LMS that causes it to produce an incorrect or unexpected result.

Some bugs are relatively minor, such as those that impact a very small number of user or that doesn’t stop users from completing a task. These low-priority bugs can be logged in the system, but should often be addressed at a later date.

Medium and high priority bugs should be resolved in priority order with the time allotted to bug-fixing.

Reporting many high-priority bugs very close to launch may mean that they don’t all get addressed, so it’s important to report them and request they are actioned at least 2-3 weeks prior to launch.

Changes

These are improvements to functionality that does work, but could be improved. 

While iteration is key to a successful long-term product, getting to perfect is rarely the goal for a phase one launch; instead, it’s better to launch with the minimum viable product (MVP). Make a note of any non-critical improvements that you’d like to implement later down the line and set these aside for post-launch consideration.

New features

New ideas will inevitably crop up in the weeks leading up to launch, but they’re often isn’t enough time to research, design, develop and test new functionality ahead of this if your launch is looming.

Make a note of these for later consideration.

Set up a feedback mechanism

Before we launch a beta to real users, it’s important to set0up a feedback mechanism to allow users to report issues and provide feedback.

At Plume, we use Marker.io, which will allow both your internal team and end-users to report issues visually. These are automatically pushed to your Teamwork Project for review by both our team and yours.

Set up a session monitoring tool

We will install a session monitoring tool, allowing us to record the screens of users as they use your system – just as if we were looking over their shoulder. 

Being able to watch your user’s sessions back provides incredibly insightful data that can be used to improve the design, functionality and even conversion rate of your LMS product. We can: 

  1. Understand how users use the system so that we can identify user needs that haven’t yet been met
  2. Uncover common friction points that prevent users from completing a task (bugs, usability issues)
  3. Improve conversion rates and sales
  4. Find and resolve bugs quicker

Popular session monitoring tools include Hotjar (includes a limited free plan) and Fullstory.

Remember to mention the use of such tools in your privacy policy

Create a migration plan

If you have users, subscriptions and learner data that you need to migrate to your new system, we’ll need to create a migration plan. This allows us to determine what data should be imported and when, and whether we’ll need to develop custom tools to facilitate the migration.

Migrating users should not happen close to your big launch to new users, since our resources will be focussed on ensuring a successful launch. Instead, we recommend migrating your existing users earlier – potentially in batches – during your Beta period – and then “launch” to new users later on. This helps to spread the workload over a more manageable period of time.

Migration should be planned at least 2 weeks before it begins to take place. This window of time allows us to carry out a dry-run, which helps us to identify issues earlier and then circumvent them on the day of migration.

Beta launch

Before you open up your courses to the masses, start small with a beta launch. There are three key benefits to a smaller beta launch:

  • Any possible issues will impact a fewer number of people and can be resolved without impacting the entire user-base
  • You can prepare yourself and your team with how to manage a live system and troubleshoot issues
  • You’ll be better prepared for a hard-launch and will avouid a lot of stress

Before the beta, let your users know that they are among the first to try this new system and that they may run into a bug or two – they’ll be excited to be trying something new and will be more forgiving of bugs if they are forewarned.

Analyse and action feedback

We’ll help you to analyse and understand the feedback collected via Marker.io and we’ll discuss potential improvements to be made to the product, including bug fixes, UX improvements and new functionality or extensions to existing functionality.

We’ll begin iterating right away, bringing in our consultants, designers and developers to make any adjustments necessary prior to launch.

Hard launch

At this point, you should have had a successful soft-launch/beta and fixed any critical bugs. You’ve collected some great feedback, prepared your team and are confident in your system and courses.

Now is the time to go public with your launch. There are a few things to consider:

  • Think about slowly ramping up user numbers. If you have 100,000 users to migrate from an older system, consider migrating those users in waves over an extended period of time. 
  • If you’re on a Plume support plan, you should let us know your hard launch plans so that we can dedicate resources to support you.
  • With lots of users in your system, it’s not safe to develop new features on a live LMS with real users. It’s time to work on a regular release cycle where new functionality and changes can be safely deployed from a staging environment (a separate installation of your LMS for development purposes).

Don’t do it alone

Poor planning leads to poor launches, and poor launches can damage your customer’s trust in your company.

We’ve launched over 170+ successful projects, so get in touch if you’d like us to develop a fully considered launch strategy for your LMS.