What a Moodle implementation involves
A self-hosted Moodle rollout covers far more than installing the software. It starts with hosting and sizing, then moves through course and category structure, role design, theme and plugin choices, identity and enrolment integrations, content migration and training. Each of these areas adds work, and a quote that omits any of them will understate the effort. Before scoping, confirm the target Moodle release and its supported PHP and database versions, because those choices decide the server build and the upgrade path for the years ahead.
Most rollouts start from one of four triggers: a new LMS requirement, replacing a hosted or legacy Moodle, consolidating identity across the organization, or a regulated or sovereign hosting requirement that rules out a shared service. Each trigger changes the priorities. A consolidated identity estate pushes SSO and provisioning to the front of the plan, while a sovereign hosting requirement shapes the infrastructure, backup and access model from the first design session. Write the trigger down, because it determines which sections of the plan carry the most risk.
Build in-house when your team already runs PHP and database platforms in production, has capacity for ongoing administration, and wants the knowledge to stay internal. Bring in a partner when the timeline is short, the integrations are complex, or the team has never run a Moodle upgrade. Whichever path you choose, ask for a written scope that lists hosting, roles, theme, plugins, each integration, migration and training as separate deliverables. Ask who maintains each one after go-live, and who pays for upgrades.
What the work includes and what you receive
A fixed-scope Moodle engagement breaks into work packages that each end in a named deliverable. Use these cards to compare what a partner quote covers against what your own team would have to build.
Infrastructure design and build
Sizing, topology and build of the Moodle environment in your cloud account, data centre or air-gapped network, including web, PHP, database, file storage and cron nodes. Check whether the quote names the PHP and database versions for your target release, since Moodle 5.1 and 5.3 raise those minimums. Deliverable: a sizing and architecture document plus configured environments.
Moodle installation and configuration
Installation of the chosen Moodle release, web server setup with the document root pointed at the /public directory from Moodle 5.1 onward, site settings, cron, email and backup schedules. Confirm who sets the administrator accounts and whether environments for development, test and production are included. Deliverable: configured environments and an installation record.
Course and category structure
Design of the category tree, course naming rules, course templates, enrolment-ready shells and the rules for when a course is created, archived or copied between terms. This is where most rework appears later if it is skipped, so ask for it to be agreed with academic owners before build. Deliverable: a course and category structure specification with templates.
Roles and capabilities
Mapping of job functions such as learner, teacher, course creator, department manager and support staff to Moodle roles, with capability overrides at category and course level. Each override should trace to a stated business rule so auditors and administrators can read it later. Deliverable: a roles and capabilities matrix and the applied role configuration.
Theme and plugin selection
Selection of the theme and contributed plugins against the required features, with a compatibility check against the target Moodle release and a decision for each item on configuration, plugin or custom code. Note that Moodle 5.3 removes the Classic theme from core, which affects any brand work started on older themes. Deliverable: an approved plugin and theme register with versions pinned to the target release.
SSO and enrolment integrations
Connection of Moodle to your identity provider and to the source of enrolments, such as an HR system, student information system or LDAP directory. Confirm which protocol your identity provider supports, since core ships OAuth 2, LDAP, LTI and Shibboleth, and SAML 2.0 is usually added through a plugin. Deliverable: integration configuration, attribute mapping and a provisioning test record.
Content migration
Moving courses, files, users, grades and completion history from the current system into the new Moodle site, with mapping rules, a dry run and reconciliation counts before cutover. Ask how the quote handles content that cannot be mapped cleanly and who decides what is archived instead of imported. Deliverable: migration scripts or procedure, reconciliation reports and a cutover plan.
Testing and acceptance
Functional testing of roles, enrolments, SSO logins, grade flows and backups, followed by load testing sized to your peak term or exam window. Acceptance criteria should be written before testing starts so sign-off is a fact, not a debate. Deliverable: a test plan, executed test results and a signed acceptance record.
Training and handover
Role-based training for administrators, teachers and support staff, plus a handover session that transfers operation to your team. Confirm whether training is delivered live, recorded, or both, and how many sessions each audience receives. Deliverable: training materials, a runbook covering backup, restore, cron and patching, and a documented upgrade path.
What drives cost and duration
Each row names a driver of Moodle implementation effort, why it moves the plan, how to keep it under control, and what a fixed-scope quote should state, so you can compare proposals on the same basis.
| Driver | Why it moves effort | How to keep it down and what the quote should state |
|---|---|---|
| Concurrent and total users | Peak concurrent sessions set the web node count, database sizing, cache layout and load testing. Total users drive directory size, enrolment volume and sync runtime. | Agree peak concurrency for exam and enrolment windows, not just averages. The quote should state the sizing assumptions and the load test scope, and name who supplies the test traffic. |
| Courses, categories and content volume | Course count and category depth determine structure design, template courses, role assignments and content migration effort. Large media libraries add storage, backup and file migration work. | Reduce scope by migrating only active courses and archiving the rest. The quote should state course counts by category, total content size, and whether legacy content is converted or copied as-is. |
| Integrations (identity, HR or SIS, grade return) | Each source system needs field mapping, provisioning and deprovisioning rules, and test accounts. Grade return adds a write path that must be reconciled and tested against the gradebook. | Limit the first release to the integrations that gate go-live. The quote should list each integration by system, direction, method (such as LDAP, SAML 2.0 via the auth_saml2 plugin, or web services), and who owns the source system. |
| Customization depth | Configuration is cheapest to build and upgrade. Contributed plugins need compatibility checks on every release. Custom code needs development, review, testing and ongoing maintenance through upgrades. | Prefer configuration, then vetted contributed plugins, then custom code. The quote should separate these three tiers, name each plugin version, and state who maintains custom code after handover. |
| Number of environments | Each environment needs its own install, data refresh, configuration sync and test run. Staging that mirrors production is the most common source of schedule pressure. | Use at least one production-like test environment for upgrade and migration rehearsals. The quote should list each environment, its purpose, its hosting, and how often data is refreshed. |
| Compliance and accessibility obligations | Accessibility testing, audit logging, data retention, and evidence collection add test cycles and documentation. Obligations that apply to your institution must be confirmed by your own compliance function. | Agree the applicable standards and the test method at scoping. The quote should state which accessibility checks, how many review rounds, and what evidence is delivered. DeployOpen prepares evidence; auditors issue any assessment outcome. |
| Starting version and data source | Moving from an older Moodle release requires stepwise upgrades. Moodle 5.1 requires a site on 4.2.3 or later, and Moodle 5.3 requires 4.4 or later. Migrations from other LMS products need data mapping for users, grades and completions. | Confirm the current release and database at scoping. The quote should state the upgrade path, the target release, and the source platform and export format. |
| Target release, PHP and database | Each major release sets its own minimum PHP and database versions. Moodle 5.1 requires 64-bit PHP 8.2 or later and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later. Moodle 5.3 requires 64-bit PHP 8.3 or later and PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. | Confirm the target release, PHP version and database engine in writing before sizing. The quote should name the release and its support window, and state whether the host platform changes. |
| Hosting model | Self-hosting in your own cloud, data center or private network means DeployOpen builds the platform, backups and monitoring inside your environment. Managed hosting shifts operations to a provider and changes the handover scope. | Decide the hosting model before estimating infrastructure work. The quote should state what runs in your accounts, who holds administrator access, and which monitoring, backup and patching duties transfer to your team. |
Project phases and outputs
The sequence moves from sizing and design to a tested, handed-over Moodle site, with each phase closing on a named output the client keeps.
Confirm discovery and sizing
DeployOpen reviews user numbers, course volume, peak exam periods, required integrations and hosting constraints with your team. The output is a sizing and scope document that sets the Moodle release, PHP and database versions, and the features in and out of scope. Duration is set in the written scope.
Design architecture and environments
The team designs the hosting topology, database and file storage, backup approach, and separate development, test and production environments inside your infrastructure. The output is an architecture document and environment inventory that your security and operations teams can review before any build starts.
Build and configure the platform
Engineers install Moodle, set up the database and web server, configure categories, roles, plugins and the theme, and apply the planned course structure. A required checkpoint for Moodle 5.1 and later is pointing the web server document root at the new /public directory instead of the main Moodle folder, since otherwise the site may show directory listings or errors. The output is a configured build on the test environment with a build record.
Run integration and migration trials
SSO, enrolment feeds and any content or user migration are tested with sample data copied from the source system. Trial results show which records map cleanly and which need correction. The output is a trial report listing field mappings, exceptions and the fixes applied.
Complete acceptance testing
Your named testers run scripted scenarios covering roles, enrolments, grading, backups and accessibility checks against the agreed requirements. Defects are logged, fixed and retested. The output is a signed acceptance record that names the open issues accepted for go-live.
Train users and cut over
Administrators, teachers and support staff receive training matched to their roles, and the final data load, DNS change and cutover run to a rehearsed plan with a rollback path. The output is a cutover runbook outcome and a live site with training materials delivered.
Hand over and support
Runbooks, configuration records, backup and restore procedures, and an upgrade plan are transferred to your team, with any agreed support period starting. The output is a handover pack and a documented support route. Ongoing support and upgrades can be taken on under a retainer if you choose.
What stays in-house and what goes to a partner
This table compares the Moodle work your own staff usually keeps with the technical work teams often outsource, showing the skills each side needs and where gaps tend to appear.
| Work area | Usually kept in-house | Often outsourced and skills needed |
|---|---|---|
| Business process and course design decisions | Deciding which programs, courses and assessments move into Moodle, and who approves them. Needs academic leads and process owners who understand how teaching works today. | Facilitating workshops and turning decisions into a category and course structure. Needs Moodle structure experience. Gap: teams often skip the decision step and rebuild the old structure by accident. |
| Course owners and content | Building course content, setting activity completion and maintaining materials after go-live. Needs subject experts comfortable with Moodle activities. | Template courses, content standards and bulk setup scripts. Gap: course owners who were never trained on the chosen activities, so quality varies between departments. |
| Grading and assessment policy | Setting grade scales, pass rules, late submission and appeals policy. Needs an accountable academic or compliance owner. | Configuring gradebook categories and rules to match the policy. Gap: policy is written after build, forcing rework of grade items and aggregation settings. |
| Communication and training | Announcing the rollout, running user training and handling support for end users. Needs change management and trainers who know the local context. | Producing training material and a sandbox for role-based training. Gap: training happens late, close to launch, when most changes are already locked. |
| Acceptance sign-off | Test scenarios, user acceptance testing and the final go or no-go decision. Needs business testers and a named sign-off authority. | Test plans, automated smoke checks and defect triage support. Gap: acceptance is treated as a formality, and defects found in the last week drive the launch date. |
| Linux, PHP and web server build | Providing servers or cloud accounts, network rules and change approval. Needs infrastructure owners who can grant access and review the build. | Building the stack for the chosen PHP and database versions, and the web server document root. Needs Linux, PHP and web server administration. Gap: the document root must point to /public from Moodle 5.1, and a wrong setting causes directory listings or errors. |
| Database and cache tuning | Approving database sizing, backup windows and retention. Needs a database owner who knows the organization's backup standards. | Configuring PostgreSQL or MySQL-family settings, cache stores and session handling for expected load. Needs performance tuning experience. Gap: defaults hold until exam peaks, then sessions and cron slow down. |
| SSO and integration engineering | Supplying the identity provider, attribute standards and sign-off on who may log in. Needs an identity owner. | Configuring OAuth 2, LDAP, Shibboleth or the SAML2 plugin, plus enrolment feeds and grade returns. Needs identity protocol and Moodle authentication experience. Gap: attribute mapping differs from the source directory and breaks logins. |
| Plugin vetting | Approving which plugins may be used and who owns their updates. Needs a risk owner and a list of required functions. | Reviewing code, maintenance status and compatibility with the target Moodle release before installation. Needs PHP code review skills. Gap: plugins abandoned or unsupported for the target version are discovered late. |
| Migration scripting | Confirming which data must move and what history must be kept. Needs data owners who can validate results. | Mapping users, courses, grades and completions and writing repeatable import scripts. Needs database and Moodle backup and restore skills. Gap: legacy data mismatches surface only in test runs. |
| Upgrade testing | Owning the upgrade calendar and accepting test results. Needs a release owner and a test environment budget agreed internally. | Testing each target release against custom code, plugins and integrations, and planning rollback. Needs staging environment skills and Moodle release knowledge. Gap: upgrades are deferred until the platform falls out of support. |
| How the split changes with team size | Small teams with little Moodle experience usually keep governance and content, and outsource most platform engineering. | Larger teams with a dedicated platform group often keep hosting and upgrades and outsource only the specialist integration or migration work. Confirm the skill mix before deciding. |
What usually goes wrong and how to prevent it
Most Moodle rollouts that run late or fail after go-live trace back to a small set of decisions made early or skipped. Each card names the prevention step and who should own the decision.
Hosting sized for average load
Sizing against normal daily use misses the spikes at enrolment, term start and assessment periods, when many users log in and submit at once. Load test with realistic peak numbers from your own calendar, and confirm the hosting plan includes headroom and a way to add web nodes. Decision owner: head of platform engineering, with the academic registrar supplying peak dates.
Web server pointed at the wrong folder
From Moodle 5.1, the web server document root must point to the new /public directory rather than the main Moodle folder, or the site may show directory listings or errors. Make this a checked item in the build runbook and in every upgrade and new server build. Decision owner: the infrastructure engineer who configures the web server.
PHP or database outside release requirements
Each Moodle release names minimum 64-bit PHP versions and supported database engines and versions, and the version chosen affects upgrade eligibility. Check the release notes for the exact target before ordering servers or images, and record the chosen versions in the design document. Decision owner: the platform lead, signed off by the Moodle administrator.
Plugins that block upgrades
Contributed and locally written plugins are often the reason an upgrade stalls, because a plugin may not yet support the target Moodle release. Inventory every plugin before selection, record its supported Moodle versions, and set a rule that a plugin without a maintained path is replaced or removed. Decision owner: the Moodle product owner, with sign-off from the development lead.
Identity attributes that do not map
Single sign-on fails quietly when the identity provider sends attributes that do not match Moodle user fields such as username, email or idnumber, or when a field is blank for some account types. Agree the attribute list with the identity team, map each one to a Moodle field in a test tenant, and confirm how deprovisioning works. Decision owner: the identity lead, with the Moodle administrator.
Course structures built before governance
Building categories, course templates and naming conventions before faculty, department and quality owners agree the rules means rework once courses are already populated. Agree who creates courses, who approves templates and how archiving works before any bulk build. Decision owner: the academic governance board, not the implementation team.
Training delivered too late
Teachers and administrators who first see the new course tools in the week before launch generate support tickets and workarounds that persist. Schedule role-based training after the course template is final and before the pilot cohort starts, and include the help desk in the sessions. Decision owner: the project sponsor, with the head of learning design setting the schedule.
What you need to provide before work starts
The quote for a self-hosted Moodle rollout depends on a short list of inputs from your side. Named owners come first. A Moodle implementation touches academic decisions (course categories, grading rules, completion criteria), IT decisions (hosting, database, backups), security decisions (SSO, MFA, data handling) and HR decisions (who is a learner, who is staff, when accounts end). Without a named person for each area, scope questions wait in a queue and the schedule slips while the quote stays open.
Access and data come next. Give us the target cloud or data centre accounts, network paths to your identity provider and HR or student information system, and a clear view of any existing Moodle server or LMS. For SSO, we need identity provider metadata, the attribute list you release, and the field mapping your directory uses. For provisioning, we need HR or SIS data definitions, such as the field that marks an active learner and the rule for ending an enrolment. Each missing definition adds discovery time, and a guess made here often has to be reworked during testing.
Content and history shape the migration effort. Provide a sample inventory of courses, categories, content types and largest files, plus any existing Moodle or LMS backups in a format you can restore. Branding assets (logo files, colour values, fonts) and accessibility requirements, such as the conformance level your institution has adopted, should also be stated early, since they change theme work and testing effort. A late content inventory is the most common reason a fixed-scope migration needs a change request.
Last, decide the target release and support window. The release determines PHP and database versions, the web server document root and plugin compatibility. For example, Moodle 5.1 requires the web server to point at the /public directory, and Moodle 5.3 removes the Classic theme from core. Confirm the release and the support window with your academic and IT owners before the quote is finalized. A decision made after build work starts usually means rebuilding the test environment and rechecking every plugin.
How the work changes by starting point
A greenfield Moodle site removes migration from the plan, so the work centers on hosting design, course structure, roles and configuration. Scope is driven by how much the design must be settled before the first course is built.
- Version choice: Pick the release line before building. Moodle 5.3 is the next LTS, and its general support runs until 4 October 2027, so confirm which line your governance policy requires.
- Runtime requirements: Moodle 5.3 requires 64-bit PHP 8.3 or later (8.4 supported), PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Confirm these against your image standards.
- Document root: Point the web server at the /public directory, which Moodle 5.1 introduced.
- Design decisions: Category structure, role model, authentication method and theme are settled before go-live, since changing them later affects every course.
- Confirm: Whether your team has a sandbox for pilot courses, and which plugins your policy allows.
Moving from a commercial or hosted LMS adds an export and mapping stage. The source platform's export format, data rights and contract end dates decide how much history can move and when.
- Export scope: Confirm which courses, users, grades, completion records and files the current provider will export, and in what format.
- Mapping work: Plan how source roles, categories and grade items map to Moodle roles, categories and grade structures. Mismatches here are the most common source of rework.
- Parallel running: Confirm whether the old system stays available during the cutover window and for how long.
- Contract terms: Check data return obligations and deletion timing with the vendor before scheduling the cutover.
- Integrations: Identify SSO, roster and gradebook connections the old system uses, since each must be rebuilt in Moodle.
An older Moodle release or a different hosting provider changes the upgrade path and the backup chain, not just the target design. The version you run today sets which steps are required before the target release.
- Upgrade path: Moodle 5.1 requires sites to be on Moodle 4.2.3 or later, and Moodle 5.3 requires 4.4 or later. Older sites need intermediate upgrades, so confirm your current version first.
- Database and PHP: Check whether your current database and PHP versions meet the target requirements, and plan any engine upgrades separately.
- Plugin compatibility: Inventory installed plugins and confirm each has a release for the target version or a replacement.
- Host access: Confirm what the current host allows for database dumps, moodledata copies and server access.
- Confirm: Whether custom code or theme overrides from the old site are still needed, since each one adds test time.
The deployment model changes the build and operations work. A VM build is usually managed as a set of hosts, while a Kubernetes build adds container images, persistent storage and cron scheduling decisions.
- Shared storage: Plan a shared moodledata location that every web node can reach, whichever platform you choose.
- Cron design: Decide whether scheduled tasks run in a dedicated pod, a separate VM or the web tier, and how ad hoc tasks are processed.
- Database placement: Confirm whether the database is managed in the cluster, on dedicated VMs or as a service you control.
- Image pipeline: For Kubernetes, plan how plugins and theme changes are baked into images and how each Moodle upgrade rebuilds them.
- Confirm: Your platform team's standards for ingress, secrets and backup tooling, since these vary by organization.
An air-gapped or sovereign build cannot rely on online downloads, hosted identity providers or vendor-hosted services. Every package, plugin and update has to be brought in through a controlled transfer process.
- Artifact transfer: Plan how Moodle code, PHP and database packages, and each plugin are verified and imported, and who approves each transfer.
- Updates: Security releases and point releases arrive on a schedule you must plan for, so an offline update process needs a fixed intake cadence.
- Identity: Use an identity provider inside the boundary, such as LDAP or a SAML2 plugin connected to an internal IdP, and confirm it is supported in your setup.
- AI and external services: Confirm that any AI provider or external web service is disabled or routed inside the boundary before go-live.
- Confirm: Your accreditation requirements and whether the Moodle release and plugins you need are approved for your environment.
Frequently asked questions
What drives the cost of a self-hosted Moodle implementation?
The cost is driven by scope, not by the Moodle licence, because the core is free and licensed under GPL-3.0. The main components are hosting and sizing, course and category design, roles, plugin and theme work, SSO and enrolment integrations, content migration and staff training. Each component is someone's paid time, and each adds effort in proportion to its complexity. One-time costs include design, build, migration and cutover. Recurring costs include infrastructure, upgrades, plugin maintenance and administrator time. Ask any quote to separate these two groups and to list every integration by name.
Can a Moodle implementation be quoted as a fixed-scope project?
Yes, most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, and a quote follows from that written scope. A fixed-scope quote is only as reliable as its definition, so it should name the hosting target, the number of course categories and roles, each SSO or HR integration, the data to migrate, the themes and plugins in scope, and the training audience. Changes after signature go through a written change process.
How long does a Moodle rollout take, and what sets the timeline?
The timeline depends on how many decisions are still open when the work starts. Hosting choice and sizing, identity integration, the volume and quality of legacy content, and the number of custom plugins or theme changes usually set the critical path. Upgrade targets matter too: Moodle 5.1 requires PHP 8.2 or later and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later, while Moodle 5.3 requires PHP 8.3 or later and PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Ask for a timeline that shows each phase, its dependencies and the client decisions it waits on.
What does DeployOpen need from our team to start?
Before design starts, DeployOpen typically needs named owners for the business process, the identity provider, the HR or student system, and the hosting environment. It also needs access to the target infrastructure, a list of courses or content to migrate with their volume, the branding and accessibility requirements, and a decision on who will administer the site after go-live. The exact list depends on your scope and is confirmed in the written proposal. Missing ownership is one of the most common reasons a fixed timeline slips.
Can our internal team implement Moodle without outside help?
Yes, an internal team can implement Moodle, and the core is free to download and self-host under GPL-3.0. The practical question is capacity and skills. The work spans Linux and web server administration, PHP and database tuning, identity protocols such as SAML 2.0 or OAuth 2, instructional design and migration testing. The plugin ecosystem, which includes more than 50 plugin types, adds maintenance work with every major release. Many teams use outside help for the parts they have not run before and keep course design and daily administration in-house. Test that split against your own staffing before deciding.
Is MoodleCloud or partner hosting a better fit than self-hosting?
It depends on where your data must live, how much control you need over plugins and infrastructure, and who will operate the platform. Moodle can run as self-hosted software, through MoodleCloud, or through Moodle Partners. Self-hosting in infrastructure you control suits organizations with residency, network or integration requirements, and it requires your team or a partner to run upgrades and backups. Managed options reduce operational load but limit what you can change. Compare the options against the written scope, and ask each provider which plugins, identity methods and database versions they support.
How DeployOpen scopes, delivers and hands over Moodle
DeployOpen plans, implements, integrates, documents and supports self-hosted Moodle inside your own cloud accounts, data centers or air-gapped networks. Work is agreed as a fixed-scope engagement, so the plan, cost drivers and deliverables are written down before build begins.
How we scope
- The written scope lists hosting target, sizing assumptions, course and category structure, roles, plugins, theme, SSO and enrolment integrations.
- We confirm which Moodle release line you will run, along with the PHP and database versions that release requires, before any cost is fixed.
- Content migration volume, training audiences and out-of-scope items are named explicitly so the quote can be compared line by line with other proposals.
How we build
- We build in a non-production environment first, configuring course structure, roles and plugins against the agreed design.
- Custom plugins or theme changes are tested against the chosen Moodle version and documented so they can be reviewed before upgrades.
- Integrations for SSO and enrolment data are tested with sample accounts, and the results are recorded against the acceptance criteria in the scope.
How we hand over
- Handover includes architecture notes, configuration records, runbooks for backups, cron and upgrades, and the list of installed plugins.
- Your administrators are trained on the features and tasks named in the scope, using the environment that will go live.
- Cutover and rollback steps are documented and rehearsed before go-live, so your team knows exactly what happens on the day.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after go-live, scoped separately from the build.
- Security patches and six-monthly or LTS upgrades can be planned with test cycles against your plugins and integrations.
- Ask any provider to confirm in writing who maintains the server, who applies releases and how incidents are escalated.
