Migrating from mod_hvp to the Native H5P Activity in Moodle

If your Moodle site still uses the older H5P plugin (mod_hvp, the “Interactive Content” activity), upgrading to Moodle 4.x or 5.x is the point where that decision catches up with you. mod_hvp is no longer the recommended way to run H5P in Moodle: the native H5P activity (mod_h5pactivity) and the Content Bank have replaced it. This guide covers moving your existing content across with the official migration tool, without losing work or breaking courses.

The two H5P systems, and why they conflict

There are two separate H5P implementations in the Moodle world:

• mod_hvp: the original third-party plugin by Joubel. Content is stored inside the activity itself. This is the one being phased out.
• mod_h5pactivity plus the Content Bank: Moodle core’s own H5P support, both introduced in Moodle 3.9. Content lives in the Content Bank as reusable .h5p files; the activity references it.

Both can run side by side, which is what makes the transition manageable, but you do not want to stay in that split state long-term. mod_hvp receives limited maintenance and lags on new Moodle version support, so leaving content there is a slowly accumulating risk.

The migration tool is a separate install, not part of core

The migration is handled by the admin tool Migrate content from mod_hvp to mod_h5pactivity (tool_migratehvp2h5p). This is not bundled with Moodle core. You download and install it from the Moodle plugins directory:

https://moodle.org/plugins/tool_migratehvp2h5p

Install it the same way as any other plugin (drop it in admin/tool/migratehvp2h5p/ or install via the UI, then complete the upgrade). The tool only shows its admin page when mod_hvp is present on the site, so it appears after installation only if you still have the old plugin to migrate from.

What the tool moves, and what it does not

What it does:

• Copies each piece of mod_hvp content into the Content Bank
• Creates a new mod_h5pactivity instance pointing at that content, in the same course location
• Copies completed student results across to the new activity

What it does not move:

• Unfinished (in-progress) attempts. The native mod_h5pactivity cannot save in-progress state the way mod_hvp can (mod_hvp’s save-state is itself off by default). Any attempt a learner has started but not completed is lost in the migration. Completed results are preserved; in-progress ones are not.
• mod_hvp’s own settings (display options, hub/usage settings) do not carry over.

If in-progress attempts matter for a particular cohort, migrate after a natural completion point, or warn learners to finish open activities first.

Pre-flight checklist

Run through all of these before touching production:

1. Take a full backup (database plus moodledata). The migration copies content into the Content Bank, so it is additive, but a backup is non-negotiable before a bulk content operation.
2. Check disk space. Migrated content is copied into the Content Bank, so moodledata grows. On a media-heavy site that can be a significant increase, so confirm you have headroom before starting.
3. Enable the Content Bank and confirm the H5P content-type libraries are present (Site administration > H5P > Manage H5P content types). The Content Bank is the destination; if libraries are missing, migrated content will not render.
4. Decide the disposal policy up front: keep the original mod_hvp activities (the default, recommended) or delete/hide them. Keep them if completed-attempt history needs to remain reachable in its original form.

Running the migration

There are two ways to run it. Use the web UI for small sites and the CLI for large ones.

Web UI (small sites):

1. Go to Site administration > Migrate content from mod_hvp to mod_h5pactivity (it is a top-level admin menu item once the tool is installed, not under an “H5P” section).
2. Choose the disposal option for the original activities. Keeping originals is the safe default for a first run.
3. Start the migration. The web UI processes the migration inline, within the request; it is not queued to cron. On a large site this means the page can run for a long time or time out, which is why the CLI exists.

CLI (large sites, recommended for anything substantial):

sudo -u www-data php admin/tool/migratehvp2h5p/cli/migrate.php --execute

By default the CLI migrates up to 100 mod_hvp activities per run, keeps the originals, and links the new activities to the Content Bank. Run --help to see the options for raising the per-run limit, deleting or hiding the originals, or filtering by content type:

sudo -u www-data php admin/tool/migratehvp2h5p/cli/migrate.php --help

For sites with more than 100 activities, run the script repeatedly; it only migrates each mod_hvp instance once (see below), so re-running picks up the remainder.

After migrating: verify before you trust it

• Open a sample of migrated activities across different content types (Interactive Video, Course Presentation, and Quiz sets are the ones most likely to surface issues). Confirm they render and play.
• Check the Content Bank: migrated content should appear there.
• Confirm completed results carried across, and remember that in-progress attempts did not.
• Only once you have verified rendering should you consider hiding or removing the original mod_hvp activities.

Re-running and rollback

The tool migrates each mod_hvp activity only once. If you need to re-migrate one (for example, after fixing a rendering problem), remove or rename the migrated h5pactivity first, then run again; the tool will treat the original as not-yet-migrated and process it. Because originals are kept by default, the practical rollback is simply to leave the originals in place until you have fully verified the migrated versions.

Common failures

• Web UI times out on a large site: expected, because the UI runs inline. Use the CLI script instead.
• Migrated content does not render: the matching H5P content-type library is missing from the Content Bank. Install or update content types, then re-check.
• Out of disk space mid-migration: content copying filled the volume. Free space, then re-run; already-migrated activities are skipped.
• A specific activity reports it could not be migrated: isolate and handle it individually, typically by re-uploading the source .h5p into a fresh activity. The rest of the batch is unaffected.

When to do this

If you are planning a Moodle 4.x or 5.x upgrade and still run mod_hvp, do the H5P migration as a distinct, verified step rather than folding it into the version upgrade. Treating it as its own project, with its own backup and verification pass, keeps two large changes from compounding into one hard-to-debug failure.

Solin specializes in Moodle and Totara upgrades and content migrations. Need help? Contact us.