Case study 01 · Aug 2025 – present · Technical lead, then project manager and main LMS administrator # Moving a government training portal onto Moodle 5.0, now with 3,800+ users I was the project manager for a state government training portal's move from an outdated Drupal LMS to Moodle 5.0, which brought online modules and facilitated session booking onto one platform. ## At a glance - **My role:** technical lead from scoping, then project manager and main LMS administrator - **Period:** Aug 2025 – present (scoping from Dec 2024, launched Feb 2026) - **Scale:** over 3,800 users (over 1,700 carried across, over 2,000 new since launch), 8 online modules, face-to-face and virtual sessions, 7 user roles, about 140 tracked items after launch - **Worked with:** a state education department, a training delivery partner, an offshore development vendor and the studio's director - **Tools:** Moodle 5.0, a Drupal-based LMS, Excel and SharePoint trackers, Python, PHP - **Headline outcome:** since launching in February 2026, the portal has gained over 2,000 new users, and every release has gone live only after checks on staging and live ## The situation The portal trains school council members across the state. It ran on a Drupal-based LMS that had fallen several major versions behind, and updating it in place was no longer a safe option. The old portal also covered only half the program. It delivered the online modules, while the training delivery partner ran face-to-face and virtual sessions through its own booking system. Participants used two systems for one program. The new platform had to bring both pathways together, give them equal standing, and carry across every existing user and their training history. ## My role I work for a small Melbourne eLearning studio, where I'm the sole employee. I was the technical lead from scoping in December 2024. When the project was approved in August 2025, I also took on project management. In practice I sit between the department, the delivery partner and the vendor. The vendor builds. I write what needs building, track it, and sign off each release. The director and I agree positions on priorities and changes before they go to the client. ## What I did ### Turned the brief into requirements and a permissions model I wrote the requirements and a role and permissions matrix for seven user roles, from council members to department administrators. The new platform uses custom page templates instead of Moodle's standard pages, so the matrix decided what each role sees on every page, not just what it can do. Once it was agreed, it gave the department, the partner and the vendor one shared reference for how each role should work. ### Kept one numbered record of the work I run weekly meetings with the vendor and regular catch-ups with the partner, and I keep the minutes and action log. I also maintain the issue tracker, where every item has a number. Since August 2026 the vendor confirms each release by item number. I check each item on staging, then on live, before closing it. I keep evidence for every check, such as screenshots and report downloads. That keeps conversations about status short and factual. ### Took the partner and department through testing During user acceptance testing (December 2025 to January 2026), I gave the partner and the department testing resources and a draft user guide. I then combined their feedback into one list for the vendor, so nothing was lost between three organisations. I later expanded the draft into a 30-page participant guide. ### Trained the partner and walked everyone through the system I ran one-on-one virtual training with the partner's staff so they could run the system themselves: setting up sessions, managing users and bookings, and pulling reports. In group meetings with the partner and the department, I walked through the whole system and showed how each role interacts with it, from a council member booking a session to a facilitator marking attendance and an administrator downloading reports. The aim was for everyone to see where their part fitted. ### Launched, then checked the migrated data The portal launched in February 2026 with over 1,700 users carried across from the old portal. Over 2,000 more have registered since, taking it past 3,800. As the main LMS administrator, I'm also the support contact for users, through live chat and the portal's support requests. After launch, I compared 29,016 user-module completion records across two report types. I traced 826 mismatches to one migration rule for part-completed records, and checked the fix cell by cell until the comparison showed no mismatches. I also reviewed the platform's 26 system emails and got them corrected and released. Alongside the main build, I built small tools: help and FAQ pages, a training enquiry form and a certificate designer. Routine changes now don't need developer time. ### Kept the platform current Catching up on several major versions at once is far harder than staying current. On the new platform, I track the Moodle version against its support dates and raise upgrades early. ## Results - Launched in February 2026 with over 1,700 users carried across from the old portal. - Over 2,000 new users registered since launch, taking the portal past 3,800 users. - Over 1,500 session bookings and over 1,000 attendances recorded through the new booking system. - Over 800 online module completions by users who joined after launch. - Online modules and face-to-face and virtual session booking now run on one platform. - About 140 functional items tracked by number after launch, each closed only after checks on staging and live. - 29,016 completion records reconciled, with 826 mismatches traced to one migration rule and fixed. - 26 system emails reviewed, corrected and released in October 2026. - A 30-page participant user guide, one-on-one training for the partner, and whole-system walkthroughs for the partner and the department. ## What I'd do differently - **Reconcile migrated data before launch.** The part-completed records only showed up when I compared reports months after launch. Next time I'd run a record-level comparison on a trial migration and sign it off before go-live. - **Agree the release rule on day one.** Confirming releases by item number made progress clear to everyone, but we only adopted it six months after launch. I'd put it in the kickoff agreement, together with the evidence standard. ## Tools and skills - **Platforms:** Moodle 5.0, Drupal-based LMS - **Delivery:** requirements, role and permissions matrix, issue tracking in Excel and SharePoint, minutes and action logs, user acceptance testing, release sign-off - **Data:** Excel, Python (pandas) - **Technical:** PHP, JavaScript and HTML/CSS for the supporting tools - **AI:** I worked with an AI assistant (Claude) on analysis scripts, tools and drafting. The work split roughly evenly; I set the approach and checked every result. - **Skills:** stakeholder coordination across three organisations, vendor management, training and system walkthroughs, quality control, technical writing ## Related case studies More detail on parts of this project: - [Tracing 826 mismatched completion records to one migration rule](https://dulitha.net/work/lms-data-investigations/) - [Rebuilding two governance tools for school councils, ready for department review](https://dulitha.net/work/self-assessment-and-declaration-tools/) - [Fixing a training portal's 26 system emails and restoring the survey link](https://dulitha.net/work/lms-system-emails/) - [Four small tools that filled gaps around a government LMS](https://dulitha.net/work/lms-supporting-tools/) Earlier work on the original portal, before the move: - [Owning school council eLearning end to end for a state education department](https://dulitha.net/work/school-council-modules-and-updates/) --- *Client, partner and vendor names, and some details, are left out. Any visuals are recreations with invented data.*