Why a Moodle 5.0 upgrade starts with what it removes
An operator moving an older Moodle to 5.x should start with an inventory, not the upgrade itself. The move is driven by three things: features that 5.0 removes, server and database requirements that change between releases, and theme changes that alter how the site looks and where custom styling breaks. Those three set the scope of the project, so they need to be listed before anyone schedules a test instance. The aim is to keep course content intact, which means knowing in advance which activities, plugins, themes and editors will stop working or need a replacement.
Each Moodle release has its own support window, and those windows decide when you must move. Moodle ships major releases in April and October and minor point releases every two months. Moodle 4.5 is a long-term support release with security support until 4 October 2027. Moodle 5.1, released 6 October 2025, has general support until 5 October 2026 and security support until 19 April 2027. Moodle 5.3, released 5 October 2026, is the next LTS, with general support until 4 October 2027 and security support until 1 October 2029. Confirm these dates on the Moodle releases page before you pick a target, because the target determines how many version hops your upgrade needs.
Requirement changes are where many upgrades stall. Moodle 5.1 requires 64-bit PHP 8.2 or later, and sites must already be on Moodle 4.2.3 or later to upgrade. Moodle 5.3 requires 64-bit PHP 8.3 or later, PostgreSQL 17 and a starting point of Moodle 4.4 or later. From 5.1, the web server document root must point to the public directory, or the site may show directory listings or errors. Record your current PHP, database and web server versions, then compare them with the release notes for each target you are considering, since the required versions differ between releases.
Removed features need the most careful inventory. Atto, Chat, Survey, CAS authentication, MNet and Oracle support are gone in 5.0, and Boost moves to Bootstrap 5, so custom theme code may need rework. Build a list of every activity, block, authentication method, theme and editor in use, count the courses that depend on each one, and mark whether core offers a replacement or a plugin is needed. Moodle 5.3 also removes the Classic theme from core, so a site still using it needs a decision before the target version is fixed. Ask each plugin vendor to confirm its 5.x compatibility in writing, and check that the SAML2 plugin you rely on lists support for your target version.
What changes in Moodle 5.0 and 5.1 and what each change means for your site
This table lists the removals and requirement changes that affect an existing Moodle site on the path to 5.0, 5.1 and 5.3, with the impact on your site and the action to take. Treat the 5.0 rows as a checklist to confirm against the Moodle 5.0 release notes on moodledev.io before you plan the upgrade. The 5.1 and 5.3 rows state version minimums that your servers and database must meet.
| Change | Impact | Action needed |
|---|---|---|
| Atto editor removed in 5.0 | Courses, blocks and custom content that rely on the Atto editor will lose their editing interface after the upgrade. | Search your content and plugins for Atto use. Confirm the replacement editor and its migration behavior in the 5.0 release notes. |
| Chat and Survey activities removed in 5.0 | Existing Chat and Survey activities and their data may not be available on the upgraded site. | List every course using these activities. Confirm the removal and data handling in the 5.0 release notes, then agree a replacement or archive plan with course owners. |
| CAS authentication removed in 5.0 | Users who sign in through CAS will not be able to sign in until another method is configured. | Identify the CAS users and choose a replacement method. Core options include OAuth 2 and Shibboleth, and SAML 2.0 is commonly provided by the auth_saml2 plugin. Test sign-in on a staging copy. |
| MNet and Oracle support removed in 5.0 | Sites using MNet peer connections or an Oracle database will need changes before they can upgrade. | Confirm whether either feature is in use. Check the 5.0 release notes for the removal scope and plan a database or network change before the upgrade. |
| Boost theme moves to Bootstrap 5 | Custom themes built on Boost, and custom CSS or templates, may display incorrectly or break after the change. | Audit theme code and local CSS for Bootstrap 4 class names. Test each custom theme on staging and confirm the Bootstrap 5 changes in the 5.0 release notes. |
| Web server document root moves to /public in 5.1 | If the web server still points to the main Moodle folder, the site may show directory listings or errors. | Update the virtual host or web server configuration to point to the /public directory, then verify the site loads and test after each restart or deployment change. |
| PHP 8.2 and database minimums in 5.1 | Servers below 64-bit PHP 8.2, or databases below the listed versions, cannot run 5.1. Sites must also be on Moodle 4.2.3 or later to upgrade. | Record current PHP, database and Moodle versions. Upgrade PHP to 8.2 or later (8.3 and 8.4 are supported) and the database to PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later. |
| Classic theme removed in 5.3 | Sites using the Classic theme will need a different theme before moving to 5.3. | Identify any site or sub-site set to Classic. Choose a supported theme and test it. Note that 5.3 requires PHP 8.3 or later and PostgreSQL 17 or the other listed database versions. |
Which starting versions can reach Moodle 5.x directly
The path into Moodle 5.x depends on the version a site runs today. Moodle 5.1 accepts sites on 4.2.3 or later, and Moodle 5.3 accepts sites on 4.4 or later. The cards below set out each starting point, the support windows that follow, and what to confirm for 5.0 itself.
Sites on Moodle 4.2.3 or later
Moodle 5.1 accepts a direct upgrade only from Moodle 4.2.3 or later. Confirm the exact installed version under site administration before planning, because a site on an earlier 4.2 point release must first move to 4.2.3. Treat this check as the first gate in the upgrade plan, ahead of any plugin or theme review. Record the PHP and database versions alongside it, since those also gate the target.
Sites on Moodle 4.4 or later
Moodle 5.3 accepts a direct upgrade from Moodle 4.4 or later, and it is the next long-term support release with general support until 4 October 2027 and security support until 1 October 2029. The target also raises the bar: 64-bit PHP 8.3 or later, PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Check the database and PHP versions early, because they often take more work than the Moodle code itself.
Older sites need intermediate hops
A site below the minimum for its target cannot skip ahead. It must move through intermediate Moodle releases first, and each hop has its own PHP, database and plugin requirements. Take a tested backup and restore before each hop so a failed step does not become the new baseline. The sibling topics on the 4.1 LTS to 4.5 LTS upgrade and the 3.x to 4.x upgrade set out those steps, so follow them there rather than rebuilding the sequence in this plan.
Moodle 5.1 support windows
Moodle 5.1, released on 6 October 2025, receives general support until 5 October 2026 and security support until 19 April 2027. A site that lands on 5.1 therefore has a short general support window before the release moves to security fixes only. Use these dates to decide whether 5.1 is a stop on the way to a later long-term release, and schedule the next move before general support ends.
Moodle 4.5 LTS as a holding release
Moodle 4.5 is a long-term support release from 7 October 2024, with security support until 4 October 2027. Sites that cannot yet meet the 5.x requirements can hold on 4.5 while they fix plugins, themes and infrastructure. Record that holding decision with an end date, and confirm the site's PHP and database versions still meet 4.5 requirements before relying on it.
Confirm the Moodle 5.0 starting point
Confirm Moodle 5.0's minimum starting version and its support dates in the official Moodle 5.0 release notes and the Moodle releases page before choosing it as a stop. Do not assume 5.0 uses the same minimum as 5.1 or 5.3. Ask your implementation partner to put the confirmed starting version, PHP and database requirements in writing as part of the upgrade scope.
Which removed features need a replacement before cutover
Before cutover, every removed feature in your site needs an owner and one of three outcomes: a replacement plugin, a rebuild on a feature that remains in core, or a planned retirement with users told in advance. Moodle 5.0 removes Atto, Chat, Survey, CAS authentication, MNet and Oracle, so the inventory begins with finding where each one is still in use. Ask the platform team for the installed plugin list, the database driver settings and the authentication configuration, then search course content, activities, blocks, login pages and peer network settings. Record each finding in a register with the feature, the location, the number of users affected and the decision.
Atto is the text editor that many sites used across course content, activity descriptions, forum posts, blocks and profile fields. Its removal affects authors more than administrators, so test whether any content depends on editor-specific markup or on toolbar features that will not carry over. Chat and Survey are activity modules. Find them by listing activities per course and checking whether they hold live data, such as chat transcripts or survey responses, that must be exported or archived. The replacement decision is whether the teaching use can move to a supported activity, such as a forum, quiz or feedback activity. That choice changes how courses are built, so it belongs in the course design review, not only in the upgrade checklist.
CAS authentication and MNet control how users sign in and how Moodle sites trust each other. For CAS, identify every login page, SSO entry point and identity provider connection that depends on it. Moodle core ships authentication plugins for LDAP, OAuth 2, Shibboleth, LTI, external database and web services, so the first question is which of these matches your identity provider's protocol. For SAML 2.0, the SAML2 Single sign on plugin (auth_saml2), maintained by Catalyst IT, is the common route. Its plugin directory listing currently states support up to Moodle 5.1, so confirm its compatibility with your target release. Before committing, confirm fit with your identity provider on attribute release, the user identifier, and logout behavior. For MNet, decide whether each peer trust relationship is retired or replaced with a supported identity link.
Oracle is a database question rather than a feature question. Check whether the main site or any external database authentication or integration connects to Oracle. If it does, the target must be an engine that Moodle still supports, and the move becomes a database migration project in its own right. For the current engine versions, check the Moodle 5.1 and 5.3 release notes: Moodle 5.1 requires PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later, and Moodle 5.3 raises several of these. Each replacement changes course design, user migration and plugin review, and each one needs its own test cycle and sign-off. Ask any partner for a written scope that names the test environment, the data copy used for testing and the acceptance criteria for each feature.
Preparation: backups, inventory and a test copy
The work below must be finished before any upgrade step runs on the production site. Each area produces evidence the next one depends on: a restorable backup, a complete inventory, a test copy that behaves like production, and a log of decisions for every removed feature. Skipping one usually shows up later as a broken course or a plugin that fails after cutover.
Full backup and restore test
Take a full copy of the code, the database and the moodledata directory before any change, and store it outside the server being upgraded. Then restore it to a separate machine and confirm that users can sign in, course content opens and uploaded files display. A backup that has never been restored is an untested assumption, so record who ran the restore, what it covered and which checks passed.
Plugin, theme and custom code inventory
List every installed plugin, theme and piece of custom code, grouped by plugin type. Moodle documents more than 50 plugin types, so check at least activity modules, blocks, themes, authentication, enrolment, local, report and admin tool plugins. For each item, record its version, its source, whether a release exists for the target version and who maintains it. Anything without a supported path becomes an entry in the decision log.
Courses using removed features
Find every course that depends on a feature the upgrade removes. The topic lists Atto, Chat, Survey, CAS authentication, MNet and Oracle as gone, so review courses for Chat and Survey activities and content edited in Atto, and identify users who sign in through CAS or MNet peers. Check whether Oracle is in use at all. Group affected courses by department so course owners know which content to rebuild first.
Test environment from production
Build a test site from a recent copy of production so course data, plugins and themes behave as they do live. Match the web server document root, the PHP version and the database engine and version to the target release. Confirm the exact requirements for your target in its release notes, then match them. Mask personal data in the copy before it leaves the production environment.
Decision log for replacements
Record each removed feature, the replacement you choose and the person or team that owns it. Typical entries cover whatever replaces Atto for teachers, the tool that takes over from Chat or Survey, and the authentication method that replaces CAS. Include the affected courses, the test that proves each replacement works and the sign-off owner. Keep the log in version control so course owners and auditors see the same decisions.
The Moodle upgrade sequence with checks and rollback points
This sequence moves a Moodle site to a supported target release in an order that keeps production safe. Each stage ends with a verified rollback point, and production changes begin only after the test copy has passed.
Confirm the starting version meets the minimum
Check the current Moodle release against the minimum starting version in the release notes for your target. For Moodle 5.1, sites must be on 4.2.3 or later, so older sites need an intermediate upgrade first. Record the Moodle version, PHP version, database engine and version, and the full plugin list in the upgrade plan. The step is done when the upgrade path is confirmed in writing and the site owner signs off. Rollback point 1: take a full backup of code, database and moodledata, then restore it to a separate host and confirm the site loads and the data matches.
Upgrade PHP and database in the test copy
Build a test copy of the production site on a separate host. Move PHP to a version the target supports, and move the database engine to a supported version, using the minimums in the target's release notes. For Moodle 5.1, PHP must be 8.2 or later (8.3 and 8.4 are supported), with PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later. Confirm with your database team how the engine change is performed. The step is done when the site runs on the new stack without changing Moodle code. Rollback point 2: restore the pre-change code and database and confirm the site still runs on the original stack.
Move the document root to /public
For target 5.1 and later, point the web server document root to the new /public directory instead of the main Moodle folder. Without this change, the site can show directory listings or errors. Update the virtual host or equivalent configuration in the test copy, reload the web server, and confirm that the front page, login page and administration pages load. Also confirm that the main folder is not browsable. The step is done when these checks pass on the test copy and the configuration change is saved in version control. Rollback point 3: revert the web server configuration file and restore the previous document root, keeping the code and database as they were.
Restore the copy and run the core upgrade
Restore a fresh production backup into the test environment so the upgrade runs against current data. Run the core upgrade through the administration notifications or the command-line upgrade script. Review the upgrade log for errors and warnings, not only for the final success message, and fix any database or configuration problem before continuing. The step is done when the upgrade completes without errors, the site reports the target version, and the cron tasks run. Rollback point 4: restore the code, database and moodledata from the pre-upgrade backup, then confirm the site returns to the starting version.
Resolve plugin and theme incompatibilities
Check each third-party plugin and theme against the target version in its own documentation or the plugins directory. Replace or remove anything that does not support the target. For example, the SAML2 plugin (auth_saml2) lists support up to Moodle 5.1 in the plugins directory, so confirm its status before moving to a later release. Test themes built on Boost against the Bootstrap 5 changes, and check custom CSS, templates and layouts. The step is done when every plugin and theme loads without errors, and the sign-in path and main navigation work. Rollback point 5: restore the previous plugin and theme code directories and the database from the last backup taken before plugin upgrades ran.
Fix course content that uses removed features
Search course content, the question bank and activity settings for features removed in the target release, including Atto editor content, Chat, Survey, CAS authentication, MNet and Oracle database connections. Replace each use with a supported activity, editor or sign-in method, and record the change for each course owner. Confirm the list of removed features against the release notes for your exact target version. The step is done when a search finds no remaining references in active courses, and course owners have reviewed their changed courses. Rollback point 6: restore the database and moodledata from the backup taken before content changes, since course edits are stored in the database and files area.
Run the test cases
Run a written test script against the upgraded test copy before any production change. Cover student and teacher sign-in, enrolments, quiz attempts, assignment submission and grading, file uploads, gradebook export, SSO sign-in, scheduled tasks, backup and restore of a course, and any integrations with video, storage or HR systems. Agree the pass criteria and the defect severity levels with the business owners in advance. The step is done when every test case passes or has an accepted, documented exception. Rollback point 7: keep the test copy, fix defects in the upgrade plan, and repeat the affected steps from the restored backup until the full script passes.
Schedule the production cutover
Begin production cutover only after the test copy has passed the full test script and the owners have signed off. Schedule a maintenance window with the business, announce it to users, and freeze course and configuration changes for the window. Take a final production backup, then repeat the steps used on the test copy in the same order. Verify sign-in, core pages, cron and key integrations before reopening the site. Define the rollback trigger in advance, and keep the pre-cutover backup available until the owners accept the upgraded site. The step is done when production passes the same checks as the test copy. Rollback point 8: restore code, database and moodledata from the final pre-cutover backup if a rollback trigger is met.
How to test themes, editors and course content before cutover
The cutover decision should rest on a written test matrix organized by area: themes, editors, course content, logins and integrations. Start by inventorying every custom theme, child theme and third-party plugin on the current site, then mark which ones depend on features the target release removes, including Atto, Chat, Survey, CAS authentication, MNet and Oracle. Run the matrix on a staging copy built from a backup of production, on the same target version and PHP and database versions you plan to use. For Moodle 5.1 and later, confirm during this run that the web server document root points to the /public directory, because a misconfigured root can show directory listings or errors that look like theme faults.
For themes, test each layout your users see: the dashboard, course page, activity pages, login page, and any custom blocks or templates. Any theme built on Boost or a child of it needs review against the Bootstrap 5 markup changes, since custom CSS and overrides that target Bootstrap 3 class names or old templates can misalign or disappear. Compare screenshots of each layout against the current site at desktop and mobile widths, and record each difference as a defect with an owner. Moodle 5.3 removes the Classic theme from core, so any course or site that still selects it needs a decision before the upgrade.
For editors, every piece of content created or edited in Atto must be opened in the editor that replaces it. Check formatting, tables, images, embedded media, math notation and any custom HTML, because stripped or altered markup is the most common silent failure. For course content, build a sample that includes quizzes drawn from the question bank, H5P or SCORM packages, embedded videos and external links, and open each activity as a teacher and as a student. Flag any activity, block or link that depends on a removed module or plugin, and assign it to a rebuild or replacement decision.
For logins, test every authentication path, not only the default one: manual accounts, the replacement for CAS, LDAP, OAuth 2, any SAML 2.0 single sign-on plugin, and password reset. Test each path with accounts for every role, including suspended and newly provisioned users. For integrations, test LTI tool launches and grade return, the SSO handoff, the HR feed that creates and suspends accounts, and every report that reads from the database. Confirm with each plugin's maintainer that its version supports the target release before testing begins.
Build the course sample deliberately. Choose courses across categories, sizes and activity types, and include the courses most likely to fail, such as those using removed modules or heavy custom styling. Assign one owner per area with authority to sign off, and name a backup. Record every result in a shared tracker with the date, Moodle build, tester, expected result, actual result and retest outcome. Make the go or no-go decision only when every critical failure has been closed or accepted in writing by the business owner, so the decision is traceable to evidence.
What makes a Moodle upgrade take longer
This table lists the drivers that change how long a Moodle upgrade takes, and the question to answer for each one in your inventory. Use it to scope the work, not to estimate it, since no effort figure is given here and each answer depends on your site. The version requirements cited come from the 5.1 and 5.3 release notes, so confirm the Moodle 5.0 requirements in its own release notes before planning.
| Driver | Why it adds effort | How to check it |
|---|---|---|
| Custom and third-party plugins | Each plugin needs a release for the target version or must be replaced, rewritten or removed, and each replacement adds testing. | List each plugin with its installed version, source and whether its maintainer publishes a release for the target version. |
| Custom themes built on Boost | Boost moves to Bootstrap 5, so theme CSS, templates and overrides written for the earlier markup need review. | List each theme, its parent theme and any template or SCSS overrides, then compare them with the Bootstrap 5 changes in the release notes. |
| Use of removed features across courses | Atto, Chat, Survey, CAS authentication, MNet and Oracle are removed, so activities, content and login paths that use them need replacing or migrating. | Run a report of activities, editor content and authentication settings that reference each removed feature, grouped by course. |
| Number of courses and content volume | More courses means more content to sample for editor, activity and layout breakage, and a longer post-upgrade review. | Count active and archived courses, then identify which courses hold the most activities, files and custom layouts. |
| Size of the database and moodledata | Larger databases and file stores extend backup time, the upgrade run and the window available for rollback. | Measure database and moodledata size, then time a full backup and restore of a copy of production. |
| Authentication and integration points | Each SSO, LDAP, external database, web services or HR connection needs retesting, and CAS users need a new sign-in path. | List every enabled authentication plugin and every external system that calls Moodle, with its owner and a test case for each. |
| PHP and database version jumps | Moodle 5.1 requires 64-bit PHP 8.2 or later and Moodle 5.3 requires PHP 8.3 or later, so server and database upgrades may need to come first. | Compare your current PHP and database versions with the target release notes, including PostgreSQL 15 for 5.1 and PostgreSQL 17 for 5.3. |
| Starting-version hops | Sites must already run a minimum version to upgrade (4.2.3 for 5.1, 4.4 for 5.3), so older sites need intermediate upgrades, each with its own testing. | Confirm your exact current version, then list each intermediate hop needed to reach the target version. |
Questions teams ask before a Moodle 5.0 upgrade
How much does a Moodle 5.0 upgrade cost, and what drives it?
The cost of a Moodle 5.0 upgrade is set by the written scope. DeployOpen does not publish a price list, and a quote follows from the scope. Most of the cost comes from work that depends on your site: the number of plugins and themes to check or replace, any custom code, the volume of course content and question banks to test, and the number of integrations such as SSO or HR feeds. The assessment, plugin decisions, fixes, testing and cutover are one-time costs. Ongoing support or a retainer is recurring. Internal staff time is also a real cost to your organization, even when it is not billed. Ask any quote to itemize these parts, state what is excluded, and list the environments included.
How long does a Moodle 5.0 upgrade take to complete?
The duration depends on what the site contains and how many test cycles it needs, so no fixed number applies before an assessment. The main drivers are the number of plugins and custom themes, how much course content and how many integrations need retesting, whether the database or PHP version must be upgraded first, and how quickly course owners and approvers can sign off. Moodle 5.1 requires sites to be on Moodle 4.2.3 or later, and Moodle 5.3 requires Moodle 4.4 or later, so an older starting point adds intermediate steps. Ask for a plan that lists each phase, the dependencies on your team, and the dates the written scope commits to.
What does our internal team need to provide for the upgrade?
Your team provides the access and decisions the work cannot proceed without. Typical items are access to staging and production servers, the database, the file store and the source control for any custom code; course owners who can review sample courses, quizzes and assignments; test sign-off from named people who approve each phase in writing; plugin decisions on whether each installed plugin is kept, updated, replaced or removed; and an approved change window for cutover and rollback. Name one person who can make decisions quickly. Delayed answers on plugins and sign-offs usually cause the longest delays in the schedule.
Can our own team upgrade Moodle to 5.0 without a partner?
Yes, an internal team can upgrade a site, and Moodle publishes release notes and upgrade guidance for each version. Whether it should depends on the site's complexity. A small site with few plugins, the default theme and no custom integrations is a reasonable candidate for a team with Linux, PHP and database skills. The risk rises with custom themes, unsupported plugins, removed features in use, SSO and HR integrations, and large databases, where a failed upgrade is harder to roll back. Check the server requirements in the Moodle 5.1 and 5.3 release notes, confirm your starting version, and rehearse the upgrade on a copy of production before deciding.
What happens if we still use a removed Moodle feature?
A removed feature still in use will stop working or block the upgrade, so find it before scheduling any cutover. Start with an inventory of activities, blocks, filters, authentication methods and database connections. Check specifically for content built with the removed editor, Chat or Survey activities, CAS logins, MNet peers and Oracle databases. Each item needs a decision: migrate the content, replace the feature with a supported plugin or core option, or retire it with a notice to users. Authentication changes carry the most risk. Confirm the login path for every user group in a test environment before the production window. Core ships options such as OAuth 2 and LDAP, and SAML 2.0 is commonly provided by the auth_saml2 plugin, but confirm its support for your target version first.
Can DeployOpen take a Moodle 5.0 upgrade on a fixed scope?
Yes, DeployOpen can take a Moodle 5.0 upgrade on a fixed scope. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The written scope should list the assessment, the plugins and themes in and out of scope, the removed features to migrate or retire, the environments, the test cycles and the acceptance criteria. DeployOpen plans, tests and documents the upgrade inside your own infrastructure, and ongoing support after go-live is available as a retainer. DeployOpen does not issue audit reports or certifications, and no outcome is guaranteed. Ask for the written scope before comparing quotes.
How DeployOpen scopes, delivers and supports a Moodle upgrade
DeployOpen treats the Moodle 5.0 upgrade as a planned change to your own Moodle site, running in infrastructure you control. The work starts with an inventory of the removed features your courses, themes and plugins depend on, then moves through build, testing and handover. Engagements are fixed-scope, with the scope agreed in writing before work starts.
How we scope
- Inventory of Atto, Chat, Survey, CAS, MNet and Oracle use across courses, plugins and integrations.
- Theme and Boost customizations assessed for the move to Bootstrap 5 before any build starts.
- Written scope names the sites, environments, plugins and courses in and out of the upgrade.
How we build
- Upgrade a staging copy of your database and moodledata first, before any change to the live site.
- Replace or remove each Atto, Chat, Survey, CAS, MNet or Oracle dependency with a planned alternative.
- Test course content, quizzes, themes and plugins on staging, with results logged against each scope item.
How we hand over
- Written record of what changed, which features were removed, and what replaced them.
- Runbook for the upgrade steps, rollback points and the staging-to-production cutover.
- Walkthrough with your administrators on the changed course, theme and plugin areas.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Confirm Moodle security support dates for your release on the Moodle releases page before scheduling.
- Plan later Moodle upgrades as a repeatable change with the same inventory and test steps.
