What to check before you migrate a course platform (a pre-flight list)

Moving a course platform is one of those projects that's genuinely simple in outline and genuinely easy to get wrong in the details, because the outline is just export from the old one, import into the new one, tell your students, and the details are where a missing video file or an untested checkout link turns a quiet Tuesday into a week of apology emails. The list below isn't exhaustive theory, it's the specific things worth checking before you touch DNS or send an announcement, in roughly the order you should check them.

Export your video library properly, not just your course pages

Course pages and lesson descriptions are usually easy to move, they're just text and structure, but your actual video files are the part that takes real time and the part most creators underestimate. Before you start rebuilding anything, download every video from your current platform in its original or highest available quality, not a compressed preview version, and organise the files by course and module so that re-uploading them into your new course hosting setup is a matter of matching folders rather than hunting through a messy downloads directory at 11pm. A course with forty lessons at an average of fifteen minutes each is roughly ten hours of footage, and depending on your upload speed that alone can take a full day to move, so don't leave it for the night before you planned to launch. If you have hours of cohort recordings or a video library running into tens of gigabytes, start this export days before you plan to do anything else, because upload and download speeds on both ends are usually the slowest part of the entire migration, not the rebuilding of the course structure itself.

Get a clean export of your student list and their access history

Your student list needs to carry more than just names and emails, it needs which course or courses each person has access to, when they enrolled, and ideally what they've paid, because that's what lets you re-enrol everyone correctly on the new platform instead of guessing or, worse, re-charging someone who already paid. Export this as a spreadsheet you can actually read and sort, and cross-check the total count against your payment records from the last few months so a handful of students who paid right before the export date don't quietly fall through the gap between the two systems.

Pull your email list out separately from your course platform

A lot of creators only think about their email list as an afterthought bolted onto the course platform, but if you've been sending newsletters or launch sequences from inside your old platform's built-in tool, that list and its engagement history need their own export, separate from your student roster, because not everyone on your email list has bought a course and you don't want to lose that broader audience in the shuffle. Once it's out, you can route campaigns through your own email campaigns setup using a provider like Resend, which also means you're not locked into whatever sending reputation and deliverability your old platform built up on your behalf.

Test checkout with a real payment before you announce anything

This is the step people skip because it feels like the migration is basically done once the course content is up, and it's the step that causes the most damage when it's skipped, because a broken checkout page found by your first real customer after a launch email is a far worse experience than finding it yourself two days earlier with a test purchase. Buy your own course with a real card for a small amount, confirm the payment clears through Razorpay, confirm enrolment happens automatically, confirm the confirmation email actually lands and doesn't sit in spam, and only then consider checkout genuinely ready.

Keep your old platform live during the transition

The single biggest mistake in a rushed migration is cancelling the old subscription the moment the new platform looks ready, because looking ready and actually receiving every payment correctly are two different things that only get confirmed once real students have gone through the new checkout a few times. Run both platforms in parallel for at least a week, ideally closer to two, point new marketing and new sales at the new platform while leaving existing students able to reach the old one if anything about their access needs fixing, and only archive the old account once you've watched a full week of real enrolments land cleanly. The full breakdown of this process, including how long other creators typically keep the overlap window open, is on the migration guide.

None of this is complicated on its own, it's just sequencing, export the heavy stuff first, verify the money-handling stuff before you tell anyone, and don't pull the plug on the old platform until the new one has proven itself with real transactions rather than test ones you ran yourself. It's also worth checking whether you had any Zapier, Make, or Pabbly automations wired into the old platform, tagging buyers in a CRM or posting sales to Slack, because those connections don't carry over on their own and need to be rebuilt against the new platform's webhook events before you consider the migration finished. A migration that follows this order tends to be boring in the best possible way, which is exactly what you want when actual students and actual payments are involved.