Switching LMS Shouldn’t Mean Starting Over

You’ve already built the thing that matters most: the curriculum. Months, maybe years, of lessons written, videos recorded, quizzes tuned against real student mistakes. The platform underneath it is just where that work happens to live right now, and the moment a platform migration means rebuilding all of it from scratch, “just where it lives” becomes the single biggest reason people stay somewhere they’ve already decided to leave.

This is the quiet tax that keeps course creators locked into a plugin they’ve outgrown. Not because the alternative is worse, but because the cost of moving looks like starting over, and starting over on a catalog that took a year to build isn’t a weekend project, it’s a reason to just keep paying for the thing you don’t like.

We’re going to look at the actual, real migration tool built into Learnomy, not a description of what an import feature theoretically could do, but the real wizard, screenshotted from a working install, plus the specific safety mechanics the code implements underneath it.

Switching costs are usually discussed as a pricing or feature conversation, is the new platform cheaper, does it have the feature I need. Migration risk rarely gets the same scrutiny, even though it’s frequently the actual deciding factor. A course creator who’s convinced a different platform is objectively better will still stay put if moving means re-typing every quiz question by hand, re-uploading every lesson video, and rebuilding a course structure that took real thought to get right the first time. The switching cost isn’t the new platform’s price tag, it’s the labor of reconstruction. A migration tool that removes that labor is what actually unlocks the decision, not the feature comparison that convinced you to consider leaving in the first place.

Why “just export and import” almost never works cleanly

Every LMS plugin stores its content differently enough that a naive export/import breaks something. Course structure that’s flat in one system and nested in another. Quiz question types that don’t map one-to-one, a fill-in-the-blank question in one plugin might have no direct equivalent in another. Media attachments referenced by internal IDs that mean nothing once they’re detached from the original plugin’s database tables.

The two failure modes that actually cost people money are worse than “the formatting looks a little off.” The first is a migration that touches things it shouldn’t, pricing, active subscriptions, an order history, and creates a billing mess on top of a content mess. The second is a migration with no way back: you run it, something’s wrong, and there’s no clean path to undo it and try again without manually deleting whatever got created.

Any migration tool that doesn’t explicitly solve both of those problems is asking you to trust it blind, on a dataset you can’t afford to lose.

The actual wizard, as it renders on a live site

Here’s the real Learnomy import screen, captured from the LMS Settings menu on a working install, not a mockup.

Two things stand out immediately, and both are answers to the failure modes above.

First, the subtitle spells out the boundary in plain language, right under the page title: “Bring courses, lessons, and quizzes from LearnDash, Tutor LMS, or LifterLMS into Learnomy. Content only. Your prices, orders, and payments are never touched.” That’s not a vague reassurance, “content only” is a specific, checkable claim about what this tool will and won’t reach into. Whatever pricing, orders, and payment records exist in your current LMS stay exactly where they are, untouched by anything this wizard does.

Second, look at the source selection step itself: “Only plugins that are active here and have content appear as selectable.” On this particular install, none of LearnDash, Tutor LMS, or LifterLMS are installed, so all three show “Not detected on this site” and can’t be clicked, which is exactly correct behavior. The wizard isn’t going to let you attempt an import from a plugin that isn’t actually present with real content to pull from. That’s a small detail, but it’s the kind of guardrail that prevents a confusing half-completed migration attempt before it can even start.

The four-step structure across the top, Source, Content, Review, Import, tells you the shape of the whole process before you commit to anything: pick where you’re migrating from, choose what content to bring over, review exactly what’s about to happen, and only then actually run it. Nothing about that sequence lets you skip straight to “Import” without passing through a review step first.

What actually happens at the Review step, and why it matters more than the import itself

The code backing this wizard implements what it calls a dry run, a preview() method that runs before anything is written to your database, calculating counts per entity (how many courses, how many lessons, how many quizzes it found) and surfacing specific warnings, like question types that don’t have a clean mapping into Learnomy’s own question format. This is the mechanism behind the Review step: you see exactly what’s about to be created, and exactly what might come across imperfectly, before you click the button that actually creates anything.

This matters because a warning surfaced before an import is a decision point; the same warning surfaced after is a cleanup job. If a LearnDash-specific question type has no clean equivalent, seeing that on the Review screen means you can decide, skip that quiz, import it and fix the one question type manually afterward, or hold off entirely until you understand the gap better. Finding out only after 40 quizzes have already imported with garbled questions is a very different, much worse conversation.

The engineering notes behind this preview step describe exactly why it exists in this specific form: the same “not migrated” list, the set of things the tool knows it can’t bring across, is shown on both the dry-run review step and again after the import actually runs, specifically so that, in the plugin’s own words, “anyone who clicked through the preview finished the import believing” they knew exactly what they were getting, with no gap between what was promised and what was delivered.

The boundary that protects your revenue

The single most consequential design decision in this whole system is the one stated plainly in that first screenshot: money is out of scope, categorically. Not “we try to migrate pricing carefully”, pricing isn’t touched at all. The plugin’s own code comment makes this explicit: “Payments, pricing, coupons, and orders are never touched. Imported courses are free; money stays in your existing system.”

Think through why that’s the right call, not a limitation. Pricing models, coupon logic, active subscriptions, and payment gateway configurations are the single riskiest thing to migrate automatically between two different commerce systems that don’t share a data model. A subtle mismatch there doesn’t just look wrong on a page, it can double-charge a customer, silently drop an active subscription, or misrepresent what a student already paid for. By drawing the line at “content only” and refusing to touch anything financial, the migration tool sidesteps an entire category of expensive, hard-to-detect failure. Every course that comes across through this wizard lands as free content in Learnomy; you set up pricing fresh, deliberately, using the pricing models and commission structure covered elsewhere in this series, not as a byproduct of an automated cross-system translation you’d have to audit line by line to trust.

This is also, not incidentally, the safer legal posture. An import tool that doesn’t touch your existing payment processor, your existing subscriptions, or your existing order records can’t accidentally create a compliance problem around stored payment data or duplicate billing. It genuinely only moves the parts of your business that are safe to move automatically: the teaching material itself.

Undo: the safety net that makes trying it low-risk

The system’s engineering notes mention undo functionality built alongside preview, using the same underlying data the review step already generates. That’s a deliberate design choice worth calling out on its own: a migration tool that can only move forward, with no way to reverse a completed import, forces you to be certain before you start. A migration tool with a real undo path lets you actually run it, look at the result on the new platform with real content in place, and back out cleanly if something isn’t right, rather than needing to be perfectly confident in a dry-run preview alone.

That distinction matters because a preview, however thorough, is still a prediction. Seeing your actual imported courses rendered in the real curriculum builder, with real lesson content, is a more trustworthy check than reading a summary of what would happen. Undo is what makes it safe to prefer that stronger check over trusting the preview blind.

How undo actually works, and why re-running isn’t dangerous

It’s worth being specific about the mechanism behind that undo capability, because “there’s an undo button” and “undo is actually safe to rely on” are different claims, and only the second one is worth trusting with a real catalog.

Every entity the migration creates, each course, each lesson, each quiz, gets a tracking record that maps the source plugin’s ID for that item to the new Learnomy ID it was given, tagged with the specific migration run that created it. That mapping is what makes three things possible at once, each solving a distinct real-world problem.

Undo deletes exactly what a run created, nothing else. Because every created entity is tagged with its run, reversing a migration means deleting precisely those tagged entities, not a broad “delete everything imported ever” operation that might catch content you’ve since edited and want to keep, and not a guess based on timestamps or naming patterns that could misfire.

Re-running an import after a partial failure doesn’t create duplicates. If a migration run gets interrupted, or you deliberately import a course again after fixing something on the source side, the system resolves each item against its existing mapping before creating anything new. Content that’s already been imported gets updated in place instead of duplicated. This is what makes “something went wrong halfway through, let me just run it again” a safe instinct instead of a way to end up with two copies of the same course.

Parent-child relationships resolve correctly even across separate steps. A lesson references its parent course by the source plugin’s ID; the mapping is what lets the migration correctly attach that lesson to the new Learnomy course it just created, rather than losing the relationship or attaching it to the wrong parent entirely.

None of this is visible in the wizard itself, it’s infrastructure sitting underneath the Review and Import steps you actually click through. But it’s the specific reason a “try it, check the result, undo if needed” workflow is a genuinely safe way to approach a migration, rather than an optimistic-sounding feature that falls apart the first time something needs a second attempt.

Three real migration scenarios

The solo instructor who’s simply outgrown their old plugin. For this person, the whole migration is one sitting: pick the source, review a manageable set of courses, import, and spend an afternoon manually setting up pricing on the handful of courses that matter most. The dry-run preview is mostly a sanity check here, confirmation that the numbers on the Review screen match what they expect from their own small catalog.

The agency migrating a client’s site as part of a larger rebuild. Here, the CLI command matters as much as the visual wizard. An agency handling this as one step in a broader migration project wants it scriptable, repeatable, and safe to run against a staging copy first, exactly what wp learnomy migrate provides, with the same content-only, undo-capable guarantees as the admin wizard. Testing on staging, confirming the Review step’s warnings are all accounted for, then running the same command against production, is a workflow this tool was clearly built to support.

The site with an unusually large or unusual catalog. This is where the warnings on the Review step earn their keep. A catalog with heavy use of a source plugin’s more exotic quiz question types, or deeply nested course structures, is exactly the case where “some things migrate imperfectly” is likely to actually apply. For this site, the right approach is patience at the Review step: read every warning, decide case by case whether to proceed, exclude, or handle a specific course manually, rather than treating the Review screen as a formality to click through quickly.

Common questions before you migrate

Will my students lose access to courses they’re already enrolled in? No, enrollment is one of the entities this tool explicitly migrates, along with each student’s progress, preserving their original enrollment and completion dates rather than resetting them. Your source platform is never written to during this process (only ever read from), so it keeps functioning exactly as it did before, for as long as you choose to keep it running alongside the new one.

Can I import a subset of my catalog instead of everything at once? The wizard’s Content step exists specifically to let you choose what to bring across, rather than forcing an all-or-nothing import. That makes a phased migration, start with your best-selling courses, confirm they look right, then bring over the rest, a realistic approach rather than a single high-stakes event.

What happens to quizzes with question types Learnomy doesn’t have a direct equivalent for? These are exactly what the Review step’s warnings are built to surface before you commit. You’ll see which quizzes have a mapping concern, and you can decide whether to import and manually adjust those specific questions afterward, or hold that quiz back until you’re ready to rebuild it directly in Learnomy’s own quiz builder.

Is it safe to run the import more than once if something looks wrong the first time? Yes, and this is a deliberate design property, not an accident, the underlying ID-mapping system resolves existing entities before creating new ones, so a second run against the same source updates what’s already there instead of duplicating it. Combined with undo, this means your realistic options if something looks off are: undo and start clean, or re-run to fix a partial result, whichever fits the specific problem better.

Do I need developer help to run this? No, the visual wizard is built for a site owner to use directly, with plain-language explanations at every step. Developer involvement becomes useful specifically for the CLI path (useful for staging-to-production workflows or scripted migrations) or for manually resolving a flagged quiz question that needs custom handling, not for the migration process as a whole.

Command-line access for anyone who’d rather script it

Everything described above is also available outside the visual wizard, through wp learnomy migrate , a WP-CLI command explicitly documented as dry-run/import capable, and explicitly documented with the same two guarantees as the UI: it never writes to the source plugin’s data, and it never touches money. For a developer or an agency handling a client migration, that means the exact same safety boundary applies whether the actual button-clicking happens in wp-admin or in a terminal running as part of a larger, scripted site-migration process. Neither path is a lesser or riskier version of the other, they’re two interfaces onto the same underlying, audited migration engine.

What actually comes across, and what doesn’t

This is where the tool is more capable than “content only” might suggest at first read, and it’s worth being precise rather than approximate about the boundary. Course structure (sections and their nesting), lessons and their content, and quizzes including their questions all migrate, with the explicit caveat, surfaced directly to you at the Review step, that some question types may not have a clean one-to-one mapping and will be flagged rather than silently mangled.

Enrollment migrates too, and not as a bare access flag, the tool preserves the actual historical date a student enrolled, so an import doesn’t make every learner look like they joined on migration day. Progress migrates the same way: per-lesson completion carries over, and a student who’d already finished the course arrives in Learnomy already marked complete, with their original completion date backfilled rather than reset to “just enrolled.” Re-running the import against the same student and course updates that record instead of duplicating it, using the same idempotent mapping covered above.

Two specific things are deliberately left behind, and the code is explicit about why. Certificates aren’t migrated, a certificate design lives in the source plugin’s own template, background image, and shortcodes, and there’s no faithful way to carry that over as-is. Instead, you pick a Learnomy certificate template after importing, and every completion from that point forward, including the historical completions that just got backfilled, issues a certificate from the new template. Quiz attempt scores aren’t reconstructed, a learner who passed a quiz is marked complete, but the per-question score detail behind that pass isn’t carried over. You get the pass/fail outcome, not a reconstructed gradebook history.

And, as covered above, anything financial stays out of scope entirely: no pricing, no coupons, no order history, no active subscriptions. That boundary is about risk, not capability, the tool could theoretically attempt a cross-system pricing translation, but a subtle mismatch there is expensive and hard to detect, while course structure, enrollment, and progress are comparatively safe, well-understood data to move automatically.

What to actually check if you’re planning a real migration

If you’re seriously weighing a move off LearnDash, Tutor LMS, or LifterLMS, here’s what’s worth verifying directly rather than assuming:

• Run the Source step and confirm detection. If the wizard reports your current LMS as “Not detected,” that’s worth resolving before you plan a migration date around it, check that the plugin is active and has actual content for the connector to find.
• Read every warning on the Review step before importing anything. The “not migrated” list and any question-type warnings are the tool telling you exactly where manual follow-up will be needed. Budget time for those specific items rather than discovering them after the fact.
• Plan your pricing setup as a separate, deliberate step, not an afterthought. Courses land as free content with existing enrollments and progress already carried over, what needs deciding fresh is the pricing model and commission structure for new sales going forward, before you announce the new platform to anyone.
• Pick your certificate templates before your first real completion fires. Since historical completions get backfilled during import, a student who already finished a course under the old platform can trigger a certificate issue on the new one the moment their record lands, have a template chosen so that isn’t a blank or default design.
• Test undo on a low-stakes course first, if you’re not yet confident in the preview. Import one course, look at it rendered in the real curriculum builder, and confirm you’re comfortable with the fidelity before committing your full catalog.

None of this requires trusting a claim you can’t verify yourself. The Source step either detects your current plugin or it doesn’t. The Review step either shows accurate counts and warnings or it doesn’t. The “content only” boundary either holds, your existing pricing and orders staying completely untouched, or it doesn’t. Every one of those is something you can check directly on your own install before you commit a real catalog to the move.

What a well-built migration tool says about the platform underneath it

There’s a broader signal worth reading here, beyond the migration feature itself. Building a genuine dry-run preview, an accurate “not migrated” disclosure shown both before and after the fact, an ID-mapping system that makes undo and safe re-runs possible, and a scriptable CLI equivalent of the same guarantees, none of that is a quick feature to bolt on. It’s the kind of thing a team builds when they’ve actually thought through what goes wrong in a real migration, not just what a migration looks like in a two-minute product demo.

That’s relevant to you even beyond the immediate question of moving your catalog. A platform that treats “what happens when this fails partway through” as a first-class design question for its migration tool is likely to bring the same discipline to the features you’ll depend on every day after you’ve switched, the commission math covered elsewhere in this series, the offline sync your mobile students rely on, the course builder your co-instructors will use without training. A careful migration tool isn’t just how you get in the door. It’s a preview of how carefully everything else was built.

The actual decision in front of you

If you’ve been putting off a platform switch specifically because of the rebuild cost, the honest question to answer isn’t “is the new platform better”, you’ve likely already answered that for yourself, or you wouldn’t be evaluating a migration tool in the first place. The real question is narrower and more answerable: does this specific migration path handle your specific catalog correctly, and can you verify that before you’re committed?

That’s a question with a concrete, low-risk way to answer it. Run the Source step against a staging copy of your site. Walk through Content and Review with your actual catalog, and read every warning the tool surfaces rather than skimming past them. If the counts match what you expect and the warnings are ones you can live with or plan around, you’ve de-risked the decision using your own real data, not a vendor’s claim about how smooth the process will be. And if something looks wrong, you’ve learned that on a staging copy, with your production site and your existing platform completely untouched, which is precisely the point of building undo and a content-only boundary into the tool in the first place.

The work you already did, the courses, the lessons, the quizzes tuned against real student answers, doesn’t have to be redone because the platform underneath it changed. That was always supposed to be the whole promise of migration tooling. This is what it actually looks like when a plugin builds that promise all the way through, instead of stopping at “we support importing from LearnDash” on a features page and leaving the hard parts for you to discover after you’ve already committed.