Migration rule
Do not cancel the old platform until access, money, email, and URLs are proven on the new one
Run a pilot with real product types and test learners, freeze content changes, cut over in a controlled window, and keep a rollback path. The highest-risk items are recurring billing, learner entitlements, progress history, email consent, domain changes, and public redirects.
Kajabi billing exit
Account cancellation does not cancel customer billing
Kajabi's cancellation policy says subscriptions and payment plans keep charging until individually canceled. Platform services end after the billing cycle; limited payment-management access is not learner access. Record the intended service and billing outcome for each customer before canceling the platform.
A separate Stripe-to-Kajabi-Payments migration is not a whole-LMS transfer or an Offer setting. Reconcile skipped records, next charge dates and remaining installments. PayPal subscriptions are excluded; do not assume a recreated checkout prevents duplicate billing. Read the payout and existing-subscription checks. This October 5 public-document review is not an account action or full pricing audit.
Teachable plan exit
Inventory access before reducing the old school plan
A lower plan can automatically unpublish excess products at renewal. Teachable's public guides disagree about existing learner access after unpublishing; hiding a catalog card does not remove a published product from its allowance. Review the plan-reduction evidence and source conflict before relying on a cheaper overlap period.
Keep a manual record of the effective date, product status and learner commitments. Cancellation takes the school offline under the plan-change guide; do not use it as an assumed archive. This October 5 source review is not a downgrade, cancellation, account test or guarantee of access.
Phase 1 · Inventory
Build a source-of-truth migration workbook
| Inventory | Export or record | Acceptance rule |
|---|---|---|
| Products | Courses, bundles, downloads, coaching, community, memberships, prices, coupons, access duration | Every sellable and free offer has an owner and destination |
| Content | Video masters, captions, audio, PDFs, text, quizzes, assignments, certificates, drip rules | Files are locally backed up and rights are documented |
| People | Students, admins, authors, affiliates, consent, tags, enrollments, progress, completions | Counts reconcile by product and status |
| Money | Orders, invoices, subscriptions, payment plans, refunds, disputes, taxes, payouts | Finance can reconcile before and after cutover |
| Marketing | Forms, segments, sequences, broadcasts, automations, attribution, pixels, affiliates | Every revenue or onboarding flow has a migration owner |
| Public web | URLs, titles, descriptions, canonicals, schema, links, sitemap, backlinks, analytics | Every indexed URL has a keep, redirect, or retire decision |
Verified import boundaries
A student import is not a subscription or progress transfer
These specific workflows were checked against official documentation on October 4, 2026. They are not promises that every vendor service or account has the same scope. Test the intended plan and obtain a written list of transferred fields before committing.
| Workflow | Documented scope | Separate acceptance check |
|---|---|---|
| Podia product migration | Paid-plan service: Mover up to 50 products/500 videos; Shaker 150/1,000; Earthquaker 150/unlimited videos. Courses and downloads are covered, not quizzes/tests, pipelines or site pages as a standard service. | Customers are imported separately. Existing payment plans, subscriptions and payment details do not transfer. Verify every lesson file: inaccessible content may be replaced by a placeholder. See Podia's migration scope. |
| Thinkific assisted migration import | Student and enrollment records are separate sheets. Existing partial progress is not imported; completion can be recorded as 0% or 100%. Activation and expiry dates control different access rules. | Archive partial-progress evidence and tell learners the destination policy. Completion does not automatically expire access. Imported enrollments do not trigger the ordinary Zapier enrollment workflow. See Thinkific's assisted import instructions. |
| Thinkific Smart Importer | A distinct self-service workflow supports up to 50,000 users and optional enrollment; the assisted workflow is described as 5,000 at a time with up to five business days of lead time. | The Smart Importer documentation carries a maintenance/access warning. Confirm access on the qualified plan; do not assume the two tools transfer identical fields. See Smart Importer's current requirements. |
| Teachable CSV bulk importer | Growth or higher. Creating a school account does not automatically enroll it in a product; product enrollment is an explicit choice. The documented coaching/bundle import maximum is 1,000 students at once. | Keep email consent independent of access. Leave password fields blank for the supported account-confirmation flow, rather than sharing passwords. Check imported-student usage costs as well as the official importer instructions. |
A content-migration allowance is not a permanent product/storage allowance. Vendor scope, queue, source-file access and destination-plan limits still need independent checks. No learner records or payment accounts are changed by this guide.
Phase 2 · Contract and payment check
Resolve recurring billing before building pages
- Read cancellation, export, data retention, domain, and refund terms for the old platform.
- Ask whether payment tokens and active subscriptions can transfer, who owns the merchant account, and which approvals are required.
- Document plans that cannot migrate: grandfathered pricing, installments, coupons, tax settings, multiple currencies, PayPal agreements, app-store purchases, or marketplace orders.
- Choose a customer path for each exception: preserve, recreate with consent, continue billing on the old system, or end and invite re-purchase.
- Confirm the new gateway, business country, verification, settlement currency, reserve, payout, tax, refund, and chargeback route with a real test transaction.
Never collect or transfer card details manually. Billing credentials are regulated data handled by approved platforms and processors.
Recurring-payment boundary
Moving saved cards does not rebuild the billing schedule
Stripe's processor-migration guide separates secure customer/payment-data transfer from subscription import and integration mapping. Record which system owns the next charge, billing date, remaining installments, currency and cancellation state. After the approved transition, verify that the old route will not also charge the customer. Do not send card numbers or sensitive customer data in ordinary email or a course-import CSV.
A same-school payment switch is a different case. Thinkific documents a 30–60-day migration for eligible existing Stripe recurring payments into Thinkific Payments. Keep Stripe connected until that migration succeeds; account/status conditions apply. This is not evidence that subscriptions can move automatically from another LMS. The specific Thinkific migration guide also warns that migrated subscriptions cannot simply be bulk re-imported into Stripe. A rollback document alone does not make an irreversible billing change reversible.
Phase 3 · Rebuild and map
Create one-to-one maps before importing
Product map
- Old product and price → new product and price.
- Old enrollment rule → new access rule.
- Old completion requirement → new requirement.
- Old certificate → new or archived certificate.
User map
- Old user ID → email and new user ID.
- Enrollment, expiration, progress, completion, certificate.
- Subscription, coupon, payment plan, refund status.
- Email consent, tags, community role, support notes.
URL map
- Old public URL → retained URL or 301 destination.
- Page title, description, canonical, headings, schema.
- Internal links, downloadable assets, images, embeds.
- Backlinks and campaign URLs worth updating.
Automation map
- Trigger → conditions → action → delay → exit.
- Sender identity, template, consent, suppression.
- Purchase, failed payment, completion, cancellation.
- Analytics event and owner for failure alerts.
Phase 4 · Pilot
Migrate one representative product end to end
- Select a product with video, captions, download, quiz, drip, certificate, coupon, payment plan, email onboarding, and community access.
- Import a small group containing a new student, active learner, completed learner, expired learner, refunded buyer, and subscription customer.
- Test desktop and mobile as each role; compare access, progress, emails, receipts, tax, community, certificate, and support history.
- Run purchase, failed payment, refund, cancellation, reactivation, and payout reconciliation.
- Record every manual repair and multiply it by the full catalog and user count.
- Obtain written sign-off from content, finance, support, marketing, and the business owner.
Phase 5 · SEO and domain cutover
Choose the URL strategy before changing the host
| Move type | Action | Acceptance evidence |
|---|---|---|
| Same public URLs, different hosting | Serve the same pages/assets, retain HTTPS, canonical URLs and Search Console verification. Do not create redirects from a URL to itself. | Compare status/content on the new host and monitor both delivery paths until the old one is unused. Use Google's hosting-only guidance. |
| Domain, subdomain or path changes | Map each moved page to its equivalent and use direct server-side permanent 301/308 redirects. Update internal links, canonicals and the sitemap. Change of Address applies to domain/subdomain moves, not hosting-only, path-only, HTTP-to-HTTPS or www/non-www changes. | Test the old URL, final destination and response code. Google generally recommends redirects for at least one year; useful external links may justify longer. See Google's URL-changing move guidance. |
| Retired content with no equivalent | Return a genuine 404/410 rather than redirecting everything to an unrelated homepage. | Keep an intentional-retirement list separate from broken pages; monitor crawl errors and priority destinations after launch. |
A move can temporarily affect crawling or rankings. A sitemap or redirect is not a guarantee of indexing or unchanged traffic. Keep staging blocked from indexing, then remove only the intended production blocks at launch.
Phase 6 · Communication and support
Tell each customer exactly what changes for them
- Announce the reason, cutover window, new login URL, password process, mobile app, saved progress policy, billing status, and support channel.
- Segment instructions for active students, completed alumni, subscribers, expired users, affiliates, instructors, and administrators.
- Create screenshots and a two-minute walkthrough of first login and content access.
- Staff support for the first 72 hours and tag migration issues separately from ordinary questions.
- Never ask users to send passwords, full card numbers, identity documents, or one-time codes by email.
Go-live gate
All 15 conditions should be true
- Catalog counts reconcile.
- User and enrollment counts reconcile.
- Active access is correct.
- Progress policy is implemented.
- Certificates are preserved or replaced.
- Subscriptions have an approved path.
- Purchases, refunds, and payouts reconcile.
- Email consent and suppression migrated.
- Automations passed test events.
- Priority pages retain metadata.
- Redirects return the intended destinations.
- Analytics records real-time tests.
- Support instructions are ready.
- Backups and exports are stored securely.
- Rollback ownership and deadline are documented.
After launch
Limit old-system changes without stopping required billing
Freeze editorial/admin changes where the platform permits, but do not disable a processor or recurring route still needed for existing customers. Monitor daily for at least the first week, then weekly through one billing cycle. Compare sales, payouts, refunds, failed payments, login failures, content errors, email delivery, course completion, support volume, crawl errors, and search traffic. Cancel the old platform only after the retention period, approved billing transition, legal needs, export verification and rollback limits are satisfied.
Frequently asked
Migration questions
Should I migrate all courses at once?
Usually not before a representative pilot. A phased migration reduces risk, but active subscriptions, shared community, and one domain can make split operation complex. Choose the sequence from dependencies.
Can a vendor migration service do everything?
Vendor services often move selected content and customer records, not every automation, URL, progress field, subscription, tax record, integration, or support history. Obtain a written in-scope list.
When can I cancel the old platform?
After data retention, active access, billing, finance reconciliation, redirects, support, legal records, and rollback requirements are satisfied—not immediately after DNS changes.
What should be backed up?
Original content files, captions, course structure, users, enrollments, progress, certificates, orders, subscriptions, refunds, tax records, consent, automations, URLs, metadata, analytics, and configuration evidence.
Primary references
Plan redirects and payment data against authoritative guidance
This checklist is operational guidance, not legal, tax, or payment-security advice. Confirm regulated-data and contract questions with qualified professionals and providers.