Documentation checked 14 September 2026. A planning checklist based on supplier documentation, not hands-on migration testing.
Moving course platforms looks like a big export and import job. Download everything from the old one, upload it to the new one, update your links, done.
That approach can miss the promises a migration needs to preserve.
Because a course platform migration isn't really about files. It's about promises. You promised learners access to their courses. You promised members their progress would be there. You promised subscribers you wouldn't email them after they unsubscribed. You promised paying members they'd keep being able to log in.
Every one of those promises can quietly break during a move, even when the migration "looks" finished. This course platform migration checklist helps you protect them, one by one, before you switch anything over.
Download the migration data matrix (CSV). It's a working worksheet, not a migration tool. It has one clearly labelled example row and blank rows for you. Don't add passwords, card details or more personal data than you need.
Start With the Promises You Can't Break
Before listing a single file, list the things learners and staff must still be able to do after the move. For example:
- buy a course
- sign in
- carry on from the lesson they were on
- get a completion record
- join a live session
- post in a members' space
- receive important service emails
Then define who each promise applies to. "Learners moved" is too vague to check. A useful version separates:
- active learners
- alumni with lifetime access
- staff test accounts
- complimentary enrolments
- refunded orders
- members on active monthly plans
Use our course platform guides for learning requirements and the community platform guides for spaces and permissions. If the move changes your costs or means paying for both for a while, put the figures into the UK course platform cost guide and calculator.
List Every Record So No Student, Payment or Email Slips Through
Use one worksheet row for each meaningful item or group. One data area may need several rows, because different groups follow different rules.
| What | List separately | Don't assume | Proof that it worked |
|---|---|---|---|
| Course content | Products, modules, lessons, release rules, prerequisites, quizzes, assignments, completion rules | Imported text recreates the same order, formatting or rules | Lesson counts match, spot checks, one full test journey |
| Files and media | Videos, audio, PDFs, captions, transcripts, downloads, embeds | Externally hosted files, captions or permissions come across | File list, playback and download checks |
| Learner accounts and access | Accounts, emails, product access, cohorts, groups, roles, expiry dates | An imported contact can sign in with the right access | Counts match, plus sample sign-ins |
| Progress and completion | Lesson progress, attempts, scores, submissions, completion dates | Old progress fits the new platform's model | Record-by-record sample and a learner's-eye check |
| Certificates | Files, issue dates, IDs, templates, reissue rules | Old certificates can be recreated or still verified | Certificate register and sample retrieval |
| Orders and payments | Orders, status, refunds, invoices, discounts, tax, instalments | A sales export is an accounting record or should trigger access | Totals reconciled, finance sign-off |
| Active subscriptions | Plan, price, currency, interval, next charge, trial, discount, status | Recurring payments can be transferred | A named plan, affected-member list, payment test |
| Community | Spaces, memberships, posts, comments, messages, events, reports, moderation | Moving membership also moves discussions or history | Space map, sampled content, moderation decision |
| Email and consent | Contacts, subscription status, consent proof, preferences, unsubscribes, bounces, segments | An email address means permission to market | Field map, counts, sample histories, privacy sign-off |
| Automations | Triggers, actions, tags, webhooks, connections, alerts | A similar integration behaves the same way | Test results, logs, named owner |
| Domains and links | Custom domains, DNS, public URLs, redirects, embedded links, email authentication | Old links and bookmarks keep working | URL map and redirect tests |
| Staff and records | Admin roles, tutors, support notes, reports, policies, scheduled tasks | Admin history and limited roles can be recreated | Role test and records register |
One warning: matching totals aren't enough. The same number of contacts on both sides can still hide duplicates, missing people or wrong access. Pair counts with sample checks and at least one full journey.
Our platform migration pilot guide shows exactly how equal counts can hide problems.
Protect Subscriptions, Email Consent and Learning Records During Migration
1. Active subscriptions
This is the big one. On many platforms, recurring payments can't simply be moved.
Podia's switching page, for example, says it can't move active paying subscriptions, and recurring plans must be set up afresh. That's common when switching payment systems.
What it means in practice: every paying member needs to take an action, usually entering their card again. Some won't. So plan it like a campaign:
- map when each member's next payment is due
- time the switch so nobody gets charged twice, or misses a charge
- write clear, friendly emails explaining what to do and why
- follow up with anyone who hasn't moved
- keep a list of exceptions with a named owner
2. Email consent and unsubscribes
An email address is not permission to send marketing.
If your unsubscribe and bounce lists don't come across, you could end up emailing people who opted out. That's a trust problem and potentially a compliance one.
Keep consent proof, preferences and suppression lists as separate items in your inventory, and check them before anyone sends a single email from the new platform.
3. Progress and certificates
Learners notice instantly if their progress has reset to zero. And past certificates may need to stay verifiable.
If progress can't move, decide how you'll handle it: a note on their account, a manual "mark as complete", or a written record. Tell learners before they find out the hard way.
Label Your Evidence Honestly
Give each worksheet row a status:
- Supplier says: the supplier's current official material says it's supported. Keep the link, wording, plan and date.
- Verified: your own test produced proof for that sample, account, plan and date.
- Assumption: an expected result that still needs proof.
- Unknown: missing, unclear, account-specific or untested.
- Not applicable: outside the scope, with a reason.
"Supplier says" isn't a criticism and "verified" isn't a permanent guarantee. They answer different questions.
Read "Free Migration" Offers Like a Contract
Here's why a line-by-line list matters, using Podia as a worked example.
Podia's switching page says its team moves products, courses, customers and email lists by hand, within plan limits. It also says it imports customer emails, products bought and community-plan membership, but can't move active paying subscriptions.
Its pricing page describes migration help as included, listing course and download files and text, customer emails, and free community and membership subscribers. Product limits are 50 on Mover and 150 on Shaker and Earthquaker.
Its help article adds that a paid plan is required, and that tests or quizzes, pipelines and site pages are not migrated. Podia's pricing page says to request a refund within 72 hours of the most recent payment; it does not offer partial annual refunds. Its migration help says no portion of the plan payment can be refunded once migration work begins, with no exceptions. Confirm this before authorising the work.
These are Podia's own statements, not our test results. And they still leave open questions about progress, certificates, discussions, externally hosted files and consent records. Ask your supplier to confirm those for your account, and write the answers into your worksheet.
Write the Test Before You Move Anything
"Looks right" is not a test. Before the transfer starts, write down for each row:
- the exact group and the time of the source snapshot
- the expected count, link or behaviour on the new platform
- which records you'll check and why they're the risky ones
- where proof will be kept
- who checks and who accepts the result
- how much difference is acceptable, if any
- what happens to items that can't move
Choose your samples deliberately. Include a current learner, an alumnus, a staff member, a complimentary enrolment, a refunded order, a member about to renew and any odd case that matters to you. Use made-up test accounts for journeys where you can.
Privacy and Old Data: Keep the Decisions Visible
Moving platforms changes where personal data lives and who handles it.
GOV.UK summarises UK data protection principles including fair, lawful and transparent use, specific purposes, data minimisation, accuracy, not keeping data longer than needed, and appropriate security.
Your worksheet helps surface the decisions. It doesn't decide your lawful basis, how long you keep data, your consent position or your security controls. Give those questions to the right person and get advice where needed.
And don't treat this guide as permission to delete the old system. Closing it and deleting data are separate decisions, made later, based on contracts and obligations.
Agree Your Pause Rules Before the Pilot
Write down the conditions that stop the project moving forward. For example, pause if:
- you can't define who's being moved or when the snapshot is taken
- an important data type has no way to move or continue
- active subscriptions have no agreed plan
- access, privacy, security or contract questions are open
- the new plan's limits or migration allowance aren't confirmed
- you don't have a usable backup of the old data
- the people responsible for sign-off and rollback aren't available
Pausing isn't failure. It stops a deadline turning an unknown into an accident.
Run a Small Pilot With Your Hardest Cases
Move or rebuild one representative programme, including the trickiest relationships, not just your simplest course. Then test the learner, tutor, support, payment, email and community journeys that apply.
Before expanding, make sure:
- every pilot row has proof or an approved exception
- you understand and have communicated any differences
- support and escalation routes are ready
- the switch-over order and data freeze are agreed
- your rollback owner knows what can be reversed and how quickly
Our platform migration pilot guide walks through this rehearsal step by step.
Switch Over Only When Continuity Is Proved
Switching over should be a signed decision based on evidence, not a date in the diary. Confirm:
- what's being moved and what isn't is written down
- counts match for every important group
- sample users can sign in with the right access
- progress, certificates and history have a tested route
- active subscriptions and upcoming charges have an agreed plan
- community permissions and discussions have a confirmed treatment
- email permissions and unsubscribes have been reviewed
- payments, essential emails, integrations, links and support all pass their tests
- open questions are resolved or accepted by the named owner
- the monitoring period, pause triggers and rollback decision-maker are in place
Anything important that's still unknown is a hold. An approved exception should name the people affected, the interim service, the communication, the owner and a review date.
Give Rollback a Person, a Trigger and a Plan
"We can roll back" means nothing unless someone owns that decision.
Write down:
- the rollback owner and their deputy
- how long you have to decide
- what triggers it (wrong access at scale, broken payments, missing records, a critical integration failing)
- what state you'd restore
And remember: rolling back isn't just reopening the old site. New enrolments, progress, posts, payments and preference changes made after the snapshot may need to be reconciled.
After switching over, keep a time-limited list of exceptions and re-run your key journeys. Keep the old system available, where contracts and cost allow, until the owners have signed off the new one.
Questions to Ask Before You Sign a Migration Agreement
- Which data types and quantities are included on our plan?
- Which fields, relationships and histories aren't?
- Who does the move, and what access will they need?
- How are externally hosted files handled?
- Can progress, attempts, completion dates and certificates be kept?
- What happens to active subscriptions, trials, discounts and upcoming charges?
- Do posts, comments, messages, events and moderation records move?
- Can consent records, preferences, unsubscribes and bounces be imported?
- What snapshot, validation proof and exceptions report will we get?
- What will our team need to rebuild, test or communicate?
- What's the pause process if checks fail?
- What access, export and support remain during the rollback window?
Record the answers against the right rows in your worksheet, not in a forgotten email thread.
Course Platform Migration: Quick Answers
How do I move my online course to a new platform?
List every course, file, learner, payment, subscription, email record and integration first. Define how you'll prove each one moved correctly, run a small pilot, then switch over only when the key journeys pass.
Will my members' subscriptions move to the new platform?
Often not automatically. Podia, for example, says active paying subscriptions can't be moved and must be set up again. Plan for members to re-enter payment details.
Will learner progress transfer when I switch platforms?
Not always. Ask the supplier specifically, test a sample, and decide how you'll handle progress that can't move.
Is an email address enough to keep emailing someone after migration?
No. Keep consent records, preferences and unsubscribe lists, and check them before sending from the new platform.
When should I close the old platform?
Only after the new platform has been signed off, the rollback window has passed, and separate decisions about keeping or deleting data have been made.
Related Guides
- platform migration guides. Our hub for migration planning.
- UK buyer guides. UK contract, billing and operational questions.
Sources
We haven't carried out a live Podia migration for this article. Supplier statements are attributed as the supplier's own. How a transfer behaves for your account remains unverified until you test it.
- Switch to Podia (checked 14 September 2026): https://www.podia.com/switch
- Podia pricing (checked 14 September 2026): https://www.podia.com/pricing
- Migrating your products to Podia (dated 10 July 2026, checked 14 September 2026): https://help.podia.com/en/articles/11370439-migrating-your-products-to-podia
- GOV.UK, Data protection (checked 14 September 2026): https://www.gov.uk/data-protection