Studio Software Migration: A Checklist That Avoids Lost Data

Treat a studio software migration as four ledgers, not one export: your roster, your money trail, your unredeemed promises, and your payment permissions. Roster and revenue history copy across cleanly. Class-pack balances and saved payment credentials are where studios lose data, and both need work before you give notice.

What does a studio software migration actually move?

Four ledgers move: the roster, the money trail, the unredeemed promises, and the payment permissions. Most migrations break on the last two.

The roster is easy. Name, email, phone, join date, membership type, all standard CSV columns. The money trail is usually fine too, though you want processor transaction IDs in the export, not just amounts and dates, because those IDs are what let you match a chargeback in six months to the right member.

The promises ledger is the one no export format handles well. A 10-class pack with three visits used exports as "10-class pack" in most systems, not "7 remaining." Purchases and redemptions live in separate tables, and if only the purchase table moves, you either give away credits or take them back from members who paid for them.

The permissions ledger is card tokens and ACH mandates. Those never travel in a spreadsheet.

Which exports do you pull before you give notice?

Pull every export while the account is still paid and unrestricted. Cancellation notices often trigger feature downgrades, and export tools are among the first things to go.

The list, in the order that matters: member roster including the internal member ID column, 24 months of transactions with processor transaction IDs, the pack table and the redemption table as two separate files, attendance history, staff records with pay rates and worker classification, the class schedule with recurrence rules intact, and every signed waiver as a PDF.

Waivers are the slow one. A studio with several hundred members downloading one PDF per member is a multi-hour job, and many platforms have no bulk option. Start it seven days before anything else. Staff classification records matter for the same reason: if you are moving 1099 and W-2 instructor records, the pay-rate history has to survive the move intact.

How do you move saved cards without making members re-enter them?

Cards move processor to processor, never through you. You arrange the transfer, both providers coordinate, and you receive a mapping file at the end.

Nobody is allowed to email you a spreadsheet of card numbers. The compliant path is an encrypted file transfer between the two processors. Stripe's payments data import documentation sets out the sequence: build the new integration first, request the data from your previous processor, submit a migration request, then wait. Stripe warns that the previous processor might take a few days or several weeks to release the final file, and the receiving processor needs its own import window after that. Ask both for their current turnaround in writing before you commit to a go-live date.

You then get a CSV or JSON mapping file pairing each old customer and card ID with the new one. That file has to be loaded into the new system, or the tokens exist but nothing is attached to a member.

What happens to your ACH and autopay authorizations?

ACH mandates are legal permissions, not data rows. They survive a migration only if the authorization on file still matches what you are actually debiting.

Under Regulation E, preauthorized electronic fund transfers from a consumer's account may be authorized only by a writing signed or similarly authenticated by the consumer, and a copy has to be furnished to that consumer. Keep those authorization records with the migrated member, not in a folder on the old system.

Two operational traps. First, your bank statement descriptor usually changes when the processor changes, and members read an unfamiliar descriptor as fraud. Second, if the cutover prorates anyone's charge, that is an amount change, and Regulation E requires written notice at least 10 days before the transfer when the amount differs from the previous one. A date shift alone does not trigger it. A prorated dollar figure does. This is one more reason to keep ACH and card billing rules straight before you touch anything.

How do you migrate unredeemed packs, prepaid sessions, and gift cards?

Reconcile balances, not purchases. Compute remaining credits as purchased minus redeemed minus expired, then have a human review the largest balances by dollar value.

Freeze new pack sales 72 hours before you cut the export. Then export the purchase table and the redemption table separately and join them yourself. If the new system imports only purchases, every member with a partly used pack gets their credits reset upward, and you have quietly given away inventory.

The shape of the problem is consistent: a mid-sized studio carries open packs in the low hundreds at any time, and a handful are outliers, usually someone who bought a bundle during a Black Friday promotion and still holds dozens of credits (Zatrovo studios, 2026). Eyeball the top 25 balances manually. That takes half an hour and prevents the disputes that cost days.

Gift cards are a liability on your books, not a marketing item. An unredeemed gift card that vanishes in a migration becomes a chargeback, and many states apply unclaimed-property rules to the outstanding balance, with the details varying by state. Export them as a distinct file.

What records must you keep after the old system is gone?

Keep the financial trail on a statutory clock and store it outside both vendors. Your old provider's informal retention promise is not a retention policy.

The IRS record retention guidance sets the general period at three years, and employment tax records at a minimum of four years after the tax becomes due or is paid, whichever is later. For payment data, the PCI Security Standards Council states plainly that PCI DSS does not define minimum or maximum times for how long cardholder data may be stored; the standard obliges you to implement your own retention and disposal policy, limited to legal, regulatory, and business need.

Practical version: on cutover day, create one dated archive containing every CSV, the waiver PDFs, and the mapping file. Put it somewhere neither vendor controls. Write two lines in your operations manual naming the retention period and the person who reviews it annually.

When in the month should you cut over?

Mid-month, midweek, after the previous billing run has fully settled. The 1st is the worst possible date because many studios bill then.

Specifically, wait until ACH returns from the last run have had time to land, which can be several days after the debit itself. Then pick a Tuesday between the 10th and the 20th. That gives you four staffed working days before a weekend, and roughly two weeks of runway before the next scheduled charge.

Avoid the first two weeks of January and avoid your intro-offer intake window. New-member volume and an untested check-in flow are a bad pairing, because the people most likely to walk out are the ones with no relationship to the studio yet.

Disclosure: Zatrovo sells studio management software, so we have a commercial interest in studios switching systems. The table below is drawn from our own onboardings rather than independent research, and it is labeled as such.

How do you run a parallel period without double-charging anyone?

Parallel means both systems can be read. Only one may charge. Turn off recurring billing in the old system before the first charge fires in the new one.

The sequence is strict. Disable autopay and all scheduled invoices in the old platform. Get written confirmation from that vendor that automatic billing is canceled; Stripe's migration guidance makes this an explicit final step for a reason, because a dormant subscription schedule will happily bill a member you already moved. Only then enable billing in the new system.

Bookings are different. Run bookings in the new system from day one, and keep the old one open read-only so the desk can look up a waiver or a purchase date without guessing. Two booking systems taking live reservations for the same 6:00 am class is the fastest way to oversell a 14-bike studio.

Why do failed payments spike in week one, and how do you stop it?

Declines rise after any migration because saved cards can lose the original network token or transaction reference, and your statement descriptor changes. It is mechanical, not churn.

Do not mass-retry. Stripe's documentation warns that retrying large numbers of cards after a migration can look suspicious to issuers, which turns a small problem into a blocked batch. Triage by decline code instead. Expired or incorrect number responses go to card account updater and network tokens. Generic decline and do-not-honor usually trace to the descriptor change, so contact the member. Lost or stolen cards get a phone call and no retry at all.

Call the highest-value failures within two hours of the run, not the next morning. A same-day call from a person the member recognizes recovers the payment far more reliably than a templated dunning email, which is the same logic behind recovering abandoned checkouts.

What do you tell members, and when?

Two messages, not five. One a week out, one on the morning of the switch. Both must contain the exact new statement descriptor.

The T-minus-7 message says what does not change, first: same rate, same billing day, same class times. Then what does: a new booking link and a different name on their bank statement. The go-live message repeats the link and offers a direct reply channel for anyone who cannot get in.

Printing the literal descriptor string, character for character, is the highest-value line in either message. Unrecognized descriptors drive "I did not authorize this" disputes, and a dispute costs you the fee plus the relationship. Members who charge back once rarely stay, which is why they show up quickly in at-risk member detection.

What do you check in the first 14 days?

Run a fixed audit on days 1, 3, 7, and 14. Fixed dates, named owner, written results. Ad hoc checking finds nothing because nobody knows what "fine" looks like.

Day 1: reconcile the active member count old against new to the exact number. Not approximately. Day 3: spot-check 20 random members for remaining pack balance and next bill date, and verify every recurring class on next month's schedule. Day 7: run the collected-total comparison above, then pull the list of members with no payment method on file and call them. Day 14: reconcile instructor pay for the first period against the old system's rates.

Then file the old system's login credentials, the mapping file, and the vendor's support email address in one document and keep it for 12 months. The question you cannot answer without them tends to arrive around month seven, usually as a chargeback on a transaction that predates the switch.

Give the desk a one-page script for the three questions they will actually get, which slots neatly into your existing front desk training.