Moodle migration services and planning

What a Moodle migration involves

A Moodle migration usually starts from one of three situations: moving courses from another learning management system, moving from an older Moodle server or a hosting provider that no longer fits, or consolidating several Moodle sites into one. Each trigger carries a different risk. Moving from another LMS means mapping its course structure, roles and grade model onto Moodle's. Moving from an old Moodle server means carrying a version gap forward. Consolidation means reconciling duplicate accounts, course shortnames and category trees that were never designed to sit together.

What actually moves is more than course content. Course content, enrolments, users, grades, completion and activity history each need their own method. Course content is usually moved as Moodle backup files and restored, which keeps activities and settings together. Users and enrolments are imported with field mapping and must be matched to existing accounts, often by a stable identifier rather than by username. Grades and completion records depend on grade items, grade categories and activity completion settings existing in the target before data lands. Activity history, such as attempts and submissions, is the hardest to move cleanly and often needs a decision about what is retained as read-only evidence.

Two version checks come before any data moves. The target Moodle release sets the PHP and database requirements, so the hosting stack may need upgrading first. For example, Moodle 5.1 requires 64-bit PHP 8.2 or later and specific database versions, and the source site must already be on Moodle 4.2.3 or later to upgrade. The source version also determines the upgrade path, since older sites may need intermediate upgrades. Confirm both against the official release notes for your target version before scheduling anything.

The short answer on delivery is that a team with a Moodle administrator, a test environment and time to rehearse a cutover can do a simple single-site move in-house. A partner is usually worth considering when the source is an unsupported version, several sites are being merged, or the cutover has a fixed date and a tight data-verification requirement. Ask any partner for a written scope that lists the data types moved, the mapping decisions, the rehearsal count and the verification method.

What the work includes

A Moodle migration runs as a sequence of work packages, each with a defined input and a signed-off output. The list below is what a fixed-scope engagement would typically agree in writing, and the scope document should name each package explicitly.

Source inventory and data audit

We catalogue the source system, its version, plugins, custom code, course volume, user counts and attachment storage, then profile the data for duplicates, orphaned records and invalid characters. The audit output decides what migrates, what is archived and what is excluded, and it is the basis for the fixed scope and quote.

Target environment build

We build the new Moodle host in infrastructure you control, with the web server document root, PHP version, database engine and file storage set for the target release. Confirm the target version's PHP and database requirements against the vendor release notes before sizing servers, and confirm your backup retention and restore testing arrangements.

Data mapping for users and enrolments

We write a mapping specification that links source user identifiers, authentication methods, profile fields, cohorts, roles and enrolment methods to their Moodle equivalents. Decisions such as how duplicate accounts merge and which enrolment end dates carry over are agreed in writing before any script runs.

Data mapping for courses and categories

We map the source course hierarchy, category tree, course formats, section structure and activity types to Moodle categories and courses. Activities without a Moodle equivalent are listed with an agreed fallback, such as a resource or an archived export, so teachers know what changed.

Data mapping for grades and completions

We map grade items, grade categories, scales, letter bands and completion criteria, and record how historical grades and completion status will be stored. Grade history is the field most often disputed after cutover, so the mapping specification should state whether values are imported as final grades, overridden or kept as read-only records.

Test migrations and validation reports

We run repeated test migrations against copies of the source data and produce a validation report for each run, comparing record counts, grade totals, completion states and sample course content. Each report lists exceptions with a disposition, so you can see which differences were accepted, fixed or deferred.

Backup and restore runs

We test full backups of the source and target, including the database and the moodledata file store, and restore them to a clean environment. Restore timings and any failed restores are recorded, because the restore time sets the realistic length of the cutover window.

Cutover rehearsal and go-live

We rehearse the full cutover sequence, including source freeze, final export, import, DNS or load balancer change and communication steps, at least once against a production-like copy. Go-live follows the rehearsed runbook, and any step that overran the rehearsal is adjusted before the production attempt.

Rollback plan and post-cutover checks

We document the conditions under which cutover is reversed, the steps to restore the source, and the owner who makes that call. After go-live we run agreed checks on logins, enrolments, grade visibility, scheduled cron tasks and file links, and report the results before the engagement closes.

What drives effort and duration

This table lists the factors that change how much work a Moodle migration takes, why each one matters, and what you can do on your side to reduce it.

Driver	Why it changes effort	How to keep it down
Source type and export options	Moving from another LMS, an old Moodle server or a hosting provider uses different export formats. Some sources offer full backups, others only CSV or database extracts, which need more mapping and checking.	Confirm early which export formats your current platform provides and whether a full course backup is available. Ask for a sample export before the scope is agreed.
Number of courses	Each course must be restored, checked for structure and tested. Effort grows with the count and with how many courses have unusual layouts.	Archive or retire courses that no longer run. Agree a cut-off so only active and recent courses are migrated in the first wave.
Users and enrolments	User accounts, profile fields, cohorts and enrolments all need mapping. Duplicate accounts and inconsistent usernames add review time.	Clean up duplicate and inactive accounts in the source system. Decide which profile fields must carry over and which can be dropped.
Historical records in scope	Grades, completions and attempts for past terms add data volume and verification work. Each record type must be mapped and reconciled.	Agree in writing which terms and record types are in scope. Keep older history in an archive export if it is needed only for reference.
Grade schemes and custom gradebook setups	Custom scales, weighted categories and manual overrides do not always map one to one. Each unusual scheme needs a target equivalent and sample checks.	List the grade schemes in use and reduce them where possible. Ask for a gradebook report from the source so mappings are agreed before build.
Custom activity types and plugins	Activities or blocks from the source that have no Moodle equivalent need a replacement, a contributed plugin or custom code, each with its own effort.	Inventory third-party activities and decide which ones users still need. Retire unused ones before the migration starts.
Attachments and media volume	Large file stores, embedded video and linked external resources increase transfer time, storage sizing and link checking.	Remove obsolete files and broken links before export. Agree how external media will be handled and tested.
Number of source systems	Each source platform has its own data model, export method and quirks. Merging several sources multiplies mapping and deduplication work.	Consolidate sources into a single agreed data set where possible. Prioritize sources by the value of their content.
Integrations to re-point	Single sign-on, HR feeds, grade return and reporting tools that point at the old system must be rebuilt or redirected and tested before cutover.	List every connected system with its owner. Confirm which integrations are retired rather than moved.
Compliance and retention rules	Retention policies decide what history must be kept, in what form and for how long. They can require extra verification, audit trails or read-only archives.	Ask your records or compliance team to define retention requirements before scoping. Confirm the evidence they need for the migration.

Migration phases and outputs

The sequence moves courses, users, grades and completion history through discovery, repeated test runs and business sign-off before a single, rehearsed cutover.

Audit the source and inventory the data
We inspect the current LMS or Moodle server, its version, database, file store, plugins, custom code and integrations, then inventory courses, users, enrolments, grades, completion records and attachments. The output is a data inventory and a list of open questions for your team to answer before design starts.
Design the target and build the environment
We agree the target Moodle release, supported PHP and database versions, hosting layout and plugin set, then build the environment in your infrastructure. Output: a target design document and a working staging environment that matches the production design, with the web server document root configured for the /public directory if the target is Moodle 5.1 or later.
Write the data mapping specification
We map each source object to its Moodle equivalent, covering user fields, authentication identifiers, course categories, roles, grade items, grade scales and completion criteria. Your data owners sign the mapping specification, which lists every transformation rule and every field that will be dropped or approximated.
Script extraction, transformation and loading
We write repeatable scripts that extract source data, apply the mapping rules and load it into the target through Moodle backup and restore or controlled database and file operations. Each run produces a log of records processed, rejected and changed, so every outcome can be traced back to a rule.
Run test migrations and validate results
We run full test migrations into staging and reconcile counts, checksums and sampled records against the source for users, enrolments, courses, grades and completions. Output: test reports listing each discrepancy, its cause and the fix, repeated until the remaining exceptions are accepted in writing.
Review migrated courses and grades with users
Your instructors, administrators and a sample of learners review migrated courses, activities, gradebooks and completion status against the originals. Output: a signed-off acceptance list that records what was reviewed, who approved it and which known issues remain open.
Rehearse cutover, cut over and support hypercare
We rehearse the full cutover at least once on a production-like copy, timing each step and recording decisions in a cutover runbook with rollback criteria. After go-live, hypercare covers monitoring, defect triage and reconciliation of late changes, closing with a hypercare exit report. Ask for a phase-level timeline in the written scope.

What stays in-house and what goes to a partner

This table compares the Moodle migration work a client team usually keeps with the technical work teams often outsource, and names the skills each part requires so you can match tasks to people.

Part of the migration	Who usually owns it	Skills required	What to confirm before you decide
Course, grade and completion rules	Client business owners and academic leads	Knowledge of assessment policy, grade scales, passing rules and how completion must be recorded for certification or reporting	Which rules must carry over unchanged and which may be retired during the move
Content validation	Subject leads and course authors	Subject knowledge, familiarity with the source LMS activities and quizzes, and the ability to spot broken links, media or question banks	Sign-off dates and who can approve a course as ready
Source data ownership	Registrar, HR or student records owners	Data privacy handling, understanding of which person and enrolment fields are authoritative, and retention rules for historical records	Which system is the master for identities, enrolments and grades
Source extraction	Partner or internal database engineer	Database and SQL work against the source system, export of course backups or API data, and handling of personal data in transit	Access to the source database or export tools, and whether the old host can be read during the window
Transformation scripting	Partner or internal developer	SQL and scripting, mapping of source IDs to Moodle entities, handling of user, cohort and grade history, and repeatable runs	Field mapping sign-off and how unmappable records will be reported
Moodle restore tooling and validation	Partner with Moodle administrator support	Moodle backup and restore knowledge, course import behavior, role and enrolment checks, and comparison of grade totals against source	Moodle version and database platform that the target must run, as set by the current Moodle release requirements
Rehearsal and cutover runbook	Partner with client platform team and business sign-off	Runbook writing, rollback planning, DNS and certificate change control, and coordination with support and communications	Number of rehearsals, freeze windows and who holds go or no-go authority
Ongoing administration after go-live	Client Moodle administrator	Moodle site administration, plugin and cron operation, user support and routine maintenance of the new environment	Whether the administrator is hired or reassigned before the rehearsal starts

What usually goes wrong

Most Moodle migration problems are not technical crashes. They are quiet data losses and mismatches that surface weeks after cutover, so each risk below has a prevention step to build into the plan.

Grades without their structure

Grade values can arrive without the grade items, categories, weights and calculated formulas that produced them, so totals silently change. Reconcile grade items and final course totals per course and per user against the source export before any learner or teacher sees the new gradebook.

Completion history reset

If activity completion and course completion criteria are not mapped to their Moodle equivalents, learners can appear incomplete and certificates or compliance records may be reissued or lost. Map every criterion in the source system, then check completion status per user on a sample of courses with the criteria still enabled.

Duplicate user accounts

When the identifier used to match users differs between systems, such as a student number in one and an email address in the other, the import creates second accounts and splits enrolments and grades. Agree the matching key before import, run a dry-run match report, and resolve every unmatched or duplicate record before the final load.

Broken activity links and files

Course restores can leave internal links, embedded media and file references pointing at old course IDs or missing content, which breaks lessons after go-live. Test a restore of several representative courses, follow every link type through the browser, and confirm file counts per course against the source backup.

Missing attachments

Assignment submissions, forum attachments and uploaded resources can be skipped when a backup excludes user data or when file storage paths differ between servers. Compare file inventories per course and per activity type, and confirm that the moodledata directory and file records were both carried over.

Time zone and date shifts

Deadlines, availability windows and gradebook timestamps can move by hours when source and target servers use different default time zones or when dates are converted without the user's zone. Set the site and user time zones before import, then spot-check due dates and release times for courses that open at midnight.

Unsupported source plugins

Plugins or third-party LMS features used in the source may have no equivalent in the target, or may not be installed or compatible with the target Moodle version. Inventory every activity type, block and enrolment method in use, then decide per item whether to replace it, rebuild it or retire it before the content is imported.

Cutover without a rollback

A final import that cannot be reversed leaves no safe path back if reconciliation fails on cutover day. Freeze the source after a defined last-change point, rehearse the full import on a copy, and prove a restore of the target database and moodledata before the production load starts.

How the work changes by starting point

Moving from another commercial or open-source LMS is usually a data mapping project first and a Moodle project second. There is rarely a database to copy across, so the work depends on what the source system can export and how faithfully that export represents courses, users, grades and completions.

Export quality: Confirm which objects the source can export (courses, activities, question banks, enrolments, grade items, completion records) and in what format. Gaps here set the scope.
Intermediate data model: Map source fields to Moodle objects in a spreadsheet or staging database before any import runs. Decisions about grade scales and completion rules are made here.
Content conversion: Packaged course formats often need conversion to Moodle activities. Budget for manual rebuilding of interactive content that does not convert cleanly.
History limits: Historic attempts, forum posts and audit trails frequently cannot be carried over in full. Agree with stakeholders which records are kept and which are archived elsewhere.
Verification: Compare record counts and sample grade calculations between source and target for each course category.

What you need to provide

Before we can scope a Moodle migration, the source side has to be readable. Provide read access to the source LMS or old Moodle server, or full exports of it, including the database and the file storage where course files, user uploads and backups live. If the source is a hosted service that only allows exports, tell us which export formats it offers and whether they include grades, completion records and activity attempts, not only course shells.

Provide a current inventory of courses, categories, enrolment methods, installed plugins and themes, and any custom code or reports. Include plugin versions where you know them. This list drives the compatibility check against your target Moodle release, and it tells us which activities need mapping and which can be retired. Also name the owners for course content and for grade policy, since they will answer questions about weighting, rounding, late penalties and retakes that the data alone cannot settle.

Confirm the data retention and privacy rules early. Historical grades and personal data may carry different retention periods, and some records may need to be excluded, anonymized or kept in the source system only. Ask your data protection or records team to state these rules in writing so the mapping can apply them. Your target hosting environment must also meet the PHP and database versions required by the chosen release. For example, 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, and the release notes list other requirements to confirm.

Provide a test environment that matches production in PHP and database versions, web server configuration and approximate data volume. Testing against a smaller or different setup gives false confidence in the restore and cutover steps. Finally, decide the cutover window and the freeze on source edits. Agree who can still change courses or grades during the freeze and how late changes will be captured. The client keeps final sign-off on migrated data. We prepare reconciliation reports and sample checks, but your named owners approve the result before the source is retired.

Common questions about Moodle migration

Can our own team migrate courses to Moodle without an outside partner?

Yes, many teams can, if they have people who know Moodle administration, the database and the web server, and enough time to test. The core work is backup and restore, data mapping and verification. It usually fails in the details: user matching, course categories, file references and grade items. A partner adds the most value when the source system is unusual, the volume is large or the cutover window is tight. Before deciding, ask whether your team has already completed a full restore test of a course with grades, quizzes and files.

What drives the cost and timeline of a Moodle migration project?

Scope and data condition drive most of the effort. The number of courses, users, enrolments, grade items and stored files matters, and so does how messy the source data is, including duplicate accounts and orphaned files. Integrations with SSO, HR or student information systems, and custom plugins on the old site, add work. The target release and database also change the build. Quotes come from a written scope, so ask the partner to list every assumption about volume, sources and integrations.

How does our current Moodle version change the migration path?

The source version sets how many steps the path needs. Each Moodle release has an upgrade rule. For example, Moodle 5.1 requires sites to be on 4.2.3 or later, and Moodle 5.3 requires 4.4 or later. An older source may need intermediate upgrades on a copy before its data moves, and each step needs supported PHP and database versions. A source on a different platform adds more work, because its data must be exported and mapped into Moodle. Confirm your exact version and plugin list first.

Can grades and course completions be preserved after moving to Moodle?

Often yes, but it depends on what the source exports and how the data maps. Grades need grade items, grade history and user identifiers to line up with the new site. Completion records depend on the activity completion settings being present in the source and restored correctly. Some history, such as detailed logs or third-party data, may not map cleanly and needs an explicit decision. Ask the partner to show how grades and completions are checked against the source for a sample of courses during a rehearsal.

Do we need a rehearsal before the production cutover?

Yes, a rehearsal is the standard way to find problems before real users do. It runs the full migration on a copy of production data, times each stage, and checks grades, enrolments, files and logins. Most cutover problems surface here rather than on the day of the switch, so the rehearsal is a planned step, not an optional one. The number of rehearsals depends on how many issues the first run finds and how complex the data is. Ask for the rehearsal plan and exit criteria in the written scope.

What happens after cutover, and can migrated courses be restored later?

After cutover, the team monitors the site, fixes data issues and hands over operations. Yes, migrated courses can be restored later if backups were taken at each stage. A Moodle course backup file restores into a site running a compatible version, and the target site needs its own database and moodledata backups taken before cutover. Your rollback plan should name which backup restores to which version. Confirm retention periods, who can run a restore, and whether support after go-live is part of the scope.

How DeployOpen delivers Moodle migrations

DeployOpen plans, builds, tests and hands over Moodle migrations inside infrastructure you control, with a written scope agreed before work starts. Each step produces documented evidence you can review before cutover.

How we scope

The written scope lists which courses, categories, users, grades and completion records move, and which are left behind.
Data mapping defines how source roles, enrolments, grade items and completion rules translate into the target Moodle site.
The scope names the source systems, export formats, target Moodle version and database engine so the cutover plan has fixed inputs.

How we build

We build the target Moodle environment, then run backup and restore or scripted imports into a staging copy of the site.
Migration scripts and mapping rules are tested on sample courses first, with reconciliation reports comparing counts and grades to the source.
Test rounds are repeated with your reviewers until the agreed reconciliation checks pass, and each round is recorded.

How we hand over

The cutover runbook covers the freeze window, final data delta, DNS or routing changes, validation steps and the rollback decision point.
You receive the mapping specification, scripts, reconciliation results, configuration records and an operations guide for your administrators.
A handover session walks your team through the cutover evidence and the open items that remain after go-live.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the migration is complete.
Post-cutover support can cover issue triage, data corrections and checks of the first term or cohort on the new site.
Confirm with us in the written scope how long post-cutover support is included and which items would be billed separately.