Moodle services
Moodle migration services
All-in-One LMS moves organizations onto Moodle™ from other learning platforms, relocates existing Moodle sites to new servers or hosts, and changes the database engine underneath them. Our Moodle migration services are for L&D, IT and e-learning teams who need users, courses and assessment records carried across in rehearsed stages, with a cutover planned to minimize downtime and a way back if something fails.
What a Moodle migration is
A Moodle migration is the planned transfer of users, courses, learning content, assessment data and configuration into a Moodle LMS site, or from one Moodle environment to another. It is finished when the new site has been checked against the old one and people are working in it. Copying files is the small part. Deciding what each piece of source data becomes in Moodle, and proving that it arrived intact, is the project.
The work falls into three kinds.
| Kind of migration | Usual trigger | How the data moves | Where the risk sits |
|---|---|---|---|
| From another LMS to Moodle | License cost, contract renewal, control over hosting and code | Source exports, converted into formats Moodle can import | Content the source cannot export in a reusable form |
| A Moodle site to a new server or host | New provider, cloud move, end of hardware life | Database dump, moodledata and code are copied, then config.php is updated | Changing server, URL and version in one step |
| A change of database engine | Policy, cost, or a database Moodle no longer supports | Moodle's database transfer tool | Schema differences and badly encoded data |
Why migrations run into trouble
A common failure we see is a project that starts without an inventory, so nobody can say how many courses are live, who owns them or which can be left behind.
The second is treating an export file as a backup of everything. Most systems export course content and leave out what learners did: submissions, posts, attempts and grades. The third is testing only as an administrator, then finding on day one that teachers cannot see their gradebooks. Our article on common LMS migration mistakes covers the pattern in more depth.
How Moodle takes data in
Every move into Moodle uses some combination of the mechanisms below. Knowing their limits early keeps the estimate honest.
| Mechanism | What it carries | Limit to plan around |
|---|---|---|
Course backup and restore (.mbz files) | A whole Moodle course: activities, blocks, filters and, optionally, enrolled users with their data | Moodle to Moodle only. Restoring onto an older Moodle version than the backup came from can fail |
| Upload users (CSV) | Accounts, profile fields, cohort membership, and course enrollments with a role | The file must contain username, firstname, lastname and email |
| Upload courses (CSV) | Course shells in bulk, each optionally filled from a backup file or a template course | The content still has to exist as a backup or a template |
| Question import | Question bank content in formats that include GIFT, Moodle XML, Aiken and a Blackboard format | The standard formats do not include a general QTI importer |
| SCORM activity | SCORM 1.2 packages, and AICC | SCORM 2004 is not supported natively |
| IMS Common Cartridge | Cartridges in versions 1.0 and 1.1, loaded through the course restore screen | Moodle's docs state that only 1.0 and 1.1 are imported, so 1.2 and 1.3 packages need another route |
| Grade import | Grades from a CSV or XML file, or pasted from a spreadsheet | Grades arrive in the gradebook without the submissions behind them |
| Web services and command-line scripts | Whatever the tools above cannot express | Custom work, written and tested per project |
The migration process, step by step
These thirteen steps apply to a move from another LMS. Server moves and database changes use a shorter version, covered below.
Plan
1. Discovery. We list what exists: every course, who uses it, which systems feed it (sign-in, HR or student records, payments, LTI tools) and what the source can export. The output is an inventory with a decision against each course: migrate, archive or retire. Leaving unused courses behind is the cheapest saving in the project.
2. Data assessment. For each data type we record the export format, the volume and the quality. Duplicate accounts, users with no email address and broken file links are cheaper to fix before the move than after it. This is also where we establish what history you must keep, such as grades for accreditation or completion records for audits.
3. Role mapping. Moodle's standard roles include Manager, Course creator, Teacher, Non-editing teacher, Student, Guest and Authenticated user. Source roles seldom line up one to one. A teaching assistant, an observer or a branch administrator is either mapped to a standard role or given a custom role with matching permissions. The mapping is settled before any user is loaded, because every enrollment depends on it.
4. Custom plugin and theme compatibility. Features the old platform had that Moodle core lacks are matched to a setting, an existing plugin or a new one, which is where our custom plugin work comes in. Branding and course layout belong in a theme, described on the theme development page. When the source is itself a Moodle site, every third-party plugin is checked against the target version, since an activity type that is not installed on the target cannot be restored there.
5. Database considerations. We confirm the target database engine and version against the requirements of the Moodle release you are moving to, and decide whether historical logs come across at all. Conversion scripts write through Moodle's own APIs and import tools, not straight into tables, so caches, completion and grade totals stay consistent.
Move
6. User migration. Accounts are loaded with the Upload users tool, which can add new users, update existing ones or both. Each source user ID is kept in Moodle's ID number field so that enrollments and grades can be matched later. Stored password hashes rarely move between systems, so users either receive a generated password by email, which the tool supports, or sign in through your identity provider once single sign-on is in place.
7. Course migration. Categories are set up first, because the Upload courses tool does not create them. Course shells are then created in bulk from a CSV, and each shell is filled from a Moodle backup, a template or converted source content. A course template is agreed first, so that migrated courses look like one site.
8. Content migration. Files, pages, videos and packages are moved and re-linked. SCORM 1.2 packages upload as they are. SCORM 2004 packages are republished as 1.2 where the authoring tool allows it; our comparison of SCORM, xAPI and cmi5 explains the differences. Links inside pages that point back at the old LMS are rewritten, or they break on the day that system is switched off.
9. Assessment migration. Question banks are converted into Moodle XML or GIFT and imported. Question types with no Moodle equivalent are rebuilt by hand and listed for the course owner. Quiz settings such as timing and attempts are re-created, rubrics are rebuilt as Moodle advanced grading forms, and historical grades are loaded through grade import where you need them.
Prove
10. Testing. The full data set is run into a staging site and timed, so the length of the real cutover is known in advance. Tests are run as real roles: a teacher grading, a student submitting, a manager pulling a report.
11. Validation. Counts are reconciled between source and target: users, enrollments per course, activities per course, questions per bank, and grade totals for a sample of learners. Course owners sign off their own courses against a short checklist. Defects are fixed in the conversion scripts, not by hand, so the final run reproduces every fix.
Switch
12. Cutover. The source is frozen or set to read-only, the final run brings across anything that changed since the rehearsal, and sign-in, links and DNS are pointed at Moodle. We schedule it for a quiet period, such as a gap between terms, and plan it to minimize downtime.
13. Rollback planning. The old system stays intact and read-only until an agreed date. Before cutover we write down who can call a rollback, by what time and on what evidence. Work done in Moodle after go-live would be lost if you went back, which is why that decision window is kept short.
What transfers, and what does not
Not everything moves. This table is a general guide, and the data assessment replaces it with specifics for your source system.
| Item | Typical outcome | What decides it |
|---|---|---|
| User accounts and profile fields | Usually transfers | Available as a CSV or report from almost every system |
| Enrollments and roles | Usually transfers | Needs the role mapping agreed first |
| Uploaded files, video and SCORM 1.2 packages | Usually transfers | You need the originals or an export that includes them |
| Common question types (multiple choice, true/false, short answer, essay) | Transfers with work | Conversion into a format Moodle imports |
| Course structure and pages | Transfers with work | Converted from the export or rebuilt on a template |
| Final grades and completion records | Transfers with work | Imported as records, without the underlying activity data |
| Rubrics | Transfers with work | Rebuilt in Moodle's own grading tools |
| Assignment submissions and forum posts | Transfers with work, or is archived | Many exports leave them out; scripts or an archive site fill the gap |
| Passwords | Usually does not transfer | Hash formats differ between systems |
| Content authored in a vendor's own builder | Often does not transfer | Depends entirely on what the vendor lets you export |
| Activity logs and analytics history | Usually does not transfer in a usable form | Kept as an archive export for audit purposes |
| LTI tool connections | Does not transfer | Each tool is registered again on the new site |
Ask for a transfer assessment of your LMS
Migrating to Moodle from another LMS
From Canvas
A Canvas course exports as a Common Cartridge package, and quizzes can also be exported as QTI files. Instructure's guide states that the export leaves out student interactions and grades, and Moodle imports only two Common Cartridge versions, so each course needs checking after it lands. Our Canvas to Moodle guide sets out what happens to each item.
From Blackboard
Blackboard produces export and archive packages as ZIP files and can export Common Cartridge as well. Moodle's own documentation describes a restore function for Blackboard packages that existed in Moodle 1.9 and is marked as not supported in 2.x, so current projects rely on Common Cartridge, the Blackboard question import format and scripted conversion. The Blackboard to Moodle page has the detail.
From WordPress LMS plugins such as LearnDash
LearnDash has an import and export tool that packages courses, lessons, topics, quizzes, questions and users into a ZIP file, built for moving between LearnDash sites. Moodle cannot read that file. We convert lessons and topics into Moodle pages and activities, turn quiz questions into Moodle XML, and load users from a CSV. Because we also build on LearnDash, we know where its data lives.
From SaaS platforms such as TalentLMS
Here the answer depends on what the vendor lets you take out. TalentLMS, for example, documents exports of account data to Excel or CSV files. Files you uploaded yourself, such as SCORM packages, videos and PDFs, can be loaded into Moodle if you still hold the originals.
Lessons written in a vendor's own editor often have no reusable export and are rebuilt. We check the export options and any API before quoting, and advise taking every export while the contract is still active.
Merging several Moodle sites
Courses move between Moodle sites as backups, with user data if required. The difficulty is identity. On restore, Moodle checks whether a user in the backup and a user on the target site are the same person, and reports a conflict when, for example, their email addresses differ.
So accounts are reconciled first, then roles and plugins are aligned, and only then are courses restored. Source sites should be on the same Moodle version as the target or an older one.
Moving a Moodle site between servers or hosts
A server move keeps the site identical and changes what is underneath. The documented method is to put the site into maintenance mode, dump the database, copy the moodledata directory (its cache, session and temp folders can be left behind), copy the code including installed plugins, and update config.php with the new URL, data path and database details. If the web address changes, Moodle's search and replace tool rewrites the old URL where it is stored in content.
We rehearse the move on the new server while the old one keeps running, test it under a temporary address, then repeat it for real and switch DNS. Moodle's documentation advises changing one thing at a time: moving server and upgrading version in the same step makes any fault hard to trace. If you also need someone to run the new environment, see managed Moodle hosting.
Changing the database engine
Moodle includes a database transfer tool for moving a site from one database type to another, for example from MySQL to PostgreSQL. It sits under Site administration > Development > Experimental > Database migration, and has a command-line version at admin/tool/dbtransfer/cli/migrate.php (inside the public folder from Moodle 5.1), which Moodle recommends for large sites because web timeouts can break a long transfer.
The tool works from Moodle's own schema definitions. It will not run if the database contains tables or columns that the schema does not describe, and it stops on wrongly encoded data. So a clean-up comes first: leftover tables, manual schema edits and bad character data are found and fixed on a copy before the real transfer.
This matters most for sites on Oracle. Oracle Database is no longer supported from Moodle 5.0, so those sites have to move to a supported engine before they can upgrade.
Upgrades are a separate project
Moving to a newer Moodle version on the same site is an upgrade, with its own rules about version paths, plugin compatibility and web server configuration. We keep it apart from a server or LMS move so that each change can be tested on its own. The scope is described under Moodle version upgrades.
What drives cost and timeline
Five things move the estimate: the number of courses that survive the inventory, the number of distinct source formats (each needs its own conversion), how much learner history you must keep, how many integrations have to be reconnected, and how tight the cutover window is.
Our Moodle migration services are estimated after discovery, when the inventory exists. A straight server move for a small site is typically days of work. A move from another LMS usually runs from several weeks to a few months, and most of that time is rehearsal and course-owner review, not data transfer. If Moodle is not yet a settled choice, our platform-neutral LMS migration service covers other targets.
Why All-in-One LMS for a migration
We build on Moodle, Canvas, Open edX and WordPress LMS plugins, so we usually know the source system's data model as well as the target's, which shortens the mapping phase.
Migration data is personal data, so we sign an NDA before you send an export, a database or a login. Every load is rehearsed on a staging copy and shown to you before the live cutover. The conversion scripts are reviewed by a second engineer, and they are handed over to you with the documentation, so a later intake of courses does not depend on us. This is one part of our wider Moodle engineering services.
Moodle migration services FAQ
How long does a Moodle migration take?
It depends on course count, source formats and how much history you keep. A server move for a small site is usually a matter of days including rehearsal. A move from another LMS takes longer, largely because course owners need time to review their content on staging. You get a timeline once discovery is complete.
Can user passwords be migrated?
Usually not. Systems store passwords as hashes in their own formats, and one system's hashes are rarely usable by another. The practical options are a generated password sent by email, a forced reset, or sign-in through your identity provider so that Moodle never holds a password at all. We agree the approach during planning so that users are told in advance.
Will learners keep their grades and completion records?
Final grades can be imported into Moodle's gradebook from CSV or XML, and completion records can be loaded by script where the source exports them. What generally does not come across is the evidence behind a grade, such as individual quiz attempts. If you need that for audit, we keep the old system's export as a read-only archive.
Can we migrate and upgrade Moodle at the same time?
We advise against it. Moodle's migration documentation makes the same point: if you change several things together and something breaks, you cannot tell which change caused it. The safer order is to move the site as it is, confirm it works, then upgrade on the new server with its own rehearsal.
How much downtime should we expect?
Enough for the final data run and the checks after it. The rehearsal on staging tells us how long that is for your data, so the window is a measured figure and not a guess. The old system remains available read-only until you release it.
Plan your move to Moodle
Tell us what you run today, roughly how many courses and users it holds, and when the old contract or server ends. An engineer replies within one business day with questions and an outline plan.