A learning platform usually arrives as a modest thing. Somewhere for staff to share materials and track progress, managed by a small team.
Then it grows up. As digital education moved to the centre of how institutions teach, the platform grew with it, from a teaching tool into a piece of core infrastructure. Somewhere along the way, for a lot of institutions, keeping it running stopped being a task and became a standing commitment. In practice, a permanent project.
The effort that became normal
The thing about a standing commitment is that you stop noticing it. None of it feels remarkable, because it has always been there.
The annual upgrade is the clearest example. At William Jewell College, the IT team had to take Moodle offline for several days every year to complete it. Downtime on that scale gets filed under “just how upgrades work”, even though it costs the institution real availability and the team real time.
Ever since our switch to D2L Brightspace, our workload on the admin and faculty side has decreased exponentially. We used to have to backup and reset each class every semester. Now, each iteration of a class has its own separate course shell. We have seen more engagement with content, and a wider variety of learning activities being used, including Video Assignments, and Group Assignments being built into the LMS.Andrew Edwards Director of Teaching and Learning Technologies, William Jewell College
The scale of the work is easy to underestimate. The UCISA 2024 Digital Education Survey found that responsibility for delivering digital education now touches over 166 distinct roles across UK institutions, and named staff time for development as the single biggest barrier the sector faces.
Control, and the responsibility that comes with it
Teams value the control an open platform gives them, and rightly so. When many of these environments were designed, that control was a real advantage, and the service providers around them are often genuine partners in keeping things running.
But with great power, comes great responsibility. When accountability is shared across internal teams, hosting and plugin developers, it can be hard to say where it lands when something fails. This also creates fragmented risk – you can’t measure what you can’t manage.
That is the trade many teams are weighing. Of 93 institutions that moved from Moodle to Brightspace, 73 cited partnership and support as a primary reason. Control still mattered to them. What changed was the weight of carrying it alone.
We’ve never felt like D2L is trying to sell us a product. Instead, they’re partnering with us on a solution.Mark Schneider Director of Learning Technology, NAIT
Every plugin is a promise to maintain
Extensibility is one of the genuine strengths of an open platform. Plugins have enabled institutions to create highly tailored learning environments. But every additional integration also becomes something that needs testing, monitoring and maintaining over time.
Each plugin is another moving part, and another dependency. A core update can break compatibility, which means another round of testing and patching on a deadline. Some plugins rely on external developers or community goodwill to stay current, so part of your platform’s future sits outside your hands.
According to OECD analyses on governance of complex digital systems, highly customised environments tend to gradually increase the cost of technology maintenance, especially when different components need to evolve in parallel.
Every week spent maintaining infrastructure is a week your team isn’t working on AI initiatives, analytics, student experience or strategic projects. The pattern is consistent: the more customised the environment, the higher the long-term cost of keeping it running.
What openness costs you
Moodle’s codebase is public. Anyone can read it, which is also true of anyone looking for a way in.
The NIST National Vulnerability Database lists 580 documented vulnerabilities for Moodle, including session hijacking, pre-authentication remote code execution, credential leaks and database takeover risks. Brightspace has one.
When something needs fixing, D2L pushes the update. There’s no patch to schedule, and no plugin maintainer to wait on.
Accountability follows the same pattern. With Brightspace, D2L owns platform security end to end. There’s no ambiguity about whose job it is when something needs fixing.
That ownership is independently verified. Brightspace was the first major LMS to achieve ISO 27001 certification, and D2L has held it continuously since 2014, alongside ISO 27701, 27018 and 27017, SOC reports and CSA STAR assessments. For a more complete picture, see here.
From maintenance to moving forward
Underneath all of this is a question about capacity. Every hour spent keeping the platform alive is an hour not spent making it better, or making anything else better.
So before the next upgrade cycle begins, it’s worth asking the question: how much of your efforts goes towards keeping the platform running, and how much is left for the work that moves it forward?
See what changes when the platform stops being a project. Brightspace is built to reduce the operational weight your team carries — fewer manual upgrades, fewer plugin dependencies, and a partnership model that means you’re not solving problems alone. If you’re weighing up where your capacity goes next, it’s worth seeing what a purpose-built, fully supported platform looks like in practice.
Explore our Brightspace integration extensibility map.
Written by:
