A change takes longer than expected. Nobody is sure who updates the plugins. Or your organisation wants to develop its learning platform further, but the current support arrangements no longer fit. Can you move to another Moodle™ provider without starting again?
Often, yes. A responsible handover starts with understanding the existing platform: what works, who has access and which tasks the transfer includes. This guide helps you prepare that conversation, with a checklist for both your current and prospective provider.
When does switching providers make sense?
A different provider may suit an organisation that needs direct access to a developer, help with custom software or clearer maintenance and support arrangements. New audiences or additional integrations can also be reasons to review the relationship.
First, describe the problem precisely. Gather outstanding changes, recurring incidents and unanswered questions, and discuss them with your current provider. Sometimes a clearer division of responsibilities is enough.
If you do switch, define what the new relationship should improve. “Faster support” is difficult to assess. “A named contact, a distinction between incidents and change requests, and visibility into the maintenance schedule” gives both parties something concrete to work with.
Does the platform need to be rebuilt?
A new provider does not automatically mean a new platform or new hosting. There are three situations:
- Only management changes. The platform stays on its existing infrastructure, where access and agreements allow it.
- Hosting changes too. The existing platform moves to different infrastructure and is checked there.
- Technical repairs are also needed. Outdated plugins, missing source code or changes to Moodle™ core require additional investigation and work.
Ask for these elements to be estimated separately. That helps distinguish essential handover work from improvements that can follow later.
Moving a complete site involves its database, Moodle™ code and uploaded files together. A collection of course backups is not a substitute for a complete site backup. The official Moodle™ site backup documentation explains those components.
A hosting move and a version upgrade are also separate tasks. Ask for the sequence to be explained and tested. The Moodle™ migration documentation addresses this distinction. For a wider upgrade or platform migration, see our technical migration guide.
What needs to be handed over?
Request one handover document showing who is responsible for each item, where it is stored and whether the incoming provider can access it.
System and administration access
Include Moodle™ administration accounts, hosting, domain and DNS management, certificates, email services and monitoring. An administrator account inside Moodle™ does not itself provide server or database access.
Use individual accounts and an agreed secure transfer method. Do not send passwords or full backups through an ordinary contact form. Agree when old accounts will be revoked and shared credentials replaced.
Source code, plugins and documentation
Request a list of plugin versions, themes, custom software and any modifications to Moodle™ core. Include the corresponding source code, installation instructions and version control. For paid plugins, establish who manages the subscription and which access is needed for updates and support.
Have a developer check that the available code matches what is running in production. An old repository missing recent changes is not a complete handover. Gaps should be visible in the inventory before anyone commits to a schedule.
Integrations and background tasks
List SSO, user imports, HR systems, webshops, payments, reporting and scheduled tasks. For each integration, record the contact, service accounts, direction of data exchange and how its operation will be checked.
A working homepage does not prove that a new employee is enrolled automatically or that a purchased course becomes accessible. Those everyday processes belong in acceptance testing. Read how we connect Moodle™ to other systems.
Data handling and support arrangements
Agree who handles incidents during the handover, who approves the final switch and when responsibility for backups and monitoring changes. Document how copies of personal data will be handled and when temporary environments and old copies will be removed. Carry existing contractual arrangements into the handover plan.
What does a careful handover involve?
1. Inventory and scope
The incoming provider reviews the technical condition and available access. The outcome is a list of what can be taken over, what is missing and what work is needed. Agree which findings must be addressed first and which can follow later.
2. Checks in a restricted test environment
Where a copy is needed, restrict access to the people involved. Limit personal data to what the checks require. Prevent the test environment from sending real emails, processing payments or writing data back to production systems.
Verify that the backup can actually be restored. Then test representative roles: a participant signing in, a teacher marking work and an administrator producing a report. Include certificates, course completion and integrations where the organisation relies on them.
3. Prepare the switch
Agree the timing, any downtime and the communication plan. For a hosting move, specify when the final data transfer happens and when changes to the old environment stop. Avoid participants working in two different environments at the same time.
Define a rollback plan too. Who decides to revert, until when is that possible and what happens to data added after the switch? Restoring an earlier backup must not cause an unplanned loss of new results.
4. Acceptance and follow-up
After the switch, repeat the agreed checks of user processes. Check email, scheduled tasks, monitoring and backups as well. Record outstanding items, assign owners and agree a review date.
Retire the old environment according to the agreed acceptance and retention arrangements. Make sure day-to-day Moodle™ hosting and maintenance arrangements start when the incoming provider takes responsibility.
What determines cost and timing?
A dependable estimate needs more than a user count. Data volume, available access and documentation, the number of integrations and the condition of custom plugins all matter. A required upgrade, limited maintenance windows and the availability of other suppliers also affect the schedule.
Ask for a proposal separating discovery, any repairs, the hosting move, testing and follow-up. Separate one-off transfer costs from ongoing management. Ask which assumptions apply and what happens if discovery reveals missing code or a broken integration.
There is no single responsible timeline for every platform. Base the plan on the findings and allow time for your own team to check the results.
Handover meeting checklist
Take these questions to both your current and prospective provider:
- Is it clear what changes: management, hosting, software version or a combination?
- Are the required accounts, source code, files and database available?
- Have custom software, plugin subscriptions and technical dependencies been identified?
- Is ownership of domain, DNS, email and integrations documented?
- Has a complete backup been restored and checked?
- Have the key user processes been tested in the test environment?
- Are communication, the maintenance window and rollback plan agreed?
- Is incident responsibility clear during and after the switch?
- Are acceptance, follow-up and revocation of old access arranged?
- Are one-off costs, ongoing management and any later improvements described separately?
Discuss a handover with Ldesign Media
You do not need a complete technical dossier before the first conversation. Tell us what you want to improve, which platform you use and what information is already available. Do not share passwords or personal data at this stage.
At Ldesign Media, you discuss your requirements directly with a developer. Together, we identify the information needed to assess what can stay and what needs attention. Whether you need maintenance of existing custom software or a handover involving an upgrade and migration, the proposal should fit your platform.
