6 min readBrad Crump
How to switch class management software without losing enrollment data
The number one reason studio owners stay on software they dislike is fear of the migration. Ten years of family records, active enrollments across dozens of classes, autopay running on the first of the month — it feels like moving a house while people are still living in it.
It's a legitimate concern, but it's also a solvable one. Studios switch platforms all the time without losing a single enrollment, and the ones that do it smoothly all follow roughly the same playbook. Here it is.
Step 1: Audit what you actually need to move
Most owners assume everything has to come over. It doesn't, and trying to migrate everything is the fastest way to stall the whole project. Split your data into two buckets:
Must move: families (parent names, emails, phone numbers), students (names, birthdates, which family they belong to), and active enrollments (which student is in which class right now). This is the data your business runs on day to day. If it arrives intact, the switch works.
Nice to have, usually skip: attendance history, old skill evaluations, notes from three seasons ago, and inactive families who left years back. This history has sentimental weight but almost no operational value. You will look at it far less than you think, and every extra dataset you migrate adds mapping work, validation errors, and delay.
Why payment history should not migrate
This surprises people, but it's the strong consensus among studios that have done this: leave payment history in the old system. Financial records are tied to the payment processor that created them — refunds, disputes, and card references don't transfer meaningfully between platforms, and a half-imported ledger is worse than no ledger, because now you have two conflicting sources of truth.
The right move is to keep your old system in read-only mode for a while: export every financial report you might need for taxes and bookkeeping (transaction history, aged accounts, revenue by program), save the files somewhere durable, and downgrade or cancel the old account once you've confirmed the exports are complete. Your accountant needs the records; your new software doesn't. Billing starts fresh on the new platform with clean balances, which is also a natural moment to chase down any lingering unpaid balances before the switch.
How the CSV export/import actually works
Both Jackrabbit and iClassPro can export families, students, and enrollments to CSV files — spreadsheet exports you can open in Excel or Google Sheets. The mechanics on the other side vary by platform, but a good import flow looks like this:
Export, then map. You pull the CSVs from your old system, then map its column names to the new platform's template — their "Guardian Email" becomes the new system's parent email field, and so on. This is tedious but mechanical, and it's a one-time cost.
Validate before importing. Insist on a platform that checks the file before it writes anything: malformed emails, duplicate students, enrollments that reference a class that doesn't exist yet. Fixing fifty flagged rows in a spreadsheet takes twenty minutes. Discovering fifty broken records after they're live takes weeks. ClassPulse handles this with guided CSV templates that validate every row and report problems before the import runs, and it accepts the export formats Jackrabbit and iClassPro produce.
One honest caveat that applies to any switch: your class schedule itself is rebuilt, not imported. Schedules encode too many platform-specific concepts — sessions, rooms, instructor assignments — to transfer cleanly. Plan an afternoon to recreate your current schedule in the new system before you import enrollments, since enrollments need classes to land in.
Time the cutover around a billing boundary
The single best scheduling decision you can make: cut over at the start of a billing cycle. If you bill on the first of the month, the last charge from the old system runs on the 1st, you switch mid-month while no money is moving, and the first charge from the new system runs on the following 1st. Nobody gets double-billed, nobody gets missed, and you never have to prorate across two systems.
Working backwards from that boundary gives you the whole timeline. Three to four weeks out: pick the platform and start rebuilding your schedule. Two weeks out: run the imports and verify them. One week out: invite parents to set up accounts and re-enter payment methods — card numbers can never be exported from your old system, for good security reasons, so parents add their card once in the new parent portal.
Run both systems in parallel for a week
Don't flip a switch and hope. For one week, keep the old system alive while the new one does the real work. Take attendance in the new system, but spot-check rosters against the old one. Have your front desk staff do their normal tasks — look up a family, move a student, answer a schedule question — in the new platform while the old one is still there as a safety net. Every discrepancy you catch in parallel week is a phone call you don't get in month two.
A free tier makes this easy: ClassPulse is free up to 50 students, which is enough to import a real slice of your data and run this evaluation before you commit a dollar or announce anything to parents.
Telling parents: one email, one week ahead
Parents don't care what software you use; they care whether anything changes for them. One clear email a week before cutover covers it. The outline that works:
What's changing and when ("On August 1st we're moving to a new parent portal"), the one thing they need to do (create their account at the link and re-enter their payment method — explain that card data can't legally be transferred, which parents respect), what stays the same (classes, times, instructors, tuition), and who to contact if something looks wrong. Send a reminder to anyone who hasn't set up their account three days before the first billing run.
The pre-switch checklist
- Export families, students, and active enrollments from your current system.
- Export and archive every financial report you'll ever need — payment history stays behind.
- Rebuild your current class schedule in the new platform.
- Import families and students, then enrollments; fix everything the validator flags before going live.
- Spot-check rosters: pick five classes and verify every student against the old system.
- Schedule the cutover at a billing cycle boundary and confirm the old system's final billing run.
- Email parents one week out; remind non-responders.
- Run parallel for a week, then downgrade the old account to read-only until you're confident you have every record.
None of these steps is hard. The studios that struggle are the ones that skip the audit, try to migrate everything, and cut over mid-billing-cycle. Do it in this order and the scariest part of switching turns out to be deciding to.
If you're evaluating ClassPulse specifically: founding studios get free white-glove migration — we do the export, mapping, and import work with you — and the free plan up to 50 students means you can run the whole parallel-week evaluation before paying anything.