Everything it takes to actually replace MindBody

Every owner we talk to has the same fear, and it's a rational one. Their recurring billing is the business. Hundreds of members are on autopay, each with a plan, a rate, and a billing date that's been running for years. "Switch platforms" sounds a lot like "turn all of that off and hope it comes back on." So they stay, quietly frustrated, for years longer than they want to.

We decided the migration wasn't a support task to figure out later — it was a product requirement to design for from day one. If we couldn't move a studio without breaking a single membership, we didn't have a product. Here's what "moving a studio" actually involves.

The four things that must survive

• The member records — names, contact details, emergency info, and the tags and notes staff rely on. People, intact.
• The active memberships — every plan, its price, its start date, and where each member is in their cycle. Not a fresh signup — a continuation.
• The billing relationships — the autopay itself, so cards keep charging on the same dates without asking every member to re-enter a card.
• The history — class attendance, passes, and package balances, so a member who has 4 sessions left still has 4 sessions left.

Miss any one of those and the switch becomes a crisis. Lose the billing relationships and revenue stops. Lose the history and members feel robbed. The whole game is moving all four together.

How we move the billing without re-charging anyone

This is the part owners assume is impossible, and it's the part we cared most about. Card details themselves live with the payment processor, not the old gym software — which means the payment relationships can be transferred to a new system without members ever re-entering a card. We built onboarding around that: the plans and their billing dates come across as data, the payment relationships are migrated at the processor level, and the first charge on Kuviro lands on the same day it would have on the old system. From the member's side, nothing happened. That's the goal — an invisible move.

Parallel run, then a clean cutover

We don't flip a switch and pray. The sequence is deliberate:

• Import and reconcile — bring members, plans, and balances in, then check the totals against the old system until they match exactly.
• Parallel run — the new schedule and the old billing overlap briefly so staff can sanity-check real days before anything depends on it.
• Cutover on a billing boundary — we switch at a point in the billing cycle that's clean, so no member is charged twice and none is skipped.
• Watch the first run — the first live billing run is monitored closely, with the old system still available as a reference, not a fallback you'll need.

Why this belongs in the product, not a PDF

Plenty of platforms will hand you a spreadsheet template and wish you luck. We think that's backwards. The migration is the scariest moment in a customer's life with us, so it's the moment the software should be doing the most work — validating imports, matching balances, catching the one plan that didn't map cleanly before it becomes a billing error. Getting this right is how we earn the right to run the rest of the gym.