Moodle or Chamilo: when each platform is the better choice
A small training team with a modest plugin list can reasonably start with Chamilo, while a university LMS program with broad integration needs usually points to Moodle. The answer turns less on license than on scale, the integrations you must support and the people you have to run the system. Both platforms are GPL-family licensed. Moodle is GPL-3.0-or-later and Chamilo LMS is GPLv3 or later, so the license does not separate them. Choose Moodle when you need a large plugin catalog, a broad network of hosting and support partners, or the planning predictability of long-term support releases. Moodle 5.3 is the current LTS with security support until October 1, 2029, and Moodle 4.5 LTS receives security support until October 4, 2027, which gives an institution a clear upgrade calendar.
Chamilo fits teams that want a lighter PHP platform with fewer moving parts and governance held by the Asociación Chamilo, a Spain-registered association that names itself as responsible for data processing on chamilo.org. Its stack is PHP 8.3, 8.4 or 8.5 with MariaDB 10 or later or MySQL 5.7 or later, so a small team with an existing LAMP-style operation may find the footprint manageable. Confirm the release and security support window directly with the association before committing, because the supplied facts do not establish one for Chamilo. Also confirm which authentication connectors your identity provider needs, since Moodle's core list of authentication plugins is documented and Chamilo's equivalent should be verified in its repository.
The decision turns on four questions. First, scale: how many concurrent learners and courses you expect in three years. Second, integrations: whether you need LTI, SSO or SIS feeds that a mature plugin ecosystem already covers. Third, support model: whether you want a commercial partner with Moodle experience or an association and community. Fourth, internal operations skills: who will apply point releases, handle the Moodle 5.1 change that moves the web root to /public, and test upgrades. A team that can answer those four questions honestly will know which platform fits.
Which platform fits which scenario
This table maps common team profiles to the platform that usually fits better and the condition that decides it. Read each row against your own headcount, identity setup, plugin needs and in-house PHP and database skills, because the better fit changes when those conditions change.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Small corporate or association training team | Chamilo, if the team wants a lighter PHP platform with a small set of core features | Choose Chamilo when the catalog is modest and the team can accept a smaller plugin ecosystem. Check whether the features you need exist in core before assuming they can be added later. |
| Single-campus university with a standard course catalog | Moodle | Moodle's wider plugin types, multiple LTS releases and larger partner network matter most when course needs grow. Confirm that your campus can meet the PHP and database versions in the current release notes. |
| Multi-department university with SSO and LDAP | Moodle | Moodle core ships LDAP, OAuth 2, Shibboleth and LTI authentication plugins. Confirm which of these your identity provider needs and which Chamilo supports natively before you commit. |
| Team needing many third-party plugins | Moodle | Moodle's plugin types and marketplace are the deciding factor. Ask Chamilo maintainers which integrations they have, and test each one you depend on against the version you plan to run. |
| Team with limited in-house PHP and database administration | Depends on your support model | Both are self-hosted PHP platforms. Moodle 5.3 requires PHP 8.3 or later and PostgreSQL 17 or MariaDB 11.4 as minimums, while Chamilo requires PHP 8.3, 8.4 or 8.5 with MariaDB 10 or MySQL 5.7 or later. Get a fixed-scope plan for upgrades and patching before choosing. |
| Team that needs a long support window for the platform version | Moodle | Moodle 4.5 LTS receives security support until October 4, 2027 and Moodle 5.3 LTS until October 1, 2029, according to the Moodle releases page. Confirm Chamilo's support policy directly with the Asociación Chamilo before relying on it. |
| Team wanting a single hosted option with minimal setup | Neither, self-hosting is required | Moodle offers MoodleCloud and Moodle Partners, which are not covered by these facts. Confirm hosting options for Chamilo with its association before comparing. |
How Moodle and Chamilo are built and deployed
Both platforms are PHP applications that run on standard web and database stacks inside your own infrastructure. The differences that matter sit in version floors, web server layout and how often you must touch the stack, so check these against your current servers before comparing features.
PHP runtime and patch cadence
Moodle 5.3 requires 64-bit PHP 8.3 or later, with 8.4 supported. Chamilo requires PHP 8.3, 8.4 or 8.5. Both floors move with each major release, so a PHP upgrade can become a prerequisite for a platform upgrade. Confirm which PHP versions your operating system vendor still patches, and schedule PHP and platform upgrades together so you do not run an unsupported interpreter in front of learner data.
Database versions and operations
Moodle 5.3 lists PostgreSQL 17, MySQL 8.4, MariaDB 11.4 and SQL Server 2019 as the supported versions in its requirements. Chamilo asks for MariaDB 10 or later, or MySQL 5.7 or later. Chamilo's lower floor may suit an existing MySQL estate, but database engines reach end of life too, so confirm the version your DBA team will support for the full life of the platform release you pick.
Document root and web server configuration
From Moodle 5.1, the web server document root must point to the /public directory, not the main Moodle folder. If it does not, the site may show directory listings or errors. Chamilo does not carry this requirement, so an Apache or Nginx configuration written for one platform will not carry over. Plan the vhost, TLS and PHP-FPM settings per platform and include the change in your deployment runbook and rollback steps.
Upgrade paths and version prerequisites
Moodle 5.3 can only be upgraded from Moodle 4.4 or later, and Moodle 5.1 required sites to be on 4.2.3 or later. An older site may need intermediate upgrades, each with its own database and plugin checks. Chamilo's upgrade path depends on its own release notes and database migrations, so ask the Chamilo association or your implementation partner to document the exact route from your current version before you commit to a date.
Managed hosting options
Both platforms can run on a self-managed LAMP-style stack in your cloud account or data center. Moodle also offers managed hosting through MoodleCloud and Moodle Partners, which moves patching and database operations to a vendor. Chamilo's hosting market is smaller, so ask for named hosting providers and their support terms in writing. Managed hosting changes who owns the upgrade calendar, backups and incident response.
How Moodle's LTS windows compare with Chamilo's release practice
Moodle publishes its support dates in advance, which makes its risk easy to plan. Major releases arrive in April and October, and point releases follow every two months. Moodle 4.5 LTS receives security support until October 4, 2027. Moodle 5.3, the current LTS, has general support until October 4, 2027 and security support until October 1, 2029. Moodle 5.1 has general support until October 5, 2026 and security support until April 19, 2027, and Moodle 5.2 has security support until October 4, 2027. Put these dates in your planning calendar, and check them against the Moodle releases page before you choose a target version.
The upgrade prerequisites decide which version you can reach in one step. Moodle 5.3 requires sites to run Moodle 4.4 or later, and Moodle 5.1 requires 4.2.3 or later. A site older than these versions needs an intermediate upgrade before it can move forward, so record your current version and plugin versions before you schedule anything. Also note that from Moodle 5.1 the web server document root must point to the /public directory. Your web server configuration is a change you must test during the upgrade, not after it.
For Chamilo, the supplied information covers the license (GPLv3 or later) and the runtime, which is PHP 8.3, 8.4 or 8.5 with MariaDB 10 or later, or MySQL 5.7 or later. It does not establish a published release cadence, a list of versions that receive fixes, or how long each one is supported. Do not assume Chamilo follows a Moodle-style LTS model. Before you commit, ask the Asociación Chamilo for its written release and support policy, including how security fixes are delivered to older branches, and check the chamilo-lms repository for the current release history. Compare the answers with Moodle's dated windows when you score long-term maintenance risk.
Side-by-side feature and requirement comparison
This table sets Moodle and Chamilo against the questions that usually decide a shortlist: license, PHP and database floors, authentication, plugins, hosting and governance. Where the supplied research does not confirm a Chamilo capability, the cell tells you what to check in the repository before you rely on it. Read the Moodle column as confirmed from release notes and core code, and treat unconfirmed Chamilo cells as due diligence items.
| Capability | Moodle | Chamilo |
|---|---|---|
| License | GPL-3.0-or-later, per COPYING.txt in the moodle/moodle repository | GNU GPLv3 or later, per the chamilo/chamilo-lms repository |
| PHP requirement (current major) | 64-bit PHP 8.3 or later for Moodle 5.3, with 8.4 supported | PHP 8.3, 8.4 or 8.5 per the chamilo-lms repository |
| Supported databases | PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later for Moodle 5.3; Oracle dropped from 5.0 | MariaDB 10 or later, or MySQL 5.7 or later |
| Built-in authentication | Manual, email self-registration, external database, LDAP, LTI, OAuth 2, Shibboleth and web services in core | Confirm in the repository which LDAP, SSO and OAuth methods are included or need extensions |
| SAML2 single sign-on | Available as the auth_saml2 plugin on the Moodle marketplace | Confirm whether SAML is supported natively or by plugin before planning federation |
| Plugin model | Typed plugin ecosystem with a large marketplace and documented plugin types | Confirm the plugin or extension mechanism and the size of its catalog in the repository |
| Managed hosting options | Self-hosted, MoodleCloud, or Moodle Partners | Confirm whether the Asociación Chamilo or other providers offer hosted plans |
| Governance and steward | Moodle HQ (Moodle Pty Ltd) maintains the code and sells hosting | Asociación Chamilo, registered in Spain, is responsible for data processing on chamilo.org |
License and edition models for each platform
Moodle's code is licensed under GPL-3.0-or-later, as stated in the COPYING.txt file of the moodle/moodle repository. That licence lets your organization download the software, run it on infrastructure you control, modify it and redistribute it under the licence terms without paying a licence fee to Moodle HQ (Moodle Pty Ltd), which maintains the project. Your costs are the people and infrastructure that run the site, plus any paid support, hosting or plugin work you buy. Moodle can be reached in four ways:
- Self-hosted download. The code is free to download and run on your own servers, cloud accounts or private networks. You carry hosting, administration, upgrades and any customization.
- MoodleCloud. Moodle HQ's own hosted plans. Confirm current user limits, storage, plugin rules and data export terms on the vendor's pages before you commit.
- Moodle Partners. Independent providers that can host and support Moodle for you. Each partner sets its own scope, pricing and service levels.
- Moodle Workplace. A separate proprietary product, not the GPL code described here. Its licensing and purchase route are covered in the Moodle LMS vs Moodle Workplace comparison.
Check the licence of every plugin you plan to use, because plugins are separate code from core and carry their own terms.
Chamilo LMS is published under the GNU GPLv3 or later license, according to the chamilo/chamilo-lms repository on GitHub. Like Moodle, it can be downloaded and self-hosted, and the licence allows you to modify it under its terms. Chamilo.org says the platform serves more than 41 million learners worldwide. That is the project's own statement about reach, so treat it as context for scale rather than as evidence that the platform fits your deployment. Chamilo.org also names the Asociación Chamilo, registered in Spain, as the entity responsible for data processing on that site. Use the following points as your starting checklist:
- Licence scope. GPLv3 obligations apply when you distribute modified versions, which differs from running a modified copy internally. Ask counsel to confirm how this applies to your planned customizations.
- Governing entity. The Asociación Chamilo is the body Chamilo.org names for data processing on that site. Ask whether it, or any listed provider, offers paid support, hosting or contracts for self-hosted installs.
- Learner count. The 41 million figure is attributed to Chamilo.org. Verify it against your own evaluation criteria before you use it in a business case.
- Hosting route. The supplied information covers self-hosting. Ask whether a managed option exists, who would sign it and where the data would sit.
Confirm the hosting and support arrangement in writing before you assume the licence terms are the whole cost picture.
Neither platform's paid support terms are covered in this comparison, so service levels, prices and coverage must come from each vendor or partner in writing. Request the same information from every provider so the options can be compared on equal terms. The items below are the ones that most often change the total cost:
- Moodle Partners. Written scope, support hours, response targets, how upgrades to the version you run are handled, and which party holds the hosting contract.
- MoodleCloud. Current plan limits, storage allowances, custom domain and course selling options, and what happens to your data if you leave.
- Chamilo providers. Whether the Asociación Chamilo or any named provider offers support contracts, and whether they cover the PHP and database versions you plan to run.
- DeployOpen. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms inside your own infrastructure, under fixed-scope work agreed in writing. It is not an official partner of Moodle or Chamilo, and it publishes no price list, so a quote follows from the written scope.
Ask each provider to separate one-time setup costs from recurring support and upgrade costs, so you can see what recurs each year.
What drives running cost on each platform
Running Moodle or Chamilo is mostly a set of recurring jobs: hosting, database and PHP administration, upgrades, plugin upkeep, backups and support. Each job has a payer, either your own staff, a hosting provider, or a partner billing against a written scope, and the balance between them determines the total.
Server and database hosting
Your infrastructure bill is recurring and depends on the users, storage and availability you require. Moodle's release notes name supported database engines per version, including PostgreSQL 17, MySQL 8.4 and MariaDB 11.4 for Moodle 5.3, while Chamilo requires MariaDB 10 or later or MySQL 5.7 or later. Ask a partner to price the database tier, backup storage and any staging environment as separate line items.
PHP and database administration
Both platforms are PHP applications, so someone must patch the runtime, tune PHP-FPM and manage database versions on a schedule. Moodle 5.3 requires 64-bit PHP 8.3 or later, and Chamilo supports PHP 8.3, 8.4 or 8.5. This is a recurring internal or contracted task, and it grows when the host runs several environments such as production, test and training sandboxes.
Upgrade labor per release
Moodle ships major releases every six months and provides LTS windows, so the upgrade effort you plan around depends on which branch you run. Moodle 4.5 receives security support until October 4, 2027, and Moodle 5.3 until October 1, 2029. Chamilo's support windows should be confirmed in writing before you commit. Ask any partner to quote the test cycle, plugin re-validation and rollback plan for each upgrade.
Plugin maintenance
Plugins are a recurring cost wherever they exist. Moodle's large plugin ecosystem gives more choice but also more code to check against each new core release, and every plugin you add may need its own compatibility review. Chamilo's plugin footprint should be assessed against the features you need. Ask for an inventory of installed plugins, the owner of each update and the cost of re-testing after a core upgrade.
Backup and disaster recovery
Backups are an ongoing service, not a one-time setup. You need tested restores of both the database and the file store, plus an off-site copy that meets your retention rules. Ask for the recovery time and recovery point the partner commits to in writing, how often restores are rehearsed and who holds the restore keys. Storage charges recur monthly and grow with course media and learner records.
Paid support and partner fees
Support is where cost models differ most. Moodle is available through Moodle Partners and managed hosting, while Chamilo has its own association and partner channels. Decide whether you need a retainer for upgrades and incident response or a fixed-scope project for a single change. Request the response targets as written in the contract, the rate card for out-of-scope work and any charges that apply only to certain user counts.
Moving from Chamilo to Moodle or back: what transfers and what is rebuilt
This sequence gives you a verified inventory of what can move between Chamilo and Moodle, a tested path for one pilot cohort, and a controlled cutover with a clear record of what was rebuilt by hand. Most of the effort sits in mapping data and activities, not in copying files.
Inventory courses, users, roles and grades
Your team lists every course, active and archived, with its owner, enrollment counts, roles, grade structure and the activity types each course uses. Export a sample from the source platform and check which fields it carries, such as user identifiers, enrollment dates and gradebook weights. The step is done when you hold a signed-off inventory that shows which items you must migrate, which you will archive and which you will rebuild. Ask the implementation partner to flag any Chamilo tool that has no direct Moodle equivalent before you commit to a scope.
Inventory files and integrations
List the uploaded documents, media, SCORM or other packaged content, external tool connections, single sign-on settings, and any scheduled reports or data feeds that depend on the platform's database. Record where each file is stored and how it is linked from course pages, because broken links are the most common visible failure after a move. The step is complete when every integration has an owner and a decision: migrate, replace or retire. Confirm with each platform's documentation which export formats are supported in the versions you run, since tooling changes between releases.
Confirm export and import formats in current versions
Read the export and import documentation for the exact Chamilo release in production and the Moodle release you will target, then run a small test export and import in a non-production copy. Check whether course backup and restore, user files, grades and enrollments each survive the round trip, and note any field that is dropped or altered. The step is done when a written test report lists what transferred intact, what needed manual correction and what was not supported. Treat vendor documentation and your own test results as the source of truth, not assumptions from older guides.
Map activities and rebuild plugin-dependent features
Course-level activities rarely map one to one between the two platforms. Quizzes, forums, assignments, certificates and reporting may need to be recreated, reconfigured or accepted as a different activity type, and any feature that depended on a Chamilo extension needs a Moodle plugin or a custom build. Authentication also has to be rebuilt on the target: Moodle core includes manual, email self-registration, external database, LDAP, LTI, OAuth 2, Shibboleth and web services authentication, and other methods come from plugins such as the SAML2 single sign-on plugin, which should be verified against your identity provider. The step is complete when a mapping sheet shows each activity as migrated, rebuilt or dropped, and each login path has been tested.
Run a pilot cohort
Choose one course with a representative mix of activity types and a small group of learners and instructors who can report problems quickly. Run the course on the new platform with real enrollments, grades and logins for a full teaching cycle, while keeping the original platform available for reference. Track login failures, broken links, grade discrepancies and instructor questions in one log. The pilot is done when the owners sign off that grades reconcile with the source records and that no learner-facing step is blocked.
Reconcile data and fix gaps
Compare grade totals, enrollment counts and file checksums between the source and target for every migrated course, and document each difference with its cause. Fix mapping errors in the staging environment, then re-run the affected imports so the corrected data is what you cut over. The step produces a reconciliation report that a course owner has approved for every course in scope. Keep the source system read-only from this point so that no grades or submissions are written after the reconciliation snapshot.
Cut over users in controlled waves
Move the remaining courses and users in batches, with a freeze window announced to instructors and learners, a final data export and import, and a rollback plan that names who can reverse the change. Redirect links, update single sign-on and notification settings, and confirm the web server is serving the correct document root for the Moodle version you deploy. The cutover is complete when all in-scope users can sign in, the reconciliation checks pass on production, and the support team has closed the pilot issues or moved them to a known-issues list. Retain the source platform in read-only mode for an agreed period before decommissioning it.
Where LMS implementations usually run long
The longest delays in a Moodle or Chamilo rollout usually come from upgrade and hosting prerequisites discovered late, not from the course build itself. For Moodle, the document root change in Moodle 5.1 is the first check: from that release the web server must point to the new /public directory instead of the main Moodle folder, or the site may show directory listings or errors. Teams that copy an older Apache or Nginx configuration into a new environment often lose a day or more to this. Moodle 5.3 also raises the floor to 64-bit PHP 8.3 or later, and it requires PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Sites must already run Moodle 4.4 or later to upgrade to 5.3, so an older instance may need an intermediate upgrade path. Map your current PHP and database versions against these minimums before estimating anything, and ask any implementation partner to show the upgrade path in writing.
Chamilo carries the same kind of risk in a different place. Its repository lists PHP 8.3, 8.4 or 8.5 with MariaDB 10 or later, or MySQL 5.7 or later, so the PHP jump and database choice must be settled before installation. Identity and plugin work is where scope is most often under-counted. Moodle ships core authentication for LDAP, LTI, OAuth 2, Shibboleth and web services, and SAML 2 single sign-on is available as a plugin from the Moodle marketplace, so SSO scoping is largely a matter of selecting and testing known components. For Chamilo, confirm in writing which SSO protocols, directory connectors and plugin hooks the version you choose supports, and whether any of them need custom code you would have to maintain. Also plan for testing with real cohorts, including course and user migration from the current system, role mapping, and staff training on the admin and teacher workflows. Ask any vendor or partner to estimate these phases separately so that an identity or migration gap does not surface after go-live.
Questions buyers ask before choosing or hiring help
How much work does self-hosting Moodle involve?
Self-hosting Moodle makes your team responsible for the PHP runtime, the database, the web server, upgrades, plugin compatibility and backups. Moodle 5.3 requires 64-bit PHP 8.3 or later and, from Moodle 5.1 onward, the web server document root must point to the new public directory, so server configuration needs attention at every major upgrade. Major releases ship in April and October and minor point releases every two months, so someone must own a regular upgrade calendar. Moodle 4.5 LTS receives security support until October 4, 2027, and Moodle 5.3 LTS receives security support until October 1, 2029, which gives you a planning horizon. Confirm with your team how many hours each month you can commit to patching, testing and plugin review before you choose a hosting model.
Can a small training team run Moodle or Chamilo alone?
A small team can run either platform alone only if one or two people own patching, backups, monitoring and the upgrade calendar with a clear backup plan. The supplied facts show Chamilo requires PHP 8.3, 8.4 or 8.5 with MariaDB 10 or later, or MySQL 5.7 or later, so the stack is familiar to many PHP shops. Moodle adds a documented release rhythm and a plugin system that needs compatibility checks at each upgrade. The deciding factors are usually:
- Whether one person can cover on-call work during course launches
- How many plugins or custom themes you run
- Whether you need integrations with an identity provider or student information system
- Whether staff can test upgrades in a non-production copy before go-live
Illustrative example: a training team with one administrator and no test environment will usually need outside help for the first upgrade. Ask the vendor or community for the current support window for Chamilo releases before you commit.
What does a fixed-scope implementation from DeployOpen include?
A fixed-scope implementation covers the work agreed in writing before it starts, including the scope, deliverables and timelines. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an LMS, that typically means agreeing the hosting architecture, installation, authentication integration, custom plugin or theme work, security hardening, backup and restore testing, and the operating documentation your staff will use. Ongoing support, upgrades and continuous testing are available as retainers, which is useful if your team wants help beyond the first go-live. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the deliverables list, the acceptance criteria and the exclusions in writing so you can compare proposals on the same terms.
How long does a learning platform migration take and what drives it?
The supplied facts do not give a migration duration, so confirm the estimate against your written scope rather than a generic figure. The duration depends mainly on the volume and format of course content, the number of user accounts and enrollments to move, the number of customizations and integrations to rebuild, and how much testing your staff can perform. Upgrade paths also matter: Moodle 5.1 requires sites on Moodle 4.2.3 or later, and Moodle 5.3 requires sites on Moodle 4.4 or later, so an older install may need intermediate steps first. Chamilo migrations depend on its own database and content structure, which you should verify with the Chamilo project before planning. Ask any implementation partner to break the estimate into data mapping, content transfer, authentication cutover, user acceptance testing and rollback planning.
Is Moodle or Chamilo better for SSO and LDAP?
Moodle has the more documented authentication coverage in the supplied facts, so it is the safer default if your identity plan is still open. Moodle core ships authentication plugins for manual accounts, email self-registration, external database, LDAP, LTI, OAuth 2, Shibboleth and web services, and the SAML2 Single sign on plugin is available from the Moodle Marketplace for SAML-based identity providers. Chamilo's supported authentication methods were not part of the supplied facts, so confirm LDAP, SAML and OAuth support in its repository and documentation before you choose it. Whichever platform you pick, test the directory schema, group mapping, account lifecycle and logout behavior with a copy of your real identity provider, not a sample directory. The better fit depends on your identity provider, not only on the LMS.
What does the work need from IT and training staff?
The work needs IT staff to provide and secure infrastructure, and it needs training staff to define how courses, assessments and reporting should work. On the IT side, expect requirements for a server or cloud environment, DNS and TLS certificates, a supported database, outbound mail, identity provider configuration, backups and monitoring. On the training side, expect requirements for:
- A named content owner who can approve course structures and accessibility checks
- Test accounts and sample courses for user acceptance testing
- Decisions on roles, enrollment rules and reporting needs
- Staff time to learn the administration and course-building workflow
Illustrative example: if the training team cannot sign off test courses on time, the cutover date moves even when the infrastructure is ready. Agree these responsibilities in the written scope before work starts.
How do Moodle and Chamilo support windows compare?
Moodle publishes its support windows for each release, which makes it easier to plan a multi-year platform. Moodle 4.5 LTS has security support until October 4, 2027, and Moodle 5.3 LTS has general support until October 4, 2027 and security support until October 1, 2029. Moodle 5.1 has general support until October 5, 2026 and security support until April 19, 2027. The supplied facts do not include Chamilo's equivalent support windows or LTS policy, so ask the Chamilo association for its current release policy, patch cadence and any commercial support options before you commit. Compare both platforms on the window you need to cover, not only the latest release. Your budget and staff plans should reflect the date when security patches stop, because that date drives the next forced upgrade.
How DeployOpen helps choose, implement or migrate an LMS
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Moodle vs Chamilo decision, we start by writing down the platform requirements, the hosting target and the team that will run the system, then build against that agreed scope.
How we scope
- Written scope covers the platform choice, target hosting environment and required database and PHP versions.
- Scope lists which authentication methods, plugins or integrations each platform must support for your users.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We install and configure the chosen platform in your cloud account, data center or air-gapped network.
- Integrations such as single sign-on, plugins and content migration are built and tested against your own data.
- Security hardening and backup routines are implemented and tested before any learners are onboarded.
How we hand over
- Documentation covers installation, configuration, upgrade steps and the support windows of the release you run.
- Handover includes runbooks for backups, restores, plugin updates and the web server document root configuration.
- Your team receives written records of configuration decisions, so the platform can be run without us.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover planned moves between Moodle release branches as each support window approaches its end.
- Ask for the support scope, response arrangements and upgrade approach in writing before you sign.
