Bulk user import into Moodle: what the move involves and how long it takes
Moving users, courses and enrolments into a new Moodle is mostly data mapping, validation and a rehearsed load, and the effort depends on two things: how clean the source data is and whether the load happens once or repeats. Teams that hold people and course records in a student information system, spreadsheets or a directory often find that the hard work sits before any upload. Someone has to decide which source field becomes which Moodle field, which identifier serves as the unique username, and how a learner who appears in two sources is recorded. The upload itself is usually the smallest step.
For a one-time move, the core Upload users and Upload courses tools in Moodle accept CSV files, and most organizations start there. Plan one CSV per object type, map each column to a Moodle field, and confirm the accepted columns and options against the documentation for the Moodle version you deploy. Decide the authentication method for each account in advance. Manual accounts, LDAP accounts and external database accounts behave differently later, when a person changes department, leaves or needs to be suspended, so the choice affects operations as well as the first load.
Where the source of truth keeps changing, a single CSV load goes stale quickly. External database and LDAP methods suit that situation better. Moodle core ships authentication plugins for both, and the enrolment side of a recurring sync needs its own check against your target version, because enrolment plugin availability and settings should be confirmed rather than assumed. A recurring sync also raises decisions the one-time load never reaches: which system owns the username, how leavers are suspended and retained, and what the site does when the source sends an empty or malformed file. Those decisions shape the design more than the upload does.
Before any production load, rehearse it on a copy of the target site using a representative extract. Include the awkward cases: duplicate names, missing email addresses, accounts that already exist, and courses with overlapping short names. Record the count of created, updated and failed rows for each file, then sample-check enrolments in several courses by role. Write down the rollback steps, such as how a bad batch is identified and suspended, and agree them with the data owner before the rehearsal begins, so the production run follows a path that has already been tested.
When you request a quote, ask for the scope in writing. It should name the source systems and their export formats, the approximate number of user records and courses, the field mapping workbook, the number of rehearsal loads, whether a recurring sync is included, and who signs off the data at each stage. Ask the same questions of any internal estimate. No effort figure appears in this section because the effort depends on that written scope, and the scope is agreed before work starts.
Which source data maps cleanly into Moodle and which needs design
This table compares common source records with their Moodle equivalents and marks where the mapping is direct and where someone must make a decision before the load. Read the rows with a decision flag first, because those choices set usernames, category structure and course identity for the life of the site. Historical grades and activity content are listed last because a user or course CSV load does not carry them.
| Source record | Moodle equivalent | Mapping status |
|---|---|---|
| User identifier (staff or student number) | User ID number field (idnumber), not the username | Direct to idnumber, but keep it separate from the login name |
| Login identifier used for sign-in | Username (must be unique, lowercase, no spaces by default) | Decision needed: choose the unique, stable field and agree how duplicates and renames are handled |
| First name, last name | firstname and lastname user fields | Direct, but confirm the source casing and special characters |
| Email address | Email field, used for notifications and password reset | Direct, but a shared or missing address blocks password reset for that account |
| Organizational unit or department | Course category, or a user profile field used for filtering | Decision needed: whether categories mirror departments one for one or only group courses |
| Cohort or class | Cohort (site-wide) or group within a course | Decision needed: cohorts for bulk enrolment across courses, groups for work inside one course |
| Course shell (code, title, dates) | Course fullname, shortname, idnumber, category and start and end dates | Direct for fields, decision needed for the shortname format and its uniqueness rule |
| Course shortname | Unique text identifier shown in lists and used in upload files | Decision needed: define the pattern (for example, term plus code plus section) and test collisions before the load |
| Teacher enrolment | Enrolment with a teacher role in the course, from the upload courses or enrolment file | Direct when the teacher's username matches an existing account |
| Student enrolment | Enrolment with the student role, with optional start and end dates | Direct, but confirm how withdrawals and expired enrolments will be handled |
| Groups and groupings | Groups and groupings inside each course | Decision needed: whether groups are created by the import or added afterwards |
| Historical grades | Gradebook records, not part of a user or course CSV load | Separate handling: decide whether to migrate, archive as reports or start fresh, and plan a separate load |
| Activity content (quizzes, files, pages, forum posts) | Activity modules and their stored files, not created by user or course uploads | Separate handling: use backup and restore, a content package or a rebuild, as covered in the migration pages |
Documented import paths in Moodle core for users, courses and enrolments
Moodle core provides CSV upload tools for accounts and courses, plus authentication and enrolment plugins that can feed the same data from a file, a directory or a database. The cards cover what each path accepts, where it fits in the build and what to confirm against your Moodle release. Settle one identity source first, because the account record and the enrolment list usually come from the same place.
Upload users tool
The core upload users tool reads a CSV file and creates or updates user accounts in one pass. Each row maps to an account, and the column headers determine which profile fields are set, including the identifiers that later sign-in and enrolment depend on. Check the accepted columns, custom profile field handling, password options and update behavior for your release before you write the file template. Run the tool on a staging copy first, because a mistaken identifier can create duplicate accounts that are hard to merge later.
Upload courses tool
The upload courses tool creates course shells from a CSV file, using fields such as short name, full name, category and dates. It creates the containers that enrolments attach to, so category structure and naming conventions should be settled before the file is written. Confirm the accepted fields, whether existing courses can be updated, and how the tool handles templates and visibility in your version. This tool does not load activities or resources, so plan content transfer as separate work.
Manual authentication accounts
Manual accounts are stored in the Moodle database and are the default authentication method. Accounts created by the upload users tool land here unless the row specifies another authentication plugin. This path suits a one-time load or a small population without a central directory. Decide early how passwords are issued, how first sign-in forces a reset, and who deactivates accounts when people leave, because manual accounts will drift from HR records unless someone maintains them.
External database and LDAP plugins
The external database and LDAP authentication plugins check sign-in against a table or directory you already run. Depending on the plugin settings, they can create accounts from that source on first login or during a scheduled sync. Field mapping determines which source attributes populate the Moodle profile. Confirm the sync options, schedule behavior and mappable attributes for your version, and test how a user removed from the source is handled before go-live.
OAuth 2, Shibboleth and web services
OAuth 2 and Shibboleth authenticate people through an external identity provider, so accounts are usually created on first sign-in. Web services expose Moodle functions to external systems, which lets middleware or an HR export call Moodle directly to create users and enrolments. Each choice moves the trust boundary and the failure modes. Confirm which functions and token settings your version exposes, which attributes the provider sends, and whether accounts created this way match those from the upload tool.
Enrolment methods for the build
Enrolments attach users to courses through enrolment methods. A typical build combines manual enrolment for exceptions, cohort sync for group-based populations and self-enrolment where open access is allowed, with external database or LDAP enrolment for recurring feeds. Enrolment plugin availability and options vary by version and by what is enabled on your site, so confirm the list against your deployment. Use one identity source to drive both account creation and enrolment, so a person removed from that source also loses course access.
One-time CSV load or recurring sync: choosing the load path for Moodle users
The first decision in a bulk import is not the file format. It is whether Moodle should receive users and enrolments once, as a snapshot, or keep receiving them from a source system that continues to change. A one-time CSV load with the core upload users and upload courses tools works well when the source of truth is a spreadsheet, an export from a legacy system, or a student information extract that will be retired soon. A recurring sync through the external database or LDAP authentication and enrolment plugins fits when another system, such as an HR platform, a student records database or a directory, already owns the people and their enrolments and changes them every term or every week.
Start by naming who owns the source record for each person and each enrolment. If the registrar or HR team edits the authoritative record, a CSV that someone exports by hand will drift from it within weeks, and Moodle will hold accounts that no longer match. If the Moodle team is the only place where course enrolments are managed, a one-time load may be enough and the operational burden stays small. Write down the owner, the system of record, and the person who will answer when the two disagree. That answer decides more of the design than the import tool does.
Next, estimate how often enrolments change during a term. Add-and-drop periods, late registrations, section moves and instructor reassignments create changes that a one-time file cannot follow unless someone repeats the load. Ask the business owners how many change events they expect per term and who will run each reload. Leavers and transfers need the same scrutiny. A CSV load can suspend or remove enrolments only if the file says so, so a missing row does not reliably mean a removal. A sync can be configured to unenrol users when the source no longer lists them, but that setting must be tested against a real leaver before it is trusted, because a broken source extract could remove many enrolments at once.
Plan for what happens to accounts created by a load when the source changes. Accounts created by the upload tool and accounts created by an external authentication plugin behave differently when a field changes, a username is reused or a person leaves, and the settings that govern updates should be checked in a test instance before go-live. Confirm with your Moodle version and plugin configuration which fields can be overwritten by the source and which are protected for local edits. A hybrid is common: a one-time load brings in legacy course history and past enrolments, while a sync handles live enrolment for current terms. Keep the two sources from claiming the same accounts without an agreed rule.
Finally, keep single sign-on as a separate decision. How an account is created, whether by CSV, external database, LDAP or manual entry, does not determine how the person signs in. SAML 2.0 single sign-on, commonly provided in Moodle by the SAML2 Single sign on plugin (auth_saml2) maintained by Catalyst IT, maps attributes from the identity provider to fields in Moodle. Confirm which identifier the identity provider sends, which Moodle field it must match, and whether that plugin version supports your Moodle release before choosing the account creation path, because the two choices must agree on usernames and identifiers.
The sequence for a Moodle course import CSV with a rehearsal and parallel run
This sequence moves users, courses and enrolments from a source system into a self-hosted Moodle in controlled stages, so each load is proven against the source before anyone depends on it. The output is a cutover that the owners of the data have signed off on, with the old load files and access removed.
Inventory source data and its owners
List every source extract that feeds users, courses, categories and enrolments, and name the owner of each one, such as the HR system team, the registrar or the course owners. Record the field definitions, update frequency and the person who can answer questions about a blank or unexpected value. The step is done when each extract has a named owner and a written field list that the owner has confirmed. Exit check: no field in the target import is left without a source owner.
Map fields and write validation rules
Map each source column to the Moodle user profile, course and enrolment fields the upload tools accept, and decide how identifiers such as usernames and course short names will be built and kept unique. Write validation rules for required values, duplicate detection, date formats and role names, and agree on what happens to rows that fail. Run the rules against a sample extract and record the rejected rows with their reasons. Exit check: the mapping document and rule set are approved by the data owners and the sample run produces a reviewed rejection list.
Rehearse the load in non-production Moodle
Build a non-production Moodle with the same major version, database engine and authentication settings planned for production, then load the full CSV set with the core upload users and upload courses tools. Keep the load files and the exact order of runs under version control so each rehearsal can be repeated. Capture every error, warning and manual correction and feed those back into the mapping and rules. Exit check: a complete rehearsal load finishes with no unexplained errors, and the team can repeat it from the same files.
Reconcile counts and enrolments to source
Compare record counts for users, courses, categories and enrolments between the source extract and the rehearsal Moodle, then sample individual records to check profile fields, course membership and roles. Explain every difference, whether it comes from a rejected row, a deliberate exclusion or a defect. Hand the reconciliation to the data owners for sign-off. Exit check: every count difference is explained and the data owners have accepted the reconciliation report in writing.
Run the parallel period
Run the old and new systems side by side for an agreed period, with the same users and enrolments visible in both, and have a representative group of users and course owners sign in and check their courses and roles in the new Moodle. Log every discrepancy and decide, with the data owners, whether it is fixed in the load files or accepted. Continue regular source extracts into the new Moodle as the source changes during this period. Exit check: no open discrepancy affects access, grades or enrolments, and the representative users confirm their access in writing.
Cut over on a set date
Agree a cutover date with the business owners and the platform team, freeze changes in the source system for the final extract, run the production load, and repeat the reconciliation against that final extract. Announce the switch to users and point their links and single sign-on at the new Moodle only after the reconciliation passes. Keep the rollback decision and its owner documented before the date arrives. Exit check: the post-load reconciliation passes and the sign-off record names who approved the switch.
Decommission load files and access
Once the new Moodle has run in production for the period the owners agreed, remove the old load files from shared locations, revoke the service accounts and credentials used for imports, and close the old system's write access. Archive the approved mapping, rules, reconciliation reports and run logs in a location the auditors and the owners can reach. Retire the old system only when its owner confirms that the data is no longer needed for operations. Exit check: the access revocation and archive are recorded and the old load files are no longer on any shared path.
What drives the cost and duration of a Moodle user and course load
This table lists the factors that change how much work a Moodle user and course load takes, who typically pays for each part, and whether the cost is one-time or recurring. Use it to shape your scope request and to compare quotes on the same basis. The main takeaway is that source data quality and the choice between a one-time CSV load and a recurring sync usually matter more than the raw record count.
| Driver | Who pays | One-time or recurring | What to ask for in a quote |
|---|---|---|---|
| Number and quality of source systems | Both: internal staff extract data, DeployOpen maps and transforms it | One-time for the initial load, recurring if feeds continue | Named source list, export formats, and who owns each extract |
| Identifier consistency across sources | Both: internal staff resolve duplicates, DeployOpen designs matching rules | One-time, but it reappears with every new feed | Matching key choice, duplicate handling rules, and a sample reconciliation |
| Number of courses and enrolment rules | DeployOpen for import templates, internal staff for approving rules | One-time for the build, recurring when rules change | Course template count, enrolment logic per role, and category structure |
| Custom validation scripts | DeployOpen, sometimes with internal review | One-time build, with maintenance if source rules change | Validation checks listed one by one and the reject and log behavior |
| Authentication and SSO integration | Both: internal identity team configures the identity provider, DeployOpen configures Moodle auth | One-time setup, recurring identity administration | Auth plugin chosen (for example LDAP, external database or SAML 2.0 through a plugin), and which fields are mapped |
| One-time load or recurring sync | DeployOpen builds the job, internal staff own the source feed | A recurring sync adds ongoing operations and monitoring | Run frequency, deletion and suspension rules, and the support model after go-live |
| Reconciliation rigour | Both: internal staff sign off counts, DeployOpen produces the reports | One-time per load, repeated for each sync cycle | Reconciliation report contents, sign-off steps, and the tolerance for mismatches |
| Number of rehearsal rounds | Both: DeployOpen runs test loads, internal staff test with real data | One-time, scales with each rehearsal | How many rehearsals are included, what each one tests, and the cutover criteria |
What usually goes wrong in a Moodle user import and how to prevent it
Most failed imports trace back to a small set of data problems that surface after the live run. The six risks below share one cause: source files are trusted without being checked against what Moodle already holds. Each card names a prevention step and the rehearsal or reconciliation check that catches the problem.
Duplicate accounts from inconsistent identifiers
Moodle matches an uploaded user to an existing account by username, so one person can end up with two accounts when the source system uses a different username format, a changed email address or mixed capitalization. Before the rehearsal, export the current user table and the source extract, normalize usernames and emails in both, and count matches on email and employee ID. During reconciliation, list every account the import created that shares an email address with a pre-existing account, and resolve each one before the live run.
Enrolments that do not match the current term
Enrolment files often carry last term's course codes or learners who have already left, so people land in courses that have ended and miss courses that have started. Build the enrolment file from the term calendar your registrar publishes, and set course start and end dates before any enrolment is loaded. In the rehearsal, compare enrolled counts per course with the source roster and confirm that completed terms stay closed to new enrolments.
Orphaned accounts after a sync stops
When a scheduled sync through an external database or LDAP enrolment stops, accounts for leavers stay active and enrolments continue to look current. Monitor the time of the last successful sync run, alert on failed runs, and decide in advance whether a stalled feed suspends accounts or leaves them unchanged. During reconciliation, compare active Moodle accounts with the source directory and suspend any account the source no longer holds.
Passwords and authentication methods set incorrectly
A user file that assigns the wrong authentication method can lock people out or leave password logins open after the institution has retired them. Confirm the authentication method for each population before loading, such as manual accounts for a pilot group and an SSO or LDAP method for staff. Keep passwords out of load files, and in the rehearsal, sign in with one test account per authentication method and check the password-change settings.
Course shells with inconsistent shortnames
Course shortnames are the keys that enrolment files use to find courses, so a shortname that differs by a suffix, a space or a changed term code creates a duplicate course or an enrolment that fails to match. Agree a shortname pattern with the registrar, such as department, course code and term, and generate it from the same source fields in both the course file and the enrolment file. In reconciliation, confirm that every shortname in the enrolment file matches exactly one course.
Load files copied to unsecured locations
Import files contain names, email addresses and sometimes student numbers, and they often end up in shared drives, email attachments or a laptop's downloads folder. Store the files in a location limited to the people running the import, delete working copies after each run, and record who holds each file. Confirm the retention period for source extracts with your data protection lead, and log the deletion in the reconciliation record so the controls can be checked later.
Which Moodle version to load into and what the server must support
The target Moodle version sets the server baseline before any user or course file is touched, so settle it first. For Moodle 5.1, the server needs 64-bit PHP 8.2 or later (8.3 and 8.4 are supported), and one of PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or Microsoft SQL Server 2017 or later. The web server document root must point to the new /public directory rather than the main Moodle folder, since otherwise the site may show directory listings or errors. Sites on older releases must be on Moodle 4.2.3 or later to upgrade to 5.1.
For Moodle 5.3, the baseline moves up: 64-bit PHP 8.3 or later (8.4 is supported), PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Upgrades to 5.3 require an existing site on Moodle 4.4 or later. Confirm these minimums against the release notes for the exact patch level you plan to install, and check your database and PHP build against them before the import project is scheduled, because a server that misses the baseline blocks the upload tools entirely.
Version choice also decides how long the site receives fixes. Moodle 5.1 has general support until 5 October 2026 and security support until 19 April 2027. Moodle 5.2 has security support until 4 October 2027. Moodle 5.3 is the next LTS release, with general support until 4 October 2027 and security support until 1 October 2029, according to the Moodle releases page. Ask your programme owner how long the site must stay on a supported branch, then map that window against the planned go-live and your next upgrade, since a bulk import into a version that leaves security support early creates a second migration soon after launch.
Version choice also affects the theme. Moodle 5.3 removes the Classic theme from core. If your course pages, custom theme or reports assume Classic, plan the theme work before loading courses, because imported courses will be displayed through whichever theme is active. Check the theme and any custom plugins against the target release in a staging copy, and record the exact version and server stack in the import runbook so the import can be rehearsed on the same baseline as production.
Before choosing, ask your hosting or platform team to confirm the database engine version, PHP version, web server document root configuration and the upgrade path from your current Moodle release. Those four answers decide whether the target version is installable on your infrastructure in the time available. If any answer is unknown, treat the version decision as open and do not start the CSV work until it is closed.
Questions teams ask before bringing in help with a Moodle user and course import
What makes a Moodle user and course import cost more or take longer?
The biggest drivers are the quality of the source data, the number of systems feeding Moodle, and whether the import is a one-time load or an ongoing sync. Source files with duplicate accounts, inconsistent department codes, missing email addresses or course codes that do not match across systems take longer to map and clean. Each additional source system adds mapping rules, reconciliation checks and a new owner to coordinate with. A recurring sync through external database or LDAP enrolment also needs authentication, scheduling, error handling and monitoring, which a one-time CSV load does not. Single sign-on adds identity mapping work, since matched usernames and fields must agree between the identity provider and Moodle. A quote should itemize each of these so you can see which one moves the total.
How long does a Moodle import project usually take?
Duration depends on the written scope, the number of rehearsal rounds agreed, and how quickly the client returns clean extracts and decisions. There is no standard timeline that applies to every organization, so treat any figure you hear without a scope as an estimate, not a commitment. A typical sequence covers discovery of source data, agreement on mapping rules, a test import into a non-production Moodle, reconciliation of results against the source, and then a final load with a cutover plan. Each rehearsal round reveals data issues that need fixing at the source, which is often where most elapsed time goes. Ask the partner to show the phases, the number of rehearsal cycles included, and what the client must deliver before each phase starts.
What does our team need to provide for a Moodle import?
Expect to name data owners who can answer questions about each source system and approve changes to the data. You will also need access to source extracts, ideally in the same format and with the same filters the production load will use, and a test environment running the same Moodle version as production. Sign-off on the mapping rules is essential: decisions such as how a department maps to a cohort, how a course shortname is built, or which enrolment role a feed assigns should be agreed in writing before the first test import. Someone must also be available to review reconciliation reports and confirm which exceptions are acceptable. Gaps in any of these areas typically extend the schedule rather than reduce the work.
Can our in-house team run a Moodle import without outside help?
Yes, an in-house team can do this if it has solid Moodle administration skills and enough time for rehearsal and reconciliation. The core upload users and upload courses tools handle CSV loads, and the external database and LDAP enrolment methods are documented in Moodle's core authentication and enrolment plugins. The skills that are most often underestimated are data cleaning, writing mapping logic that survives edge cases, and checking results against the source after each run. Ask whether your team has done a test load into a copy of production, whether someone can own the sync schedule after go-live, and who will fix errors during term start. If those answers are unclear, a fixed-scope engagement can cover the parts you do not want to staff.
How does DeployOpen price a Moodle import engagement?
DeployOpen does not publish a price list. Most engagements are fixed-scope, so a quote follows from a written scope that lists the source systems, the import method, the number of rehearsal rounds, the reconciliation expected, and the deliverables. Ask for the quote to separate discovery, mapping and scripting, test loads, final load and any ongoing sync or support. Each line should say who does the work and what the client must supply. If the scope changes after signing, the change should be written and priced before work continues.
Which Moodle version should we target before importing data?
Choose the version during planning, because the import mapping and test environment must match it. Moodle 5.1 requires 64-bit PHP 8.2 or later with PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or Microsoft SQL Server 2017 or later, and it changes the web server document root to the new /public directory. Moodle 4.5 is a long-term support release with security support until 4 October 2027. Moodle 5.3 is the next long-term support release, with general support until 4 October 2027 and security support until 1 October 2029. Confirm your database, PHP and web server choices against the release notes for the version you select before the test environment is built.
Does a Moodle sync with LDAP or an external database replace the CSV upload?
Not always. A one-time CSV load suits a single migration from a fixed extract, while LDAP or external database enrolment suits a source that changes often and must keep Moodle current. The sync approach needs a stable identifier for each user, agreed field mapping, a schedule, error handling for records that fail, and a plan for who responds when the source changes. Core Moodle ships external database and LDAP authentication, and external database enrolment is available as well, so the choice is about your data flow rather than missing features. Ask the partner to explain which method fits each source and what happens to accounts that disappear from the feed.
What should we check after a Moodle import finishes?
Check counts first: the number of created, updated and suspended users, enrolments by role, and courses created against the source totals. Then sample records across departments and course types to confirm names, emails, cohort membership and enrolment dates are correct. Verify that users can sign in through the method you chose, including single sign-on if it is in use, and that teachers see the courses and roles they expect. Keep the reconciliation report and the mapping rules with the project record so the next load can be compared with this one. Agree in advance which exceptions are acceptable and who signs off on the final result.
How DeployOpen scopes, rehearses and supports a Moodle user and course load
DeployOpen plans bulk user and course loads as a designed project inside infrastructure you control, with the CSV formats, enrolment rules and validation runs agreed in writing before any production data moves. Engagements are fixed-scope, and the load is rehearsed on a non-production Moodle copy before the live import.
How we scope
- Written scope lists the source extracts, CSV templates and course categories the import covers in your Moodle.
- We agree which user fields, enrolment roles and course templates are loaded, and which are created by hand afterward.
- The scope states whether a one-time upload or a recurring external database or LDAP sync fits your environment.
How we build
- We prepare upload users and upload courses CSV files with validated columns, mapped roles and unique identifiers.
- Each load is rehearsed on a non-production copy, with row-level error reports reviewed before production runs.
- Where a recurring sync is in scope, we configure the external database or LDAP enrolment settings and test them against sample records.
How we hand over
- You receive the final CSV templates, column definitions and the import runbook used for each load.
- Documentation covers error handling, rollback steps and the order in which users, courses and enrolments are loaded.
- Your team gets a reconciliation checklist to confirm user counts, course counts and enrolments after each run.
How we support
- Ongoing support, upgrades and testing are available as retainers for sites that load data regularly.
- Support can cover re-running loads after source changes and reviewing sync logs when enrolments drift.
- Confirm with us, in the written scope, how upgrades to a newer Moodle release affect your import tools and sync settings.
