Moving a government training portal onto Moodle 5.0, now with 3,800+ users

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.

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