Most colleges and universities that run Moodle have a provisioning script somewhere. It might be a PHP job calling Moodle web services, a SQL view on the SIS that feeds the external database enrolment plugin, or a CSV export dropped in a folder every night. It reads sections and enrollments from Omnivox, Clara, Banner or PeopleSoft and turns them into Moodle courses and enrollments.
The question of whether to keep it rarely comes up on a quiet day. It comes up when a Moodle upgrade breaks it, when the person who wrote it leaves, or during add/drop week when the helpdesk fills with "I can't see my course" tickets. This comparison puts both options side by side so you can decide with the real costs in view.
What does a Moodle enrollment script actually have to do?
"Sync enrollments" sounds like one job. Any script that runs a real term does at least five, and each one fails in its own way.
| Job | What it involves in Moodle | Where homegrown scripts usually stop |
|---|---|---|
| Course creation | Full name, short name, course ID number, category, template, visibility | Works until naming or category rules change |
| Initial enrollment | Users matched by ID number; student, teacher and non-editing teacher roles | Works if every user account already exists |
| Add/drop changes | Adds, drops, section swaps and instructor changes in the first weeks | Adds but never removes, or removes too aggressively |
| Multi-section and cross-listed courses | Meta-courses built with the course meta link plugin, one group per section | Done by hand, on request |
| End of term | Hiding courses, moving them to an archive category, closing access | Forgotten until the next term is cluttered |
The first two rows are what most scripts were written for. The last three are where the hours go.
Why do scripts get harder to maintain every term?
A script freezes the assumptions of the day it was written. The institution keeps moving.
- The SIS changes. A new export format, a new term code scheme, a new status for waitlisted students or a full SIS migration means rewriting the extraction side.
- Moodle changes. Each major upgrade, for example from 3.9 LTS to 4.1 LTS and beyond, can shift web service behavior, plugin settings or PHP requirements. Fragile scripts are one reason institutions postpone upgrades.
- Edge cases pile up. Canceled sections, an instructor assigned the week before classes, auditing students, a teacher who wants three sections merged: each one becomes a special case in code or a manual fix.
- Knowledge concentrates. The logic lives in one person's head and a few hundred lines with little documentation. When that person is on vacation in late August, nobody wants to touch the cron job.
- Failures are silent. A run that skips 30 enrollments doesn't page anyone. Students and teachers find out, usually in week one.
What does a custom script really cost?
The visible cost is small: a server, a cron entry, a few days to write the first version. The real cost is spread over every term that follows.
Based on LS2's deployments, the time IT teams spend keeping custom scripts running typically lands around 40 to 80 hours per term. That counts maintenance after SIS or Moodle changes, failed runs, manual corrections during add/drop and multi-section courses merged by hand. It is an estimate, and your number may be lower if your scope is small. Ask the people involved how long the last start of term really took, evenings included.
Other costs never show up on IT's timesheet:
- Students who registered on time but can't see their course on the first day, or who changed sections and lost track of their work.
- Faculty who stop trusting the Moodle class list and start enrolling students manually, which creates enrollments the script will never clean up.
- Moodle admins whose day-to-day Moodle administration turns into ticket triage during the busiest weeks of the year.
- Compliance. When a student asks who removed them from a course, or your privacy officer asks how enrollment changes are traced, a log file on a server rarely answers. Quebec's Law 25 and the GDPR both expect institutions to account for how personal information is processed.
Aren't Moodle's built-in enrolment plugins enough?
Moodle ships good tools for this, and they deserve a fair look. The external database enrolment plugin reads enrollments from a table and can create missing courses. Flat file enrolment processes a CSV file of add and delete operations. Upload courses and upload users handle bulk creation, and cohort sync enrolls a whole population, such as a program, into a course.
These plugins are reliable, and many custom integrations are built on top of them. What they don't do is the institution-specific part:
- Produce a clean table or file from your SIS, in the shape Moodle expects, on time.
- Decide naming, categories, templates and which sections share one Moodle course.
- Choose a safe behavior when a student drops. The external unenrol action setting, for example, decides whether a removed student is unenrolled, suspended or left alone. The wrong choice either deletes grades or leaves access open.
- Record why each change happened, not only that it happened.
So "built-in plugin plus a SQL view" is still a custom integration. The code has just moved to the SIS side. Closing that gap is what a full LMS integration is meant to do.
How to decide: custom scripts or a maintained integration
The comparison below assumes a script that covers the whole term, not only the first enrollment run.
| Dimension | Custom scripts | Maintained integration |
|---|---|---|
| IT time per term | Estimated 40–80 hours | Under 4 hours of monitoring and exceptions |
| Moodle upgrades | Your team retests and patches | The vendor tracks Moodle releases |
| SIS change or migration | Extraction rewritten | Connector replaced, rules kept |
| Multi-section courses | Mostly manual | Rule-based and logged |
| Add/drop | Nightly batch is common | Real-time or scheduled, within minutes |
| Audit trail | Server logs, if any | Every action timestamped and attributed |
| Support | Whoever wrote the script | Support SLA |
Before you decide, run your current setup through these seven questions:
- Can at least two people run, fix and redeploy the script without its original author?
- Did it survive your last Moodle upgrade without code changes, and has it been tested on the version you plan to run next?
- When a student drops, is the enrollment suspended rather than deleted, so grades and submissions survive a mistake? (See why students lose access during add/drop.)
- Does it build multi-section and cross-listed courses, or does someone merge them by hand? (See how meta-courses fix duplicate courses.)
- Do you know a run failed before a teacher tells you?
- For a given student, can you show who changed their enrollment, when, and from which SIS change, in a few minutes?
- How many hours did the last start of term take, honestly counted?
If most answers are yes, your script is in good shape: document it, monitor it and keep it. If three or more are no, it costs more than it appears to, and rewriting it from scratch tends to recreate the same problems. That is the point where a maintained integration is worth pricing.
How Classeo handles it
Classeo replaces the SQL and cron scripts with a maintained integration between the SIS and Moodle. It reads sections, instructors and enrollments from Jenzabar, PeopleSoft Campus Solutions, Banner, Workday Student, Omnivox, Clara or COBA, and every SIS class record becomes a Moodle course at the start of term, with no manual creation.
Enrollment sync runs in real time or on a schedule, so add/drop changes reach Moodle within minutes. Multi-section and cross-listed offerings are merged into a Moodle meta-course with one gradebook, one forum and a separate enrollment pool per section. At the end of term, completed courses are hidden or archived according to your institution's policy.
Every provisioning, enrollment and archive action is timestamped and tagged with its actor, which is what Law 25 and GDPR questions require. Classeo acts as a synchronization relay and doesn't keep long-term copies of student data, and it runs on Quebec-resident infrastructure. It supports Moodle 3.9 LTS, 4.1 LTS, 4.3, 4.4 and 4.5, and because it is a maintained product, Moodle and SIS changes are LS2's job rather than your team's.
A typical rollout takes four to eight weeks, and the remaining IT effort is usually under four hours per term. The Moodle SIS integration page details each supported system, and the FAQ covers pricing, rollout and data questions.
Key takeaways
- A Moodle provisioning script does five jobs, not one: course creation, initial enrollment, add/drop changes, multi-section courses and end-of-term cleanup.
- Based on LS2's deployments, keeping custom scripts running typically takes an estimated 40–80 IT hours per term, against under 4 hours of monitoring with a maintained integration.
- Moodle's built-in enrolment plugins are solid building blocks, but someone still has to build and maintain the SIS side and the business rules.
- Without a log that ties each Moodle change to its SIS source, answering student complaints and Law 25 or GDPR questions is slow.
- Run your current script through a seven-question check before deciding to keep, rewrite or replace it.
See your SIS feeding Moodle without a script
A 30-minute demo of Classeo creating Moodle courses, syncing enrollments and handling add/drop changes, with time for your edge cases.
Book a demoFrequently asked questions
Can Moodle sync enrollments from an SIS without custom code?
Partly. Moodle's external database and flat file enrolment plugins can read enrollments from a table or a file on a schedule, and the upload courses tool creates courses in bulk. But your team still has to produce that table or file from the SIS, apply naming and category rules, handle multi-section courses and decide what happens when a student drops. That SIS-side work is the custom part.
How many IT hours does a custom Moodle enrollment script take per term?
It depends on scope. LS2's estimate from its deployments is 40–80 IT hours per term once you count maintenance after SIS or Moodle changes, failed runs, manual corrections during add/drop and multi-section courses merged by hand. With a maintained integration such as Classeo, the remaining work is usually under 4 hours of monitoring and exception handling per term.
When does it make sense to keep our own enrollment script?
Keep it when your scope is small and stable: few course sections, no multi-section or cross-listed merges, an SIS that rarely changes, and at least two people who can run and fix the script. Even then, monitor it, test it before every Moodle upgrade and make sure it records who changed what. Replace it when those conditions stop being true.
Which SIS platforms and Moodle versions does Classeo support?
Classeo connects Jenzabar, PeopleSoft Campus Solutions, Ellucian Banner, Workday Student, Omnivox, Clara and COBA to Moodle. It supports Moodle 3.9 LTS, 4.1 LTS, 4.3, 4.4 and 4.5, Moodle Cloud where API access is granted, and third-party hosted Moodle on a case-by-case basis. Other systems with an API, a CSV export or a database view can be reviewed.