Rolling Out an LMS at a School or College: A 90-Day Plan

An LMS rollout rarely fails on the software. It fails when accounts are wrong on the first Monday, when teachers saw the system once in a staff meeting, and when nobody owns the list of things that broke. A workable LMS implementation plan fixes the order of work so those three problems are dealt with before students log in.

The plan below fits one term of preparation: about 30 days of setup, 30 of pilot and 30 of training and launch. The examples use Moodle, but the sequence holds on any platform. Treat the 90 days as a planning frame. A small school can move faster, and a college with several campuses and a complicated student information system (SIS) will need longer.

Settle five decisions before day one

Setup stalls while these are open, so get them signed off first.

• One owner. A named person with hours set aside for the project, not a committee. They chair the weekly check-in and settle disputes between departments.
• The scope of the first term. Which year groups or programs, and which uses: sharing materials, collecting assignments, quizzes, grades. "Everything, for everyone" is how launches slip.
• The source of truth for people and classes. In almost every school this is the SIS. The LMS reads from it and is never edited by hand to disagree with it.
• How people sign in. If staff and students already have Google Workspace or Microsoft 365 accounts, use those. A separate LMS password tends to be the most common support request in the first month.
• What happens to the old system. Old courses can be migrated, archived read-only or left behind. Migrating everything is rarely worth the effort.

The LMS implementation plan at a glance

Phase	Days	Main work	Done when
Foundation	1 to 30	Hosting, sign-in, SIS sync, category structure, course template	A test teacher and a test student can log in and see the right classes
Pilot	31 to 60	A small set of real classes, weekly feedback, fixes	Pilot teachers have taught a full unit and the open issues are few and understood
Training and launch	61 to 90	Task-based training, help desk, launch at a term boundary	Every class in scope has a course, a trained teacher and its students enrolled

Days 1 to 30 are for accounts, sync and structure

Sign-in

In Moodle, sign-in through an existing identity provider is configured under Site administration > Server > OAuth 2 services and then enabled as an authentication method. Test with a real staff account and a real student account, and include a student whose name or email address changed during the year. Those are the accounts that end up duplicated.

SIS sync

There are three common ways to move users and enrollments from the SIS into the LMS, in rising order of effort:

1. A scheduled CSV export. The SIS writes a file each night and the LMS imports it. Moodle accepts users, course enrollments and cohort membership in one file under Site administration > Users > Accounts > Upload users, and the Upload users documentation lists every column it understands.
2. A standard roster feed. If the SIS can produce OneRoster or IMS Enterprise data, the LMS can read it on a schedule through a core feature or a plugin, with less custom mapping.
3. A direct connection. The LMS reads a database view or an API that the SIS exposes. Moodle's External database enrolment plugin works this way, and it is one of several enrolment plugins in the Moodle documentation.

A minimal upload file looks like this:

username,firstname,lastname,email,idnumber,course1,role1,cohort1
s.rivera,Sam,Rivera,s.rivera@example.edu,204518,MATH-9A-T1,student,year9

Whichever method you choose, match people on the permanent ID from the SIS (the idnumber field in Moodle) and never on email, which changes. Decide what happens when a student leaves a class. Suspending the enrollment keeps their work and grades in the course where a teacher can still reach them, so it is the safer default mid-year than removing the enrollment outright. Send the sync error report to a named person every morning, because an unread error log is how a whole class goes missing in week two.

Structure and templates

Mirror the school in course categories (year, department, term) and agree a short-name pattern that includes the term, such as MATH-9A-T1, so the sync can match classes without guesswork. Then build one course template with the same sections in every course: an overview, one section per week or unit, and a place for assessments. Restore that template into each new course. Students who find things in the same place in every subject need far less help.

Days 31 to 60 are a pilot with real classes

Choose a handful of teachers from different departments, and include one skeptic and one person who is not confident with technology. Each pilot teacher runs a real unit of work with real students, including at least one assignment collected and graded in the LMS.

Hold a short check-in every week and keep one issue log with three columns: the problem, who it affects, and the decision. During the pilot, watch for:

• students who cannot log in, or who see the wrong classes
• upload limits that block video or large project files
• how the site behaves on the phones students own, on school Wi-Fi and at home
• where the grade of record lives: if report cards come from the SIS, decide who copies grades across, or whether an integration does it
• what parents can see, if anything

Change the course template and the guides as you learn.

Days 61 to 90 are for training by task, then launch

A tour of every menu teaches nobody. Train in short sessions built around a job a teacher has to do next week: post materials, collect and grade an assignment, build a quiz. Each teacher works in their own course during the session and leaves with something they will use. Back that up with short screen recordings and a one-page guide per task. Pilot teachers make the best trainers, since colleagues ask them first.

Students need an orientation too. A first-lesson activity where everyone logs in, opens a resource and submits a practice assignment finds the broken accounts while a teacher is in the room.

Launch at a term boundary. For the first two weeks, run a help desk with one address or form, staffed by people who can fix accounts on the spot, and sort every request into four piles: account, enrollment, how-to and fault. Freeze the platform for those two weeks: no new plugins, no theme changes, no restructuring.

Measure adoption with numbers the LMS already has

Agree the measures before launch and review them a month in:

• courses in scope that had teacher activity in the last two weeks
• courses where at least one assignment has been collected and graded
• students who have not logged in since launch, as a list for tutors and not as a score
• help desk requests by pile, week by week
• open sync errors

In Moodle, Site administration > Reports > Custom reports can build most of these and email them on a schedule, and each course has its own logs, activity report and participation report. Use the numbers to find departments that need another session, not to rank individual teachers.

What usually derails a rollout

Dirty SIS data. Duplicate students, classes with no teacher and last year's sections all flow into the LMS. Fix them in the SIS, or they return with the next sync.

Customizing before anyone has used it. Every plugin added before launch is something to test, train and upgrade. Start near the default and add what the pilot proves is missing.

Privacy questions that arrive late. Who can see grades, how long submissions are kept and which outside tools receive student data are design decisions. We cover them in what to ask about student data privacy in an LMS.

How much of this to run in-house

A school IT team can usually handle the structure, templates, CSV sync, training and help desk. Developer time earns its cost in narrower places: a live connection to the SIS or a grade passback, single sign-on with an unusual identity provider, moving course content out of the old platform, reports the built-in tools cannot produce, and sizing the hosting for exam days when every student logs in at once. That is the kind of LMS work we do for schools and colleges, including Moodle integration with student information systems. For what else an LMS commonly connects to, see our guide to LMS integrations.

Frequently asked questions

Should we launch for the whole school at once or in phases?

Phase by use, not by teacher. Launch for every class in scope on the same date so students have one place to look, but limit the first term to a few uses such as materials and assignments. Add quizzes, gradebook work and parent access in later terms.

Do we need to migrate courses from the old LMS?

Usually only a small part. Ask each department to name the courses worth moving and archive the rest in a read-only copy of the old system for a year. Imported courses often need rework to fit the new template.

Can the LMS gradebook replace the one in our SIS?

It can hold day-to-day marks, but report cards and transcripts normally stay in the SIS. Decide early which system holds the grade of record, then either pass final grades across through an integration or have teachers enter them once at the end of term.

Who should own the LMS after launch?

One academic owner and one technical owner. The academic owner decides how the platform is used and keeps templates and guides current. The technical owner looks after the sync, upgrades, backups and the hosting provider.