You can migrate from Teachable without losing students or sales, but only if you treat it as a staged project and not a weekend switch. Teachable exports your people and your payments as data. Your lesson content you rebuild by hand. Plan for weeks, not days, and move one real group of buyers before everyone else. If you want a destination that charges nothing monthly and takes a cut only when you sell, BibliOWLteca is built for exactly this kind of educational store.
TL;DR
- Back up your original media files, student and sales records and email list before you touch anything. Teachable's data export covers people and payments, not lesson content.
- Expect a manual rebuild of lessons, quizzes and attachments. For an established course business, six to twelve weeks is a realistic window.
- Run both platforms in parallel, check access as three kinds of buyer, and send the announcement email last.
- Decide where each revenue stream lands (one-off sales, subscriptions, payment plans) before you cancel anything.
- Migrate when friction outweighs the cost of staying, not out of irritation.
Table of Contents
- Decide first whether to leave
- What to back up before anything else
- What exports and what you rebuild by hand
- A staged plan, from inventory to shutdown
- Realistic timeline
- Protect your search traffic and your students' trust
- Where BibliOWLteca fits
- Our perspective
- FAQ
- Sources
Decide first whether to leave
Migration carries revenue risk, and the cost is mostly your time. One migration framework suggests moving when at least two things are true: platform fees and surcharges take more than 6 to 8% of your revenue, you have hit student, product or storage limits, you pay for extra tools to fill gaps, or key workflows depend on manual workarounds.
Do the sum with your own numbers. Take last year's gross sales, add up everything you paid the platform and your payment processor, and divide. Then list the tools you bolted on: a separate community, a separate quiz tool, a separate checkout for international buyers. If the percentage is high or the list is long, you have a case.
Also write down what you want the new home to do that the old one does not. "Cheaper" is a weak goal on its own. Better goals sound like: sell in several currencies, accept local payment methods, host video and quizzes in one place, run mentorship alongside courses, or keep a storefront that looks like your brand. Those goals decide your destination and, later, how you judge whether the move worked.
What to back up before anything else
Start with a full copy of what you own. A backup guide for course creators names three assets that matter most: the original source media (not the streaming versions you can download back), your student and sales records, and your email list.
Original media
Find the master files: the raw video exports from your editing software, the slide decks, the original PDFs, the audio. These are better quality than anything you can pull back out of a hosting platform, and you will upload them again. If some masters are lost, make a list now so you know which lessons will need a careful download or a re-record.
Student and sales records
Export your user list, enrolments and transactions as spreadsheets and save them in two places. You need them to recreate access for every buyer and to answer refund or invoice questions later. Date each file. Check that the totals look right: row counts should match what the dashboard shows.
The email list
The same guide argues that the email list is the one asset that survives any platform change, and that it should live in a dedicated email service of its own. Whatever you choose, export it separately and confirm you have permission to keep mailing these people. Our guide to student data privacy for course creators covers what you may store and how, and the GDPR checklist for course sellers matters if any of your students are in Europe.
What exports and what you rebuild by hand
The hard truth shapes the whole project. Teachable's public API, launched in 2022 for its Pro and Business plans, covers course lists and metadata, users, enrolments and transactions. It does not expose lesson-level content, lesson descriptions, video URLs, PDF attachments or quiz questions.
In practice that gives you this split:
| Item | How it moves |
|---|---|
| Student names and emails | Spreadsheet export, then import or enrol on the new platform |
| Enrolments (who owns what) | Export, then recreate access per course |
| Transactions and sales history | Export and archive for your records |
| Videos, audio, PDFs | Re-upload from your masters |
| Lesson text and descriptions | Copy and paste, lesson by lesson |
| Quizzes | Rebuild question by question |
| Course structure (sections, order) | Rebuild from a written outline |
| Email list | Export and keep in your email service |
The realistic options are a manual rebuild, or spreadsheet exports for people combined with manual content recreation. Neither is exciting, and both are reliable. Anyone who promises a one-click transfer of everything is skipping the lesson content.
A staged plan, from inventory to shutdown
A staged approach works better than a single cutover: inventory, prove the risky paths, pilot with one real cohort, run in parallel, cut over in a planned window, then decommission. The people who describe it say a smooth migration is boring on purpose, and that the ones that become war stories are the ones attempted in a single weekend. Here is that plan in steps, with the places it goes wrong.
Step 1: Take inventory
Build one spreadsheet with a row per course, and columns for number of lessons, video minutes, attachments, quizzes, price, who is enrolled, and which pages link to it. Add rows for bundles, coupons, order bumps, certificates and any automations or integrations connected to your school.
Where it goes wrong: people forget the small things, such as a free lead-magnet mini-course, a bonus lesson only some buyers received, or a coupon still advertised in an old podcast episode. Each one is a promise to somebody.
Step 2: Choose and set up the destination
Set up your new store before moving a single student. You need a storefront, a checkout that handles your currencies and payment methods, hosted courses, and a place for digital downloads.
On BibliOWLteca you publish e-books, courses, templates and other digital products in your own customisable storefront. Course hosting supports video and quizzes, with mentorship spaces and community features on the same platform. Checkout supports multiple currencies and payment options including Pix, SEPA, crypto and Klarna, and digital delivery is instant. Because those pieces sit together, you spend less of your migration week connecting separate tools. Our guide to building a scalable online store for digital education walks through the storefront side.
Where it goes wrong: building the store and the courses in the same sitting. Set up the shell first, check that a test purchase completes and that the confirmation arrives, then fill it.
Step 3: Rebuild the content
Work course by course, in order of revenue. Upload masters, paste lesson text, rebuild quizzes, attach files, and recreate the section order from your inventory. Use the move as a chance to fix things you have been meaning to fix: a dated screenshot, an audio dip, a quiz question students always dispute.
Budget honestly. One roundup of course platforms puts the work at six to twelve weeks for an established business, and warns that rushing risks your student data, search visibility or payment continuity. A creator who moved more than 30 Teachable courses in 2025 called it a monster project, yet reported hardly any confusion among over 1,000 student accounts. Scale is the variable: one course with 40 lessons is a few evenings, thirty courses is a quarter.
Where it goes wrong: copying lessons in a different order than students know, or renaming courses. Keep titles and structure identical on day one. Improve later.
Step 4: Move your students and their access
Every person who paid must be able to log in and find what they bought. Using your exported enrolment list, enrol each buyer in the matching course on the new platform, one course at a time. Keep your original spreadsheet as the master list and tick off each batch.
People with partial progress are the awkward group. If you cannot carry over progress, tell them honestly in advance and keep the old lessons available to them during the overlap, so nobody loses their place or their certificate.
Where it goes wrong: matching on the wrong email. Buyers often purchased with one address and read newsletters at another. Match on the purchase email, and give people a clear way to ask for access to be moved.
Step 5: Handle payments and subscriptions
This is where migrations lose money. List every revenue stream: one-off sales, payment plans, memberships or subscriptions. For each one, decide whether it ends on the old platform, continues there until it runs out, or moves.
A sensible default is to keep existing subscribers and payment-plan customers billing where they are until their term ends, and send all new sales to the new store. That removes the risk of double charging or silently stopping a payment. Moving active recurring billing is a decision to make with care and an explicit message to each customer, because they should see exactly what changes and when.
On BibliOWLteca you pay no monthly fee. The platform takes a percentage and a fixed fee from each sale completed through its checkout, with the transaction fee listed from €0.99 on the pricing page. Buyers pay no platform fee. That means the cost of running the new store tracks what you sell, which is helpful during a quiet rebuild month. European tax compliance is built into the platform, which matters if you sell to buyers in Europe.
Where it goes wrong: cancelling the old plan before the last payment-plan instalment is collected, or leaving a stale checkout link live in an email sequence.
Step 6: Rewire the connections
List every integration: your email service, your community, your analytics, your webinar tool, your website buttons, your social bios. Update each link to the new store. Then rebuild the post-purchase emails, so the first message after payment is correct from day one. Our guide to mapping the first onboarding email after payment shows the sequence that works.
If you run a community, plan its move as a separate small project and give it a date. Our piece on building a course community students actually use helps you decide what to carry over and what to restart.
Step 7: Pilot, then check as three buyers
Before you announce anything, test the access experience. One checklist advises picking three real customers, one brand new, one halfway through and one who finished, then logging in as each on the new platform to confirm they see exactly what they paid for. The same source notes that most migrations that go badly fail at preserving purchase history and access.
Do this literally. Write down for each of the three: which courses they should see, what progress they should have, what downloads they own. Then compare with what appears. Fix gaps now, while nobody is watching.
Then pilot with one real group: a small cohort, a loyal segment of your list, or the newest buyers. If your offer is cohort-based, the end of a cohort is a natural point to move; see our guide to how a cohort-based course works.
Step 8: Run in parallel, then cut over
The instinct to switch everything on a Saturday night is wrong. A cutover is a set of promises that cannot be verified at 2 AM against a system that has never run under real load. Instead, keep both platforms live and move new sales first.
One migration playbook suggests running both platforms side by side for 30 days as a safety net, picking a low-traffic hour for the final switch, and watching support messages closely for 72 hours afterwards. Treat those as sensible defaults, then adjust to your own audience. If most of your buyers are in one time zone, switch overnight there. If they are spread around the world, a quiet midweek hour is fine.
The announcement email goes last. Before sending it, one buyer who already paid should be able to log in to the new home and find everything they own. Say what is changing, what is not, the date the old site closes, where to log in, and who to write to if something is missing.
Step 9: Close down the old school
After the overlap, and after the last payment-plan instalment and refund window, cancel the old plan. Before you do, download a final copy of your sales and user data and store it with your backups. Leave a redirect or a notice wherever possible, so old links do not dead-end.
Realistic timeline
Here is a plain way to schedule it, assuming a small catalogue of three to five courses.
| Week | Focus |
|---|---|
| 1 | Back up media, users, sales and list; build inventory |
| 2 | Set up storefront and checkout; run test purchases |
| 3 to 5 | Rebuild courses in order of revenue |
| 6 | Enrol buyers; check as three kinds of customer |
| 7 | Pilot with one group; fix issues |
| 8 to 11 | Parallel run; all new sales on the new store |
| 12 | Announcement, cutover, close the old school |
A single course can go much faster. A larger catalogue will run to the upper end of the six-to-twelve week range or beyond. The point of the table is the order of operations: backups first, announcement last.
Protect your search traffic and your students' trust
If your old course pages rank in search or sit behind links on your site, list those URLs in your inventory and decide where each one points in future. Keep course and lesson names consistent so people who search for a title still find the right page. Update your website buttons, bios and email signatures on the same day as the cutover.
Trust matters as much as traffic. Students bought from you, not from a platform. Tell them early, keep language plain, avoid blaming anyone, and make the new login as easy as the old one. If accessibility mattered to you before, keep it: our practical guide to online course accessibility and the one-hour mobile checklist help you check captions, contrast and phone layout on the rebuilt lessons.
If you have moved a store before, the logic is the same. Our guide on how to migrate from Gumroad follows the same staged pattern for digital downloads.
Where BibliOWLteca fits
If your reasons for leaving are fees, limits or missing tools, the destination should answer them directly. BibliOWLteca is a marketplace and creator platform for educational content: you sell e-books, courses, mentorship programmes, templates and digital downloads from one customisable storefront. There is no monthly fee. The platform earns from a percentage and a fixed fee on each completed sale, with the transaction fee on the pricing page listed from €0.99.
For creators selling beyond the US, the checkout supports multiple currencies and payment options such as Pix, SEPA, crypto and Klarna, and the platform includes European tax compliance. Brazilian creators and others expanding into Europe get localised checkout and payment access. Unlimited hosting, quizzes, mentorship spaces and community features sit in the same account, so the rebuild in step 3 lands in one place. Browse the product categories to see how e-books, courses, templates and digital downloads appear to buyers, then set up your store.
Our perspective
Most creators who leave a course platform are not leaving because of one bad week. They are leaving because the arithmetic stopped working: fixed monthly charges that arrive whether or not a launch went well, tools stacked on tools, and a checkout that does not suit buyers in other countries.
We built BibliOWLteca around a different arrangement. You pay nothing monthly. We take a percentage and a fixed fee when you make a sale, so our income follows yours. That is why we think a migration should be judged on one question: will this store carry my products and my buyers with less friction than the last one?
The rebuild is the part nobody enjoys, and we would rather tell you so. But a store that hosts your courses with video and quizzes, delivers files instantly, runs mentorship and community beside them, and accepts the payment methods your buyers already use is a store you only have to build once.
Move in stages, check access as a real buyer, and send the announcement last. Then let the platform work for you.
BibliOWLteca
FAQ
How long does it take to migrate from Teachable?
For an established course business, six to twelve weeks is the typical range, and faster work risks cutting corners on student data, search visibility or payment continuity. A single small course can take a few evenings. A catalogue of thirty or more courses is a major project.
Can I export my whole course from Teachable in one step?
No. The public API covers users, enrolments, transactions and course metadata, but not lesson content, video links, attachments or quiz questions. You export people and payments as data, and rebuild the lessons from your original files.
What should I back up first?
Your original media files, your student and sales records, and your email list. Store copies in two places, and keep the email list in an email service separate from any course platform.
What happens to my students' access when I move?
You recreate it. Use your exported enrolment list to enrol each buyer in the matching course on the new platform, then log in as a new, a mid-course and a finished customer to confirm each sees what they paid for. Send your announcement only after that check passes.
Do I have to pay a monthly fee on BibliOWLteca?
No. BibliOWLteca charges no monthly fee. It takes a percentage and a fixed fee from each sale completed through its checkout, with the transaction fee shown on the pricing page from €0.99. Buyers pay no platform fee.
Sources
- LMS migration framework: when to leave and how long it takes
- How to back up and export your online course content
- Why a full migration from Teachable is not possible through its API
- A staged LMS migration approach
- Leaving Teachable: a migration checklist
- Teachable to WordPress migration playbook
- Course creator year in review: moving 30+ courses in 2025