28 Oct LMS migration: six failure points we see again and again
Moving to a new LMS fails in predictable ways. As a Moodle Premium Certified Partner and Totara Platinum Partner, we see the same six failure points again and again. Here is what they are, and how to avoid them.
Picture an LMS migration that went well. It finished on schedule, the courses are all there, learners can log in, and the first reports ran without complaint. Then, three weeks later, someone in HR asks why completion certificates have stopped reaching line managers. Nobody can answer, because nobody knew that feature depended on a change a developer made to the platform’s core code several years earlier.
Data migration has a long record of going wrong. Bloor Research found that more than 60% of data migration projects overrun on time, budget, or both, and identified poor data quality as the most common reason. An LMS migration adds complications of its own: years of learner history, compliance deadlines, connected systems, and customisation that can reach deep into the code.
The encouraging part is that these failures are predictable. We migrate organisations onto Moodle, Moodle Workplace, and Totara regularly, and the same six LMS migration failure points come up again and again.
Why an LMS migration may now be urgent
On 21 October 2026, the National Cyber Security Centre warned of two critical flaws in PHP, the language Moodle and Totara are built on. The flaws allow an attacker to run code on a server without logging in.
For many LMS owners, the required update is more than a patch. PHP 8.1 and older no longer receive security updates from the project. Some vendors offer stopgap fixes, but the lasting answer is a supported version. Moodle 4.1 runs on PHP 7.4 to 8.1 only. A site still on 4.1 or earlier cannot move to a supported version of PHP without upgrading Moodle as well. That kind of jump is where hidden customisations and older plugins tend to surface.
This is where keeping a platform current pays off. We moved all our clients onto the latest supported version of PHP well before these flaws were announced. When the fix arrived, we applied it across every customer platform in a single, smooth update.
For organisations without that head start, urgency is when the six failure points below do the most damage. It’s tempting to skip the audit and the rehearsal to save time. A migration can be quick and careful at the same time, as long as those steps still happen.
1. The customisation nobody wrote down
This is the failure we encounter most. At some point in the platform’s life, someone edited the core code: an internal developer, a contractor, or a previous supplier. The change worked, the person moved on, and the documentation was never written or was lost.
Sometimes the client knows about these edits and can point us to them. Sometimes the outgoing provider tells us. And sometimes we’re told there are none, and the first sign that this isn’t actually the case is a feature that quietly stops doing what it used to after go-live.
When we take on a platform, we receive the database and file data, not the old codebase. We rebuild on clean release code. Anything that relied on a hidden edit stops working, with no error message to warn anyone.
Third-party plugins and themes bring a related risk, since each major release can break them. Moodle 5.0, for example, moved to Bootstrap 5 and added a backwards-compatibility layer specifically to protect third-party plugins and custom code during the transition.
Important
The question to ask: what has been changed, by whom, and what was each change for?
2. The integrations nobody listed
An LMS rarely works alone. It exchanges data with an HR system, signs people in through single sign-on, and feeds reports to managers and compliance teams. Everyone lists the obvious integrations. The less obvious ones can slip through.
The ones that cause trouble are often small: a script that pulls completion data into a spreadsheet overnight, an enrolment routine a department set up years ago, or a reporting tool that reads straight from the database. Nobody thinks of these as integrations until the report they feed goes blank.
A proper review has a second benefit. Some integrations turn out to be no longer needed, and others exist only to work around something the old platform couldn’t do. Both are candidates to retire, or to replace with something new that’s now properly supported.
Important
The question to ask: what reads from or writes to your LMS, including anything that connects directly to the database?
3. Learner history that doesn't survive the move
Courses can be rebuilt. A learner’s history is much harder to recreate. Different LMSs structure their data differently, so learning paths, certifications, and reporting logic frequently fail to map directly.
Recertification dates are the quietest risk. If a due date silently resets to blank, people can fall out of compliance without anyone noticing for months.
For regulated organisations, a training record is evidence. We work with NHS and healthcare organisations, government departments and agencies, education providers, and charities. In each of them, the LMS is often the first place an inspector, auditor, or funder looks. In health and social care, for example, Care Quality Commission guidance on staffing expects that “all learning and development and required training completed should be monitored”. For funded UK training providers, Department for Education guidance requires learner records to be kept for six years from the end of the financial year after the last payment.
Records arriving is only half the job. You also need to show they arrived intact: totals that reconcile between old and new platforms, completion and expiry dates that match, and certificates that still open.
Important
The question to ask: if a regulator asked for a learner record from six years ago, could you produce it and prove it arrived intact?
4. Content that loads but doesn't track
Most organisations hold a library of SCORM packages, and most will open in the new platform after an LMS migration. Whether they report correctly is another matter, so every important package needs testing before learners rely on it.
Older packages carry a specific risk. SCORM 1.2 limits the data a course can store about where a learner left off to 4,096 characters. Larger courses that exceed it can return learners to the wrong point when they resume. Some platforms apply that limit loosely, so a package that worked for years can start misbehaving on a platform that applies the standard strictly. Republishing in SCORM 2004, which allows far more, is the usual fix.
Completion history needs checking separately. SCORM governs how a course reports during a session, but each LMS stores the long-term record in its own way. A package that launches perfectly can still fail to record a completion.
Important
The question to ask: have you tested your most important packages end to end, including resuming partway through and completing?
5. Forgetting that an LMS migration is a change for people
Many of the failures above share a root cause. Teams plan the migration as a technical task of moving a database and files from one place to another. For the people who use the platform every day, it’s a change in how they work, and it needs managing as one.
The interface may look completely different. Familiar menus move, enrolment works differently, reports live somewhere new. ATD describes the hidden cost of user adoption as more support requests, slower completions, and extra manual work in the early weeks.
Each group needs something different, at a different time.
Administrators need training first, ideally on the trial build, because they’ll field everyone else’s questions.
Managers need to know what changes in how they assign, approve, and report on training.
Learners need to know what’s happening and when, with short guides or videos for the tasks they do most.
Support teams need extra capacity for the first few weeks, and a quick way to report problems.
We build this into how we onboard clients. We train your administrators, provide guides and videos for your users, and support your learning team through the switch. That support starts well before go-live and continues while people settle in.
We build this into how we onboard clients: administrator training, user guides and videos, and learning team support through the switch.
Important
The question to ask: who needs to know what, and when, and how will you support them in the first weeks after go-live?
6. Going live without a rehearsal
While the team prepares the new platform, the old one keeps running. Any learning activity not captured before launch can go missing. Add an untested build and a single attempt at the live migration, and every problem above arrives on the same day.
Our approach is to rehearse twice: a trial build of the new platform, then a trial migration of the real data. Issues surface while there is still time to fix them. Only then do we run the live migration.
Important
The question to ask: will you see your own data, migrated and working, before the switch?
Start your LMS migration with the outcome you want
Every one of these failure points becomes more likely when an LMS migration aims to reproduce the old platform. Lifting and shifting carries over the hidden edits, the forgotten integrations, and the workarounds that existed only because the original system could not do something.
We start from the other end: what does the platform need to do for your organisation? Once that is clear, a hidden core edit becomes a requirement we can meet properly, through configuration, a supported plugin, or one of the Accipio One modules, which run on Moodle, Moodle Workplace, and Totara. The review often shows plugins nobody uses and integrations you can retire. You end up with a platform that is simpler to support and easier to upgrade. At Accipio, we include upgrades for our clients at no extra cost.
This is just one example that illustrates what we mean by Beyond out of the box.
Your LMS migration checklist
What has been changed in the core code, by whom, and why?
What reads from or writes to the LMS, including direct database connections?
Which learner records, certifications, and due dates must survive, and how will you prove they arrived intact?
Have your most important SCORM packages been tested end to end?
What will you migrate, archive, or retire, and how will you prepare each group of users?
Will you see a trial build and a trial migration before go-live?
If any of these are hard to answer, we can help.