E-learning and LMS blog articles

One of the key decisions for organisations implementing Moodle is whether to host the site internally, leveraging your existing IT resources, or to host your site using a third-party service provider, taking advantage of their expertise.

LMS deployment costs vary significantly based on hosting model, with distinct financial implications for each approach. On-premise solutions require substantial initial capital for hardware infrastructure and software licensing, though they may offer reduced ongoing operational expenses over time. Cloud-based platforms significantly minimise upfront investment through subscription pricing models, yet recurring fees may increase total ownership costs in the long run. However, a hosted LMS from a leading LMS service provider also offers many additonal benefits (such as expert product knowledge and support services).

Here's a quick overview and detailed breakdown:

On-Premise LMS:

• High initial costs such as upfront investment in hardware (servers, storage, etc) software licences and implementation services
• Ongoing maintenance in terms of dedicated IT staff, updates, security, support tickets
• Hidden costs such as energy consumption, hardware repairs, additional staffing
• Scalability can be complex and expensive
• On-premise offers greater control and customisation options but requires more internal resources to manage

Cloud LMS

• Lower upfront costs based on predictable monthly or annual fees, which reduces initial financial burden
• Vendor handles maintenance, updates and security patches, reducing or eliminating need for internal IT support
• Scaling up is very easy, simply need to adjust subscription band, making it perfect for growing organisations
• Accessibility - offers anytime, anywhere, any device access, perfect for remote and hybrid teams
• Cloud LMS providers (SaaS solutions) invest heavily in security and upgrade patches

Cloud-based LMS platforms typically provide an optimal combination of affordability, growth potential, and administrative simplicity for most businesses. Conversely, on-premise deployments might better serve organisations requiring extensive LMS customisation capabilities and those possessing dedicated and knowledgable internal IT resources able to manage complex systems.

In this post we'll jump into greater detail as to what to consider when hosting in house so you can make an informed decision on whether this is the best option for you.

We'll look at items that have an impact on the total cost as well as items, which may not have a direct cost but may impact the total cost of ownership of the system. The actual costs involved may vary significantly depending on your existing IT infrastructure, software licensing agreements (e.g. if using SQL Server) and the skill sets available to you.

Throughout this post we'll use the term LMS (Learning Management System) but these points apply equally to Moodle and Totara Learn, unless stated otherwise.

What do I need to think about if I host my Moodle / Totara Learn site in-house?

1. Servers:

Spec your web server

You'll need a server with sufficient resources for the anticipated load. If you have a virtualisation infrastructure this may be simply a case of adding a Virtual Machine (VM) and the resources as necessary. Adding the LMS to an existing web server may not be ideal as there may be differences in software dependencies – e.g. PHP versions and maintenance requirements for one application may adversely affect the other.

We've assumed that a single-node web server environment will be in use in this post i.e. no high-availability or load-balancing. You should also consider future storage requirements as your users start to use the system more.

Select an operating system

Most of Moodle and Totara Learn's development and support is centred around Linux, making this the default choice if there are no other factors influencing your decision.

However, if all your other systems use Microsoft Windows servers then both Moodle and Totara Learn have full support for this also. You should base this decision on any existing guidelines or policies you have for server operating systems and the skill set of your IT team who will implement and support the site.

Select a database server

The majority of the LMS systems are probably running on MySQL/MariaDB but Microsoft SQL Server and PostgreSQL are also very popular choices with full support. Support for Oracle is limited and not recommended. This decision may be based on your IT teams in house experience or having existing database which you can utilise such as a central clustered server.

Typically, you'll use Apache on Linux or Microsoft IIS on Microsoft Windows. There are other options available such as Nginx and Lighttpd however these are less widespread so it may be harder to recruit staff with the necessary skills or locate third-party support.

You may have a well-specified server in the corner of the office but will that offer the connectivity and security needed for an important application with personal information? If not, you’ll need to evaluate suitable datacentres and manage the relationship with the one you select. Bear in mind that overseas datacentres may seem good from a cost perspective but may not enable you to comply with data protection legislation.

2. Site installation:

Step 1 - Install and configure PHP

Linux distributions include PHP as part of the default packages available for installation. However, these packaged versions may not meet the minimum versions required for either LMS.

On Microsoft Windows servers there is an installer for PHP for IIS. Whilst this makes the installation simple, in our experience this does not install the latest PHP version and the configuration settings need updating to work correctly with either LMS. It would be preferable to download PHP and configure IIS manually.

Step 2 - Install the LMS

Once your web server has been installed and configured you can install the LMS. Obtain the LMS source code and copy this to your web server. You'll need to create the database and follow the documented installation steps specific to your environment. On the web server Apache or IIS will need to be configured with the domain name for your site along with a certificate for secure HTTPS access. Don’t forget a DNS name for your site and you may need to liaise with your networking team to set up firewall rules if Internet access to the site is required.

Step 3 - Configure your site

You can then set up additional functionality or services that may be required. You can install third-party plugins to extend the site's functionality (with the usual caveats about using 3^rd party code) and probably a custom theme to enhance your LMS with your corporate branding. You may also require integration with other systems, e.g. using Active Directory for integrated user authentication.

3. Go-live:

Ahead of bringing the site into production your support teams will need to be ready to handle any issues reported by site users. This may involve some combination of staff training, reference documentation and updating your in-house processes.

A crucial part of bringing the site into production is to make sure a suitable data backup regime is in place so that full recovery of the site is possible and compliant with your disaster recovery policies. If you have performance or availability monitoring you may wish to extend this to cover your LMS site.

With the site in production it makes sense to create a sandbox site ideally on a separate web server where you can test changes without affecting your users.

4. Maintenance:

1. Minor version updates

Moodle and Totara release regular version updates. These are cumulative updates so you can skip releases unless you're affected by an issue that's addressed. Ideally you should avoid becoming too far behind as this can affect the support available. Updates may also include security fixes and you would ideally track announcements and release notes.

Generally, minor version updates do not require a great deal of planning simply schedule a maintenance window, take a backup of the site beforehand and apply the update. If you have a staging environment you'll want to make the change there first.

2. Major version upgrades

Major version upgrades include new features but may have changes that introduce compatibility issues with any third-party plugins or your theme. Consequently, greater emphasis must be placed on the planning and implementation for these than with minor version updates.

Both Moodle and Totara publish the period of support for versions where updates are available. You should perform acceptance testing with stakeholders and resolve any issues before proceeding on to the upgrade of the production site.

3. Plugin and theme installation

Moodle's functionality can be enhanced and extended through a plugin architecture, Totara Learn is the same but there are fewer plugins available. As plugins are third party code released separately to the LMS these may need evaluating on your staging site before installing them for your live users. As with the LMS you should aim to keep your plugins up to date to ensure you have the latest bug fixes and security updates. A backup of your site database should be taken before installing plugins.

4. PHP updates and upgrades

Your web server software should be kept up to date particularly if your server is Internet-facing to ensure any security vulnerabilities are addressed or mitigated. PHP particularly needs to be kept up to date to ensure security fixes are applied and this may be required ahead of an upgrade to ensure the minimum version requirements are met.

Again, these changes should be tested on a staging server ahead of applying them to a production system.

Conclusion:

If your IT team have the skill set and infrastructure resources or are already supporting similar systems then hosting your site in-house may be attractive. When hosting in-house you still have the option of engaging expert third parties e.g. Moodle or Totara Partners to underpin your existing support capabilities or for help with specific work.

If there's no overlap with your existing in house abilities then implementing a system you're unfamiliar with can be problematic, adversely affecting the credibility of your site. In this scenario you can avoid potential headaches for both support staff and users by outsourcing the hosting of your site.

The largest proportion of our clients adopt the outsources approach i.e. we host their site but the great thing about open source is that you’re free to choose to host in house.

Our friendly team of experts are only a call or email away. Get in touch today to discuss how we'll turn your requirements into a great project!