LMS migration checklist: switch without losing students
What to move and what to archive, how to move app users, an eight-week parallel-run plan, and a student communication timeline for switching platforms mid-session.
On this page 11 sections
An LMS migration moves your videos, PDFs, students, enrolments, payment records, test history and app users from one platform to another. Done well, students notice a better app and nothing else: they keep their courses, validity dates and progress. This checklist covers what to move, how to move app users without losing them, a parallel run and cut-over plan, and what to tell students, with a timeline you can adapt.
First, check whether you need to migrate at all
Common reasons to switch are video leaks, a poor student app, and costs or contract terms. If leaks are the only problem and your current system otherwise works, adding protection to it can be cheaper than moving. We explain when an SDK beats migrating. If the app, support or ownership terms are the problem, migrate, and use the LMS features checklist to make sure the new platform fixes it.
Before anything else, read your current contract for three things: your right to export data and original video files, the notice period, and who owns the app listing.
Decide what moves and what doesn't
| Data | Move it? | How | Watch out for |
|---|---|---|---|
| Videos | Yes | Upload your original files to the new platform, which encodes them again | Old platforms may only hold encoded copies; ask for originals early |
| PDFs and notes | Yes | Upload originals | Watermarks and view-only settings must be set up again |
| Students and parents | Yes | Spreadsheet export and import | Duplicates; the phone number is usually the best match key |
| Passwords | Usually not | Move to OTP login, or import password hashes if both systems support the same algorithm | No platform should be able to give you plain-text passwords |
| Enrolments and validity dates | Yes | Map old course IDs to new ones | Every student must keep the exact end date they paid for |
| Payment history and invoices | Archive | Export and keep for your accounts | Saved cards and payment mandates usually can't move between gateways |
| Instalment schedules | Yes, as data | Import due dates and amounts | Students may need to re-authorise automatic payments |
| Question banks | Yes | Export to spreadsheet or Word, then import | Formulas, images and Hindi text often break; check a sample |
| Test scores and ranks | Summaries | Import scores per student, or archive reports | Past all-India ranks can't be recalculated on a new system |
| Watch progress | If possible | Import completion by lesson | Often lost; tell students in advance if so |
| Doubts and discussions | Archive | Export for reference | Rarely worth importing |
Videos and PDFs
Video is usually the longest job, so start it first. Request your original files, not the platform's encoded copies, and build a mapping sheet: old lesson ID, new lesson ID, course, chapter, title and duration. The sheet lets you check that nothing is missing and fix broken links in notes and messages.
Estimate upload time before you promise a date. For illustration: 1,200 hours of lectures at about 1.5 GB an hour is 1.8 TB. At a sustained 100 Mbps upload, that takes about 40 hours; at 50 Mbps, about 80 hours. Then the new platform needs time to encode. If your office connection can't sustain those speeds, ask the new vendor about bulk transfer from cloud storage.
After import, sample-check every course: play the first and last lecture of each chapter, open each PDF and check the watermark shows.
Students, enrolments and payments
- Clean before you import. Merge duplicates, fix phone numbers with missing digits and remove test accounts.
- Preserve validity. A student whose course runs until 31 March must have 31 March on the new system too. Lost days generate complaints fast.
- Handle logins deliberately. If your old system stored passwords properly, it has only hashes. The new system can accept them only if it supports the same password hashing algorithm. Otherwise, move students to OTP login, which avoids a mass password reset.
- Plan for recurring payments. Saved cards and automatic payment mandates are generally tied to the gateway and merchant account that set them up. Ask both gateways how to handle them, and plan for students on instalments to re-authorise.
- Keep the old payment records. Refunds and disputes for past payments still go through the old gateway, so export transaction reports before access ends.
Tests and results history
Export your question bank early and test-import 50 questions covering every type you use: single correct, multiple correct, numerical, match the following, with images, formulas and Hindi text. Fix the problems before the full import.
For results, import each student's past scores so progress charts still make sense, and archive rank lists as reports. Don't promise students that old all-India ranks will appear on the new system: ranks depend on who took the test at the time.
Moving app users to a new app
How painful this step is depends on one question: whose developer account is your current app in?
| Situation | What happens | Student effort |
|---|---|---|
| The app is in your own Google Play and Apple accounts | The new vendor publishes an update to the same listing, with the same package name and bundle ID | None: they update as usual |
| The app is in the old vendor's accounts, and they agree to transfer it | Both stores support transfers between developer accounts; the app keeps its users, ratings and reviews | None, once the transfer is done |
| The vendor won't transfer, or it was a marketplace app | You publish a new app | Every student must install it and log in again |
On Android, every update must use the same package name and signing key, and a package name can never be reused for a different app. If your app uses Play App Signing, Google holds the signing key, and the account owner can ask Google to reset a lost upload key. Transfers need both parties' cooperation: see Google's app transfer process and Apple's app transfer overview for the requirements.
If you must publish a new app, keep the old one working until the current batch ends, send direct store links by SMS and WhatsApp, put QR codes in classrooms, and track who hasn't logged in to the new app so counsellors can call them. Then make sure the next app sits in your own accounts. Our guide to making an app for coaching classes covers what to insist on.
Parallel run and cut-over
Never switch in the middle of exam season. Cut over between batches, or at least weeks away from a major exam. An illustrative eight-week plan:
| Week | Work |
|---|---|
| 1 | Contract review, export requests, new platform and developer accounts set up |
| 2 to 4 | Video and PDF upload, course structure rebuilt, question bank imported |
| 5 | Student import tested with 20 real students and two teachers; fixes |
| 6 | Parallel run: new batches start on the new platform; existing batches stay on the old one |
| 7 | Cut-over: final export of changes since the first import, then all students switch; old platform becomes read-only |
| 8 onwards | Support peak, follow-up with students who haven't logged in, old platform shut down after the batch ends |
Freeze content changes on the old platform after the final export, keep a rollback option for the first week, and decide in advance who can call it off.
Finally, the data protection side. Under the DPDP Act, your new vendor is a data processor that needs a proper contract, and your old vendor must eventually erase the student data it processed for you. The DPDP Rules also require processing logs to be kept for at least a year, so agree in writing what the old vendor keeps, for how long, and when it confirms deletion.
Telling students
| When | Channel | Message |
|---|---|---|
| Three weeks before | In-app banner, WhatsApp, SMS, email | What is changing, why it is better, and what stays the same: courses, validity, progress |
| One week before | WhatsApp and SMS | The install link, how to log in, and the switch date |
| Switch day | Everywhere, plus a short video | "It's live": login steps and a support number staffed all day |
| One week after | Calls from counsellors | Personal follow-up with students who haven't logged in |
| When the old app closes | Old app and SMS | A final reminder, with the new app's link |
Tell teachers first. Students ask their teachers before they read any message.
Key takeaways
- Inventory everything, and get original video files and exports before notice periods start.
- Preserve every student's course access and validity date exactly; import scores, archive old ranks.
- Use OTP login or compatible password hashes; never plain-text passwords.
- Whose developer account holds your app decides whether students update or reinstall.
- Run in parallel, cut over between batches, and over-communicate through teachers and counsellors.
Where Upclass fits
Upclass gives institutes a course website, live classes, tests, payments into their own gateway, a lead CRM, analytics and branded apps on Android, iOS, Windows and macOS, and its team also takes on custom development. If you're weighing a move, the LMS for coaching institutes page describes the platform.
Frequently asked questions
What is LMS migration?
LMS migration is moving an institute's teaching operation from one learning management system to another: video lectures, notes, courses, student accounts, enrolments and validity dates, test banks and results, and app users. A good migration inventories all of this, maps it to the new system, runs both in parallel for a short time and cuts over between batches, so students keep their access and progress.
What is LMS integration?
LMS integration means connecting a learning management system to other tools so data flows between them without manual copying. Common integrations for institutes are payment gateways, live class tools, SMS and WhatsApp messaging, a lead CRM, and video protection or hosting services, usually through APIs or webhooks. Integration adds capabilities to an existing system; migration replaces the system itself.
What are LMS modules?
Modules are the functional parts of a learning management system. For a coaching institute, the usual ones are course and content management (videos and PDFs), live classes, tests and question banks, student and enrolment management, payments, communication, reports and analytics, and the student apps. When migrating, list which modules you use today, because each has its own data to move.