How to Migrate an Online School from Zoom, Drive, and Telegram Without Disrupting Learning

When an online school grows, a stack built from Zoom, Google Drive, and Telegram can begin to create friction. Live classes may sit in one place, worksheets in another, student questions in a fast-moving chat, and attendance or submission records somewhere else again. The problem is not that any one tool is necessarily unsuitable. The problem is that staff and students must constantly remember where each learning task belongs.

To migrate an online school platform successfully, treat the move as an academic operations project rather than a software switch. Your aim is to preserve teaching continuity, protect access to essential learning materials, reduce confusion, and give teachers enough time to make sound decisions about course structure and communication.

This guide sets out a practical sequence: inventory what exists, define what will move, run old and new workflows in parallel, create redirects and clear signposting, communicate with students repeatedly, and complete quality assurance before retiring the old process.

Start with an inventory, not a platform demo

Migration projects often fail because teams begin with features instead of workflows. Before configuring a new environment, document how teaching currently happens across Zoom, Drive, and Telegram.

Create a simple inventory for every active programme, cohort, and course. The inventory should show where students currently find information, how teachers distribute work, how learners submit work, and how the school follows up when someone misses a class or deadline.

Do not assume that every file, chat, or recording should be moved. Migration is a useful opportunity to remove duplicate documents, expired announcements, abandoned groups, and unclear naming conventions. However, avoid deleting material during the early stages. First identify what is current, what is archived, and what requires a decision from an academic or operational owner.

Map the student journey

For each course, write down the journey a student takes from enrolment to completion. Include the points at which they receive a welcome message, join a live class, download materials, ask for help, submit work, receive feedback, and find the next lesson.

If a student currently needs to search Telegram for a Zoom link, scroll through chat history for a worksheet, and request access to a Drive folder, the new setup should make those next steps more visible. A good migration does not merely transfer content; it reduces the number of decisions students must make to continue learning.

Define what “moved” means for each workflow

A complete migration does not always mean replacing every existing tool on day one. Some schools may continue using Zoom for live delivery while centralising course information, tasks, and communications elsewhere. Others may retain a Drive archive for staff while giving students a more structured access point.

For each workflow, choose one of four decisions:

• Move: transfer the workflow into the new environment and make it the standard route.
• Link: keep an existing specialist tool, but provide one consistent place from which students access it.
• Archive: preserve records or resources for reference without presenting them as current course content.
• Retire: stop using a redundant folder, group, process, or duplicate resource after the transition period.

Write these decisions down in a migration register. Each item should have an owner, a target date, a status, and a clear test for completion. For example, “Term 2 worksheets moved” is vague. “All current Term 2 worksheets are available to the pilot cohort, open correctly on mobile and desktop, and are labelled by week” is testable.

Run a parallel launch before making the new system mandatory

A parallel run is a controlled period in which the existing workflow remains available while a selected group begins using the new one. It gives your school a chance to identify missing files, unclear instructions, access problems, and teacher workload issues before every learner depends on the new process.

Choose a pilot that is representative but manageable. A single course, one intake, or a small group of teachers can work well. Avoid choosing only your most technically confident staff or students; you need feedback from people who reflect the experience of the wider school.

1. Set a defined pilot scope. State which course, cohort, teachers, learning materials, and communication channels are included.
2. Set a start and review date. A pilot without a review point can become a permanent double-work system.
3. Keep one source of truth for key information. Even during parallel running, students should know which location contains the official timetable, task instructions, and latest announcements.
4. Record issues consistently. Capture the issue, affected user group, urgency, owner, workaround, and resolution status.
5. Review teaching impact. Ask whether the change makes it easier or harder for teachers to prepare, communicate, monitor participation, and return feedback.

Parallel running should reduce risk, not create endless duplication. If teachers are expected to post the same message in multiple places, decide which messages genuinely need duplication and set an end date for that requirement. A short, well-managed overlap is usually easier to sustain than an open-ended arrangement.

Create redirects that lead students to the right next action

Students rarely experience a migration as a single announcement. They encounter it at the moment they click an old Zoom bookmark, open a familiar Drive link, or return to a Telegram group. That is why redirects and signposting matter.

For every old access point that students are likely to use, add a concise notice explaining what has changed and what to do next. Where possible, keep the message focused on one action.

Example redirect message: Course materials and weekly tasks are now available in the new course space. Please use the link in your welcome message to sign in and open this week’s lesson. This folder will remain available for reference until the stated transition date.

Use the same language across announcements, teacher scripts, welcome emails, old folders, and Telegram messages. Inconsistent naming creates unnecessary support requests. If you call the new location a “student hub” in one message, a “portal” in another, and a “course page” somewhere else, students may assume these are different places.

Plan redirects for common failure points

• Old Zoom invitations or recurring meeting links.
• Drive folders saved in bookmarks or shared in previous messages.
• Pinned Telegram messages and group descriptions.
• Automated or template welcome communications.
• Teacher documents that contain old links.
• Course PDFs, worksheets, and slide decks with embedded URLs.

Keep a register of links and notices that require updating. This is especially important if course resources have been reused across multiple terms or copied between cohorts.

Communicate early, clearly, and more than once

Most migration confusion is not caused by unwillingness to change. It is caused by students receiving incomplete information at different times, through channels they do not check, or in language that assumes they already understand the new process.

Your communication plan should answer five questions: what is changing, why it is changing, when the change takes effect, what students need to do, and where they can get help.

Use a communication sequence rather than a single launch announcement: initial notice, practical instructions, a reminder shortly before the change, and a follow-up after launch. Keep instructions short and action-led. A student should be able to tell, within a few seconds, what they need to do next.

It is also helpful to identify a support route for the first phase. This might be a named staff contact, a scheduled help session, or a structured way to report access issues. Make sure staff know how to distinguish a simple login problem from a missing enrolment, an incorrect course assignment, or a question about learning content.

Complete quality assurance before retiring the old stack

Quality assurance is the point at which you verify the learner and teacher experience, not just whether files appear to have transferred. Test the system using realistic tasks and different user roles.

At minimum, ask a teacher and a student tester to complete the following without live assistance:

• Find the correct course and current lesson.
• Open essential materials on a desktop device and a mobile device.
• Locate or join the next live session if one is scheduled.
• Read an announcement and identify the required action.
• Submit or respond to an assignment workflow, if applicable.
• Find the appropriate route for academic or technical support.
• Confirm that old links and pinned messages point users to the current location.

Maintain a launch checklist with clear pass, fail, and follow-up statuses. Prioritise issues that block access to teaching, prevent students from finding current work, expose incorrect information, or create inconsistent instructions. Less urgent improvements can be scheduled after launch, but they should still have an owner and a review date.

Make the new workflow sustainable

The final stage is not simply turning off old tools. It is agreeing how the school will maintain the new operating model. Decide who owns course structure, who reviews outdated materials, who updates links, and how staff request changes. A migration can quickly lose its benefits if old habits return without a shared standard.

SubSchool can support online schools that want to reduce repetitive teaching administration while keeping teachers responsible for the content and final educational decisions. As you design your migration, focus on the recurring tasks that consume staff time and the moments where a clearer, teacher-led workflow would help students act with confidence. Explore SubSchool for online schools to consider how a more connected operating approach could fit your school’s transition plan.

A careful migration is less about moving everything at speed and more about protecting the learning experience. Start with a reliable inventory, introduce change through a controlled parallel run, signpost old routes clearly, communicate consistently, and test every essential journey before you retire the previous workflow.