The contract is signed, the start of term is on the calendar, and everyone wants to know the same thing: will classes be ready in Microsoft Teams, Moodle and student calendars when faculty start preparing? The honest answer is that technology rarely decides it. Decisions, access and testing do.
This guide lays out a realistic plan for connecting a student information system (Omnivox, Clara, COBA, Banner, PeopleSoft Campus Solutions, Workday Student or Jenzabar) to Teams, Moodle or calendars. It's written for the IT lead running the project, the registrar's office that owns course data and the pedagogical team that will hear from faculty if something goes wrong.
Why do SIS integration projects slip?
Rarely because of code. They slip because:
- Access takes weeks. A read account on the SIS, consent for an application in Microsoft Entra ID or a web service token in Moodle each need someone with the authority to approve it.
- Decisions stay open. How should classes be named? Which cross-listed sections are merged? What happens to a team at the end of term? Each unanswered question blocks configuration.
- The data surprises everyone. Sections without an instructor, students without an institutional account, courses coded differently from one department to the next: real data always contains cases nobody mentioned at kickoff.
- The calendar is unforgiving. A two-week delay in May costs nothing. The same delay in August pushes go-live into the first week of class.
What a late or rushed go-live costs
Faculty who don't see their classes start building their own, which creates duplicates the integration then has to reconcile. Students who registered late can't find their course. The help desk absorbs the first weeks of term. And IT ends up doing by hand the work the integration was supposed to remove: 40 hours or more per term at a mid-sized college, according to the estimate detailed on our methodology page.
What doesn't work
A big bang on the first day of class. Turning the integration on for the whole institution the day students arrive leaves no time to catch errors before everyone sees them.
Configuring before deciding. Starting the setup while naming and fusion rules are still under discussion means doing it twice.
Testing with sample data. A test file with ten clean sections proves the connection works. It doesn't prove your data does.
Treating it as an IT-only project. If the registrar's office and the pedagogical team aren't involved, the rules will be wrong in ways IT can't see.
A realistic rollout plan, week by week
The plan below fits the typical four-to-eight-week range. Shorter projects compress the same steps; none of them disappears.
| Phase | Typical timing | Led by | Done when |
|---|---|---|---|
| Kickoff and privacy review | Week 1 | IT lead, privacy officer | Scope and roles confirmed, impact assessment under way |
| Access and connection | Weeks 1–2 | IT lead | The integration can read the SIS and write to the platform |
| Rules and decisions | Weeks 2–3 | Registrar's office, pedagogical team | Naming, fusion, roles and archive policy signed off |
| Dry run and reconciliation | Weeks 3–5 | IT lead, vendor | Counts match the SIS and every exception is explained |
| Pilot | Weeks 5–6 | Pedagogical team | A few departments teach with real classes |
| Go-live and close support | Weeks 6–8 | Everyone | All classes live and add/drop changes flowing |
Week 1: kickoff and privacy review
Confirm the scope: which SIS, which platforms, which terms and which campuses. Name an owner for each decision. Start the privacy impact assessment now, not after the pilot. Our Law 25 due-diligence checklist lists the questions your privacy officer is likely to ask. Agree as well on a go/no-go date: the last day on which you can still fall back on the previous process if testing reveals a problem.
Weeks 1–2: access and connection
Grant the integration read access to the SIS, approve the application in Microsoft Entra ID for Teams and calendars, or create the web service account in Moodle. Agree on how people are matched. The SIS student number linked to the Entra ID account is a more reliable key than an email address, which can change.
Weeks 2–3: rules and decisions
Write down the rules the integration will follow:
- The naming convention for classes (course code, section, term).
- Which cross-listed or multi-section courses are merged into one class or meta-course.
- Roles: instructor, co-instructor, teaching assistant.
- What happens to classes that were already created by hand.
- The end-of-term policy: archive, hide or keep, and when.
Weeks 3–5: dry run and reconciliation
Run the integration on real SIS data without publishing anything to students. Compare counts by department: sections, students, instructors, merged groups. Investigate every gap. Pay particular attention to cross-listed sections and to students enrolled in more than one program; that's where the rules and reality most often disagree. Then test changes: add a student in the SIS, drop another, move a section to a new room, and check that each change reaches the platform.
Weeks 5–6: pilot
Open real classes to a few departments with motivated instructors. Their feedback catches naming and fusion issues before the whole institution sees them, and they become the colleagues others turn to during launch. Our article on why faculty don't adopt new campus technology explains why this group matters so much.
Weeks 6–8: go-live and close support
Publish all classes early enough for faculty to prepare, ideally a week or two before the first day of class. Then keep someone watching the integration every day through add/drop week, when changes peak, with a clear path for escalating exceptions.
If term starts in two weeks
An express deployment of about ten days is possible when the start of term is close. It follows the same steps in compressed form, so it works best when SIS access can be granted within a day or two, the naming and fusion rules are settled in a single meeting, and the dry run starts with the largest departments.
After the first term
The project isn't over at go-live. At the end of the first term, run the archive policy as decided and check the result with the registrar's office and a few instructors. Review the exceptions logged during the term, such as unmatched accounts, manual additions or sections without an instructor, and adjust the rules before the next term's classes are created. That review is what turns a successful launch into a process that runs on its own.
How LS2 approaches it
LS2's integrations, Teameo for Microsoft Teams, Classeo for Moodle and Calendo for calendars, are deployed in four to eight weeks in a typical project, with a ten-day express option when the start of term is close. They connect natively to Omnivox, Clara, COBA, Banner, PeopleSoft Campus Solutions, Workday Student and Jenzabar, so the project starts with configuration rather than custom development.
The rules decided in weeks 2 and 3 (naming, meta-course fusion, roles and end-of-term archiving) are settings in the product rather than code, so they can be adjusted for the next term without a rewrite. Every action the integration takes is logged with a timestamp and its source, which makes the dry run easier to reconcile and gives the privacy officer the trail they need. Once the integration is live, the ongoing effort typically comes down to a few hours of monitoring and exception handling per term.
LS2 is a Microsoft Partner for higher education, and more than 50 colleges and universities run its products. To build a timeline around your own SIS and start date, contact the team.
Key takeaways
- Plan four to eight weeks from kickoff to go-live, counting back from the date faculty need their classes, not from the first day of term.
- Most delays come from open decisions rather than technology: naming, cross-listed sections, roles and archive policy.
- Run at least one full dry run on real SIS data and reconcile the counts before anything reaches students.
- Go live with a pilot group first, then the whole institution, and keep support close through add/drop week.
Map your own rollout timeline
A 30-minute demo walks through the integration with your SIS and platforms, and the steps between signing and the first day of class.
Book a demoFrequently asked questions
How long does an SIS integration with Teams or Moodle take?
Typically four to eight weeks from kickoff to go-live, depending on the SIS, the number of platforms, the quality of the data and how quickly decisions are made. When the start of term is close, an express deployment of about ten days is possible, provided access to the systems and the key decisions come quickly. The steps are the same; they're just compressed.
When should we start the project to be ready for the fall term?
Count back from the date faculty need their classes, ideally a week or two before the first day so they can prepare content. With a four-to-eight-week rollout, that means starting in the spring for a late-August term, before staff vacations. Starting in mid-August remains possible with an express track, but it leaves little room for testing.
Who needs to be involved on the institution's side?
Four roles at minimum: an IT lead who grants access to the SIS and to Microsoft 365 or Moodle, the registrar's office for course and section rules, a pedagogical adviser or instructional designer who speaks for faculty, and the person in charge of privacy for the impact assessment. A sponsor who can settle disagreements quickly saves more time than any technical shortcut.
What should we test before going live?
Run a full dry run on real SIS data and compare counts: sections, students, instructors and merged groups in the SIS against what the integration would create. Then check edge cases such as late registrations, students without an account, sections without an instructor and courses taught by several teachers. Finally, add and drop a student and watch the change propagate.