Kajabi Skills
Kajabi to Kajabi Migration
Move your entire Kajabi business to another account cleanly, without losing customer access or interrupting active billing.
Moving within one Kajabi account is easy. Moving between two separate accounts is deceptively hard: native duplication doesn't cross account boundaries, and exports only capture templates, not your full course content, your customers, your offers, or their access. I run migrations as a controlled, phased project. Inventory first, then content, commercial config, automations, members, and active subscriptions, then a tested cutover. Nothing critical gets lost, and I tell you up front what Kajabi genuinely can't carry across.
Book a Discovery CallThe Problem
Kajabi makes moving within a single account simple. You can move a product from one site to another, duplicate a course, even move individual lessons and mix and match. If both sites live under the same Kajabi account, most of a migration is a few clicks.
Moving between two separate Kajabi accounts is a different job entirely, and Kajabi does not make it obvious how different. Native duplication does not cross account boundaries. The export feature looks like a safety net, but it mostly captures the course template and the presentation layer, not the complete course content, and it does not touch customers, offers, member access, automations, or active subscriptions. So the moment your destination is a separate account (a partnership you are joining, a higher tier that lives under someone else's account, a business you are splitting off or consolidating), you no longer have a duplication task. You have a full migration.
Most people quoting a Kajabi migration price it by counting courses. That is the wrong unit, and it is how migrations go wrong. Thirteen courses with a hundred simple lessons is a completely different migration from thirteen courses with eight hundred media-heavy lessons, sixty offers, active recurring subscriptions, and fifty automations. The real work is driven by total volume and complexity across every dimension at once: modules, lessons, videos, downloads, offers, payment plans, automations, forms, email sequences, members, product access, and active billing. Quote by course count and you either overcharge simple migrations or badly under-scope complex ones.
And then there is the part nobody wants to discover after they have paid: some things cannot be migrated at all. Passwords cannot transfer. Lesson-by-lesson learner progress cannot be restored into a new account. Coupon-usage history and some backend customer relationships do not survive. Historical transactions, email analytics, and quiz records stay in the source account. If a migration is sold to you without those limits stated up front, the disappointment (and the scope dispute) arrives at the worst possible moment: cutover.
What This Service Delivers
I move your Kajabi business from one account to another as a controlled, phased project. The default case this service is built around is the hard one: source and destination in two separate Kajabi accounts, often on different pricing tiers and a different domain. Because native duplication cannot cross account boundaries, the work is a genuine migration rather than a copy, and it is sequenced deliberately to keep your live business running while it happens. It covers the full range of Kajabi product types, not just courses: courses, coaching products, communities, podcasts, downloads, and newsletters all move as part of the same engagement.
The migration runs in six phases: validation and inventory, course and product content, pages and commercial configuration, automations and communications, members and active subscriptions, then a tested production cutover with a one-month stabilisation window afterwards. The phases exist to reduce risk and give you validation points between stages, so content that is still changing in your live site can be scheduled close to cutover rather than migrated twice. The order is deliberate: everything that can be built and validated ahead of time is, so the final cutover (members, access, active billing, domain) is a tight, tested window rather than a leap. A typical separate-account migration runs around six weeks of delivery from start to cutover, with several phases overlapping where it makes sense, followed by the 30-day stabilisation window. Same-account moves are shorter. The exact schedule is confirmed after the Phase 1 inventory, and where a later cutover date suits your business, the preparatory phases can be completed in advance and the final member, subscription, and domain transition scheduled closer to that date.
This service is about faithful transfer, not redesign. I move what you have as it is. If you also want things improved during the move (pages rebuilt better, your subscription and automation setup redesigned, your email deliverability and DNS properly rebuilt), those are separate services that can run alongside the migration, and I flag them in the scope boundary below rather than quietly folding their cost in here.
Same-account, site-to-site moves are also possible and are a faster, lower-cost variant of this service. When both sites live under one Kajabi account, much of the heavy lifting Kajabi handles natively, so the engagement is smaller. If that is your situation, say so on the discovery call and the scope and quote adjust accordingly.
What a Kajabi migration genuinely cannot preserve (and I tell you before you commit):
- Passwords. They cannot be exported or transferred. Migrated members use a password-reset or account-setup flow on the destination site, supported by a short customer communication.
- Lesson-by-lesson learner progress. It cannot be restored into a new account. Members keep access to the same products, but progress indicators start fresh. A historical progress report can be preserved for reference if needed.
- Coupon-usage history and some backend customer relationships. These live in Kajabi's own database, not in anything exportable, so some historical filters may not survive. Tags and product access are preserved.
- Complete course content via export. Kajabi's export captures the template and presentation layer, not the full content, so course content is rebuilt in the destination and validated, not simply exported and re-imported.
- Historical records. Past transaction records, email-performance analytics, and quiz or assessment history remain in the source account and are not reconstructed in the destination.
Stating these limits up front is the point. A migration sold without them is a migration that disappoints at cutover. Everything on that list can be handled with an agreed approach; what matters is agreeing the approach before the work starts, not discovering the limit after.
What is not included in this service (each has a natural home elsewhere): full email deliverability and DNS rebuild with SPF, DKIM, DMARC, and CDN work is the Kajabi Domain, Email & CDN Setup service (this migration includes only the domain and DNS cutover coordination needed to point your existing domain at the new site). Redesigning or rebuilding pages rather than moving them as-is is the Custom Kajabi Website Design & Build service. Redesigning your subscription and automation architecture rather than reproducing what exists is the Kajabi Subscription & Automation Engine service. Also excluded: migration into Kajabi from another platform (Squarespace, WordPress, Webflow and similar), which is a different kind of project and a different conversation; creation of new content; historical-data reconstruction; and ongoing platform administration beyond the stabilisation window.
One responsibility stays with you: because a migration moves your members' personal data between accounts, you confirm that you are authorised to provide access to that data and to instruct its migration. You remain the data controller for your customer records throughout; I handle them only to carry out the agreed migration. If your source or destination account is owned by a partner or a collaboration, that authorisation and the account access it requires are confirmed during Phase 1.
Frequently Asked Questions
It is the single biggest factor in how much work a migration is. If both sites live under one Kajabi account, Kajabi lets you move products, duplicate courses, and even move individual lessons natively, so most of the heavy lifting is done for you and the engagement is small. If the destination is a separate Kajabi account, none of that native movement works across the account boundary. Duplication does not cross accounts, and exports only capture the template, not the full content, the customers, the offers, or the access. That turns the job into a full, phased migration where content is rebuilt and validated, members and access are recreated, and active billing is transitioned deliberately.
This service is built around the separate-account case because that is where the work and the risk are. If your move is same-account, it is a faster, lower-cost variant, and the scope and quote adjust accordingly. Either way, Phase 1 confirms which situation you are in before any pricing is fixed.
No. Preserving product access is a core objective of the migration. Your members are migrated to the destination account with the same product-access relationships they had before, and that access is validated against representative accounts during the members phase and again at cutover. What does change is login: passwords cannot be transferred between accounts, so members complete a password-reset or account-setup step on the destination site. That transition is planned in advance and supported by a short customer communication, so it is a smooth onboarding moment rather than a surprise.
Active subscriptions are the most delicate part of any migration, and they are handled deliberately rather than assumed. Each active subscriber sits at a different point in their billing cycle: someone who subscribed a month ago is due at a different time from someone who subscribed nine months ago. The transition is planned so the next payment aligns with when it was actually due, using a technically supported and mutually agreed approach, so nobody is double-charged and no billing cycle is interrupted. Any subscription case that needs customer-specific handling is identified in advance during the members-and-subscriptions phase, not discovered at cutover. Where an exact automated transition is not technically possible, we agree a clean alternative together before anything is executed.
Lesson-by-lesson completion cannot be restored into a separate Kajabi account. Progress can be exported as a product-level record, but Kajabi does not provide a way to import and rebuild granular completion state in a new account. In practice this matters less than it sounds for most course businesses, because members keep full access to the same products and can pick up where they left off; the progress indicator simply starts fresh. If a historical progress record matters to you for audit or reference, it can be preserved as a report. What is not possible is making the destination account show each member's exact prior completion state, and that is agreed up front rather than promised and missed.
No. Passwords cannot be exported or transferred between Kajabi accounts; this is a platform limitation, not a scoping choice. Migrated members use the destination site's password-reset or account-setup process to log in for the first time. This is planned as a small, supported migration moment: a clear customer communication explaining the one-time step, timed around cutover. It is routine, and handled so it does not generate a wave of confused support requests.
The source account needs to remain available and active until the migration is complete and accepted. The phased approach is designed around this: everything that can be built and validated ahead of time is, while the source stays live and your business keeps running, and only the final cutover (members, access, active billing, domain) happens in a tight window. Content that is still actively changing in the source is migrated close to the cutover date to avoid migrating it twice. Decommissioning, deleting, or downgrading the source account after cutover is a separate decision you make on your own timeline; it is not part of this service unless you specifically ask for help with it.
Not through this service. This is a Kajabi-to-Kajabi migration, and the phases, tooling, and risk model are built specifically for moving between Kajabi accounts. Migrating into Kajabi from another platform (Squarespace, WordPress, Webflow, Teachable, and similar) is a different kind of project: the source structures do not map cleanly to Kajabi's products, offers, and automations, and much of the work is rebuild rather than transfer. That can absolutely be done, but it is a separate conversation with its own scope. If that is what you need, mention it on the discovery call and we will talk about how it would work.
There is a brief, planned period of downtime around the domain switch, because DNS changes take time to propagate across the internet. It is scheduled for a low-traffic window and communicated in advance, and it is short: most visitors never notice. The rest of the migration happens on the destination account while your live site keeps running, so the only real exposure is that narrow cutover window.
The cutover runs to an agreed plan rather than on the day's improvisation. Before the switch, there is a short content freeze on the source so nothing changes mid-move, a defined migration window, and customer communications prepared in advance. If something needs to be reversed, there is a rollback position: because the source account stays live and intact until the migration is complete and accepted, the fallback is simply to keep pointing at the source while the issue is resolved, rather than being stranded on a half-migrated destination. Nothing is deleted from the source as part of this service.
Phase 1 exists precisely to make the quote accurate, so the fixed price follows the confirmed inventory rather than a guess. The things that can move a quote are the things Phase 1 is designed to surface: a materially larger volume than the initial discovery suggested (many more lessons, media files, offers, or automations than expected), previously unidentified backend configuration or custom code, source media that no longer exists outside Kajabi and needs recovery, or a decision to bring additional work into scope (redesigning pages rather than moving them, rebuilding subscription architecture, or a full email and DNS rebuild, each of which is a separate service). If anything material emerges, it is discussed and agreed before additional work happens. Normal migration adjustments that stay within the agreed outcomes are not treated as scope changes.
Ready to plan your Kajabi migration?
No commitment. We will talk through your source and destination accounts, what needs to move, and where the real risks are, so you get an accurate picture before anything begins.
Book a Discovery Call