Moving from Mindbody, Kajabi or Uscreen to your own app: 2026 guide

TL;DR

Moving from Mindbody, Kajabi or Uscreen to your own app in 2026 is a data and billing project first and a software project second. Three assets decide whether your members follow you: the client records, the stored payment cards, and the app record in the App Store and Google Play. Each platform releases them differently, and the order in which you claim them sets your churn. Stored cards move only between PCI DSS Level 1 processors, and 31% of Google Play subscription cancellations are billing failures, so the payment migration is the retention plan.

• Mindbody exports client contacts, purchases, memberships and visits as CSV, and sells a data export service for up to 30 days after cancellation.
• Kajabi exports contacts as CSV, but under Kajabi Payments you do not hold the Stripe account the cards sit in.
• Uscreen publishes apps under your developer accounts and keeps the app code as its own property.

The platform stops fitting before it stops working

Nobody leaves a platform on the day it breaks. They leave when the workarounds start costing more than the subscription.

The money in the category keeps rising. Grand View Research puts the fitness apps market at $13.9 billion in 2026, on its way to $33.6 billion by 2033. The platforms that carried a studio or a coaching brand through its first years were built for the median customer at that stage, and growth moves you off the median.

Public reviews describe the moment in three ways. The first is about control. One Mindbody customer on Capterra put it in capitals: "THEY HOLD YOUR CLIENT DATA HOSTAGE", adding that leaving meant paying "for our own clients information to have it transferred to the new company". The second is about fit: "Designed for large fitness centres, poor choice for martial arts centres." The third is about scale: "We needed more. Unfortunately we had to move off of this one in short order to keep up with growth and activity."

The contract is the fourth reason, and the one people notice last. Mindbody offers terms of 12, 24 or 36 months that "automatically renew at the end of the current term unless the contract is terminated", and requires "at least 30 days' notice before the end of your contract term". Fixed-term plans cannot be cancelled mid-term unless the order form says so. A migration that is ready in month 14 of a 24-month term is a migration that waits ten months or pays twice.

The August 2026 fee fight that decides where your subscriptions live

On August 14, 2026, Apple filed a proposal in the US District Court for Northern California to charge a 15% commission on purchases made through external links in standard apps, and 10% on subscription renewals, with lower rates for its partner programs. The day before, the Supreme Court had declined to pause the proceedings. Epic Games argued the fee should be zero under the Ninth Circuit's definition of necessary costs.

Why this matters to a migration: when you leave a platform, every subscription gets rebuilt somewhere, and you choose where. In-app purchase, billed by Apple and Google. Or web billing, held in a processor you own. The commission on the second path is being decided in court this year, and the answer changes the unit economics of the app you are about to build. Design the subscription layer so the billing route can change without a rewrite, because it will.

The retention side has numbers too. RevenueCat analyzed over 115,000 apps and found that "nearly a third of all subscription cancellations on Google Play are involuntary billing failures", against 14% on the App Store. A migration that re-collects cards from members by email is choosing the involuntary churn rate as its baseline.

How we built this guide

Four rules.

• Every statement about a platform comes from that platform's own documentation or pricing page, fetched in September 2026, and each page is listed in the sources.
• Every statement about a processor or an app store comes from Stripe, Apple or Google directly.
• Our own numbers come from discovery calls and closed contracts in our fitness and wellness pipeline. A group is published only when it rests on at least three records, and the size of the sample is not.
• Where we give an opinion, it is labeled.

One disclosure. Mercury Development builds the owned apps that platform customers migrate to, so we benefit when you leave. Every claim here therefore points at a document you can read yourself. For what the build itself costs, our fitness app development cost guide has the ranges.

What each platform lets you take with you

Leaving Mindbody: the export window closes 30 days after you do

Mindbody is the most documented exit of the three, and the most time-boxed.

Mindbody lists what you can pull yourself in CSV: "Client contact information, Purchase history, Membership details, Visit records, Sales reports, Staff data". For larger accounts, "Mindbody offers a data export service for an added fee. This service is available for up to 30 days after cancellation". After that: "Once your site is fully deactivated, you will no longer be able to access the data stored in it."

Cards are separate. Per the migration guide Spark Membership publishes for its own customers, the paid subscriber data export that includes financial data costs "$500 USD (varies regionally)", is delivered "5 Business days after verification", asks the requester to "Attach a government-issued photo ID", and releases card data only as "encrypted payment data" to a named merchant processor "along with their PGP key". That last clause contains the whole sequencing problem. You cannot request the cards until you have signed with the processor that will receive them, and you cannot test billing on your own app until the cards arrive.

The order that works: sign the processor, open the export request, pull the CSVs yourself the same week, then reconcile the membership export against your new subscription table before the site is deactivated. The paid service is a safety net for volume. The CSVs you can download today come first.

Leaving Kajabi: the contacts are yours, the payment account may not be

Kajabi splits into two exits depending on how you took payments.

The records are simple. Kajabi lets you "Download a CSV of customers and contacts from the Contacts tab", with two limits: "Your contact export is limited to the contacts limit of your Kajabi Plan" and "The download link expires after 3 days". Purchase reports export per offer.

The cards are where the two exits diverge. Kajabi keeps its Stripe and PayPal integrations, and if you connected your own Stripe account, the card data sits in an account you control and Stripe's export process, covered below, is available to you. Kajabi Payments is different: "Kajabi Payments is built in partnership with Stripe", and "you don't create or manage a Stripe account to use it." The processor's export is requested by the account holder. Under Kajabi Payments, that is not you. Kajabi documents the migration from Stripe into Kajabi Payments, completed "within 1 to 3 weeks", and does not document the reverse. Before you build anything, ask Kajabi in writing how card data leaves Kajabi Payments, and get the answer into your timeline.

The app is the good news. Kajabi's branded app lives in developer accounts you create, at $199 a month on Basic and Growth plans and included with Pro, and in-app offers carry Apple's and Google's fee "generally ranging from 15% to 30%". Because the app record is yours, the path in the subscriptions section below applies. One warning from the same page: if you archive or delete the Kajabi site, the app stops working but "will still be visible to customers on their phone and in the app store". Ship your replacement build into that record before you archive.

Leaving Uscreen: your developer account, their code

Uscreen is the clearest statement of the ownership split, because Uscreen wrote it down.

The developer account policy puts the apps in your Apple, Google, Roku and Amazon accounts, with Uscreen invited as a developer, and then draws the line: "Uscreen does not provide app artifacts (build packages, bundles) or any other means of access to the app's source code. This code is our legal property, and we reserve the right to keep it under our control." You own the storefront listing. You do not own anything behind it.

Billing runs through your own Stripe account, which is what makes the exit workable. Uscreen's own inbound migration guide describes the mechanics from the other direction: billing migration is "supported for Stripe only", the account owner must "accept the Stripe data copy request on both your old and new Stripe accounts", and the migrations team handles "re-mapping payment method IDs" afterward. It schedules customer migrations "at least 14 days in advance" and quotes "around 30 days from when all required data is received". Those are the same steps, run the same way, when you leave.

The economics of staying are on the pricing page: App Essentials at $449 a month plus a $0.99 subscriber fee for iOS and Android apps, Growth at $149 plus $1.99 per subscriber without apps, both on annual billing, and a 5% fee on one-time sales on both. A brand with a growing subscriber base pays more every month for an app it will never be able to take with it.

Moving subscriptions without a churn spike

Three moves, in this order.

First, the cards. Stripe states: "If you decide to leave Stripe for another payment processor, we'll work with your new processor's team to securely transfer your credit card data." The receiving processor must be PCI DSS Level 1 compliant, evidenced by a current Attestation of Compliance or a listing on Visa's Global Registry, and must host a PGP key of 4096 bits or more on a domain named in that attestation. Two limits matter for planning: credentials saved through Link are excluded, and "Stripe doesn't export your account's payment history, subscriptions, or other objects." The subscription schedule is rebuilt by your team from the API, which is why the membership CSV and the card export have to reconcile before launch day.

Second, the app record. On Google Play, a transfer carries "All users, statistics, data, comments, ratings, subscriptions, and others that are related to the app". On the App Store, a transferred app "retains its reviews and ratings, and users continue to receive updates", and "maintains its Bundle ID, which can't be changed once a build has been uploaded", per Apple; apps with auto-renewable subscriptions carry an app-specific shared secret that moves with them. Opinion, from the build side: if the app record already sits in your developer account, as it does with Kajabi and Uscreen, you do not transfer anything. Your new codebase ships as the next update to the same record, and a subscriber who bought inside the old app opens the new one still subscribed. That is the single biggest retention lever in the whole project, and it disappears if you publish a fresh app with a fresh bundle ID.

Third, the failures. With billing failures at 31% of Google Play cancellations and 14% on the App Store per RevenueCat's benchmark summary, recovery flows belong in the launch scope. Retry schedules, in-app card update prompts and grace periods have to be live on the day the first migrated renewal runs, because migrated cards fail at a higher rate in the first cycle than cards collected in the app.

Which exit path fits your situation

The exit depends on which asset you are most afraid to lose.

Booking-heavy studio on Mindbody: the client and membership records are the asset, and the calendar is the dependency. Start the CSV exports and the card request against the contract calendar, and expect to keep parts of Mindbody, such as reporting or staff setup, running under a new front end for a phase. The vendor continuity plan lists the accounts to move first.

Coaching or course brand on Kajabi: the payment account decides the timeline. Own Stripe means a Stripe-to-Stripe copy. Kajabi Payments means a written answer from Kajabi before any date is promised to members. The branded app record is yours either way, so the replacement ships as an update.

Video library on Uscreen: the cards and the app record are both yours. What you are replacing is the code, and the content structure around it. The migration is the moment to fix the catalog, the onboarding and the program structure that a hosted video bucket never had, because the members you keep are the ones who find something to do in week two.

Any of the three with a custom vendor in the picture: read the ownership checklist first. An agency that keeps the repository is the same problem with a different logo.

What our discovery records show

These are our own observations, from discovery calls and closed contracts with guided workout and coaching brands in our fitness and wellness pipeline.

Around 60% of those brands came to us to replace a third-party platform or a source video system with an owned product, and the platforms they named were Kajabi, Uscreen and Facebook groups used as the community layer. Around 80% described subscription management as a source of friction: members emailing to cancel, checkout that pushed people to an external browser, tiers and trials the platform could not express. Around 60% ran content operations by hand, out of a CMS plus spreadsheets, and wanted publishing to flow into the app without a manual step. The same share said community and coaching had fragmented across tools they did not control.

The ownership language was direct. One buyer stated the requirement in a single breath: "it has to be completely owned we own the code we own everything." Another described the current position as the reason to move: "we don't own, we are not the owners of the code."

Closed contracts in that group ran from $8,000 for an analysis and design phase to $500,000 for a full owned rebuild, with a median around $140,000. The low end buys the paid phase where the export inventory, the billing route and the app record strategy get decided before anyone writes the product.

Own the accounts before you own the code

Opinion, stated plainly. The platforms in this guide differ on almost everything except one point: the assets that keep your members are held in accounts, and accounts have owners.

A Stripe account in your name turns a card migration from a negotiation into a form. A developer account in your name turns an app replacement into an update. A CSV downloaded this week turns a 30-day export window into a formality. None of these require an engineer. All of them are cheaper on the day you sign with a platform than on the day you leave it, and the second cheapest day is today.

The code comes last. It is the most expensive part of the project and the least important to retention, because members do not churn over architecture. They churn when a card fails, when a login breaks, or when the app they paid for disappears from their phone. Solve the accounts, then build.

Written by Rob Devereaux, Chief Operating Officer at Mercury Development. Rob has run the firm's operations from Hudson, Ohio since 2019 and has over 20 years of operational and financial experience. The discovery records and closed contracts behind this article's migration data sit in the operations he oversees.

Leaving a platform this year? Get the account-by-account migration plan first

Tell us which platform you are on, how you take payments today and where your app record sits. We come back in writing with the export sequence, the billing route we would choose for your situation and the phase that has to happen before any build starts.