When Moodle Marketplace launched, a number of plugins were not migrated from the old Plugins Directory, and that gap now affects sites already running them. On 21 July 2026, the Marketplace replaced the Plugins Directory as the official source for Moodle add-ons. However, 105 plugins did not make the move, because their providers asked to stay out.
Some are discontinued, but several are actively maintained and widely used. The real risk is not that your site breaks tomorrow, it is that these plugins quietly become impossible to update or reinstall. In this article, we explain what changed, how to audit your stack, and how to decide what to replace, fork, or sponsor when a Moodle Marketplace plugin is not migrated.
I recently migrated my site to Mindfield from another host, and the experience couldn’t have been better. Mindfield kept working until they were certain that my site was operating as well as it was before, and they even helped clean up a few issues to improve my site’s performance – issues my prior host never mentioned. I also found Mindfield’s communication to be excellent. Before the migration, they prepared me for what to expect, and during the migration they kept me well-informed.
Jim Benedek
review Source: Google Reviews
Outline
- What “Not Migrated” Actually Means for Your Site
- Auditing Your Plugin Stack Against the New Directory
- When a Working Plugin Becomes an Upgrade Trap
- Replace, Fork, or Sponsor: Choosing a Path
- Getting the Plugin Transition Right with Expert Help
- Frequently Asked Questions (FAQs)
What “Not Migrated” Actually Means for Your Site
Nothing on your live site is deleted, and no plugin stops working on 31 August 2026. The code already installed keeps running exactly as before. What ends is distribution, not function.
The code you run keeps running
Your running site is not at risk. Moodle did not remove, pull, or ban anything. Instead, the providers of these plugins asked Moodle not to migrate them to the Marketplace, 105 in total.
In most cases the plugins are discontinued and no longer maintained. However, some are actively maintained and widely used, which is exactly why this matters.
What ends is distribution, not function
After the cutoff, affected plugins simply stop being retrievable through the update API, which Moodle’s own notice calls the Marketplace API. Practically, that removes them from three places you rely on:
- The admin update check that flags new plugin versions.
- Any scripted or automated install that fetches plugin files.
- Any future rebuild or clone of your site.
These plugins remain available through it only until 31 August 2026. After that date, any not published by their provider drop off the API for good. You can read Moodle’s original notice in the General plugins forum announcement.
A quieter change: downloads now need credentials
A second operational shift is worth naming. Downloads from Moodle Marketplace now require Bearer token authentication, using a token from a Marketplace account. By contrast, old Plugins Directory downloads needed no login at all.
Consequently, any automated build or deployment pipeline that once pulled plugin files anonymously now needs credentials it never required before. Ask your team or hosting vendor whether your pipelines are affected.
Auditing Your Plugin Stack Against the New Directory
Before you react, you need an accurate inventory, and most organisations do not have one. The list itself is easy to misread. So the first job is matching it correctly against what you actually run. It is also the right moment to revisit your Moodle plugin cleanup strategies, because anything you no longer use is one less decision to make.
Match by component name, not display name
The list must be matched by Frankenstyle component name, not the display name you see in your admin screens. Display names collide; component names do not.
For example, a community member raised the alarm after spotting “Book” on the list. However, the Book activity has been part of Moodle core since around 2012. The real entry was a separate third-party plugin, mod_mubook.
A manager who searches by the friendly name will get both false alarms and false all-clears. See the Book / mod_mubook thread for the full exchange.
“I cannot find it” is not the same as “not migrated”
Not finding a plugin in the Marketplace does not mean it was left behind. By default, Marketplace search only shows plugins updated in the last three years. As a result, older but perfectly working plugins are hidden by a filter, not missing.
The catalogue totals make this plain. On 21 August 2026, the Marketplace listed 1,574 plugins by default, and 2,828 once the “Include plugins last released 3+ years ago” filter was switched on. So if the directory looks like it shrank from well over 2,000 plugins to around 1,500, that gap is one unticked filter rather than a purge.
Keep that number well apart from the 105. The roughly 1,250 plugins the default filter hides are still in the Marketplace and still downloadable, simply old. The 105 on the not-migrated list are a separate set, held back at their providers’ request, and they alone face the 31 August cutoff.
One member could not locate the Allbackups plugin until it was pointed out that it was there all along. Therefore, treat a failed search as a prompt to look harder, not proof of removal.
Silence from a provider may be an account issue
A provider who has gone quiet has not necessarily abandoned anything. Marketplace accounts were not created automatically from old Plugins Directory accounts. Maintainers had to sign up using the same email as their moodle.org account to reclaim their plugins.
Moreover, several reported trouble linking a business email address at all. So silence may be an account problem rather than the end of the road for a plugin you depend on.
The published list of Moodle Marketplace plugins not migrated is already changing
Treat the official list as a snapshot, not the final word. On 20 August 2026, Mindfield queried the public Moodle update API and compared it against the published list. It carried 105 rows; 104 have a component name, while one, HTMLArea Toolbar Extensions, has none and cannot be matched to installed plugins. Of the 104, our check found:
- 76 still resolve to old Plugins Directory URLs, so these face the cutoff.
- 15 have since been published to the Marketplace.
- 13 no longer appear in the update API at all.
The published list of plugins not migrated to Moodle Marketplace is therefore already out of date. Recheck it against your own stack rather than trusting it as final. The full document lives on Moodle’s plugins not migrated page.
When a Working Plugin Becomes an Upgrade Trap
A plugin that installs cleanly today can still block your next major upgrade. The danger is not the running plugin, it is the version you will need later.
The upgrade trap in practice
A site on Moodle 4.5 LTS today can install many affected plugins without any problem. For example, three well-known add-ons top out at a 4.5-compatible release:
- The Foundation theme (theme_foundation).
- The Microsoft OneDrive document converter (fileconverter_onedrive).
- Signup Sheets (mod_tutorialbooking).
However, a site moving to 5.x needs a newer release, one that may never be fetchable from the API again. Consequently, an add-on that works fine now becomes the single thing holding back your upgrade. That is the same class of problem behind most Moodle upgrade issues, and it is far cheaper to catch before you schedule the work.
Maintained today is not the same as available tomorrow
Some of these plugins are live, maintained code, not abandonware. Two of the best-known names prove the point. The Adaptable theme is a regular in any list of top Moodle themes. It has 82 releases, its most recent uploaded 11 July 2026 and supporting Moodle 5.2.
The Collapsed Topics course format has 196 releases, its latest from April 2026, also supporting Moodle 5.2. Both sat on the list, which is exactly what Moodle meant by “actively maintained and widely used.”
How much of the set is really at risk
Our check put rough numbers on the scale of the problem. Of the 76 plugins still on old download URLs:
- 29 have a release supporting Moodle 5.x.
- 16 stop at a 4.x release.
- 31 stop at 3.x or older.
In addition, 38 of the 76 had a release uploaded in 2025 or 2026. So roughly half of the affected set is live, maintained code. Practically, the safe move is to archive any versions you may still need before 31 August 2026. Ask your team or vendor to capture those files now, while the API still serves them. Pair that with automated testing for Moodle upgrades so you learn early which add-on actually blocks the move.
Replace, Fork, or Sponsor: Choosing a Path
When a plugin you rely on has no active maintainer in the Marketplace, you have three moves: replace it, fork and self-host it, or sponsor the maintainer to publish it. This is often the moment an organisation discovers when Moodle plugins stop being enough. The deciding factor is simple to name: whether the plugin holds data or only presentation.
A theme or course format only affects presentation. Swapping one costs you user confusion and some retraining, nothing more. The upkeep that follows is the ordinary work of managing custom Moodle themes. By contrast, an activity module, an enrolment plugin, or a certificate plugin holds records. Replacing one of those is a data-migration project, not a swap.
The Three Paths Side by Side
| Path | Best when | Main cost or risk |
|---|---|---|
| Replace | A tested alternative exists | Migration, retraining, possible data loss |
| Fork and self-host | You have in-house developers | You own every future release and fix |
| Sponsor the maintainer | One active maintainer, shared cost | It is a relationship, not a purchase |
This table judges each path on cost and ownership for a Moodle site owner, not on technical difficulty. It assumes the plugin still works and the question is only how you will keep obtaining it.
Weighing the Cost You Will Actually Carry
Most of these plugins are open source, and where the licence is the GPL, keeping an internal copy is legitimate. Confirm the licence shipped with the plugin before you fork it. A fork also means you silently own every future Moodle security fix. Sponsorship is often cheapest when one identifiable maintainer is still active and several institutions share the bill.
If you want your needs heard directly, Moodle has opened a Marketplace Product Advisory Group, with its first meeting on 23 September 2026. You can also review one admin’s detailed early observations in the Marketplace observations thread.
The verdict: replace when the plugin only shapes presentation and a tested alternative exists. Fork when it holds learner records and you have developers who can own it. Sponsor when one active maintainer is still publishing and the cost can be shared. The condition that decides it is whether the plugin holds data, not how attached your users are to it.
Getting the Plugin Transition Right with Expert Help
Untangling which add-ons moved, which did not, and which will quietly block your next upgrade is detailed work that rewards getting it right early. Mindfield’s Moodle specialists can audit your full plugin stack by component name, flag the add-ons facing the distribution cutoff, and map a replace, fork, or sponsor plan around what your site actually depends on. Moreover, we can archive the versions you need before they leave the API and prepare your build pipelines for the new authentication. Where a plugin you depend on has been abandoned, our engineers can take over its upkeep or revive an older release against a current Moodle version, so an unmaintained add-on does not set your roadmap. From audit to upgrade, we handle it end to end so nothing critical drops off unnoticed.
Frequently Asked Questions (FAQs)
This article may contain conceptual illustrations to help support the article content.
