Moving a swim school onto new software
The switch itself is rarely the hard part. What decides whether it goes well is the order you move things in: families and class structure first, active subscriptions second, history last. Do it between terms, run both systems for a fortnight, and take the first payment run on the new platform only once the old one has proved it agrees.
Why swim schools stay on software they have outgrown
Almost nobody stays because the software is good. They stay because the cost of leaving looks unknowable. There are four hundred families on the system, half of them on a recurring payment, and the register that gets printed on a Saturday morning is the one thing that must not break.
That fear is reasonable, but it is usually pointed at the wrong risk. Moving the data is a solved problem. What goes wrong in a switch is almost always timing and payments: a term boundary missed, or a direct debit taken twice because two systems both thought they were live. Those are scheduling decisions, not technical ones, and they are the part worth spending your attention on.
What actually has to move
It helps to separate the things that must be right on day one from the things that can follow later. Most of the anxiety attaches to the third column, and most of it is misplaced. Nobody has ever cancelled because last year\'s attendance history arrived a fortnight after launch.
| What | When it has to be right | What goes wrong if it is not |
|---|---|---|
| Families and swimmers | Before launch | Parents cannot log in, and your register is wrong |
| Class structure and levels | Before launch | Nobody can be placed, so nothing else works |
| Timetable and venues | Before launch | Bookings land in the wrong pool or the wrong hour |
| Active subscriptions | First payment run | Families are charged twice, or not at all |
| Outstanding credits | First week | Parents lose make-up sessions they have already earned |
| Attendance history | Can follow later | Reporting is thin for a term, and nothing else |
| Old invoices | Can follow later | Nothing, as long as the records still exist somewhere |
Pick the gap, not the date
The single decision that matters most is when. Move between terms, in the gap when no classes are running and no payment is due. A school on a term structure usually has three or four of these windows a year, and they are worth waiting for.
Avoid the fortnight before a term starts. That is when re-enrolment happens, when parents are logging in for the first time in months, and when your team has the least attention to spare. A switch that would have been uneventful in the quiet week becomes a crisis in the busy one, for no reason other than the date.
If you cannot wait for a term gap, phase it instead. Take bookings on the new system for the coming term while the old one finishes billing the current one. That is slower and slightly more work, and it is much safer than trying to move everything on a Sunday night.
The payment run is the real test
Everything else can be corrected quietly. A payment taken twice cannot, because the parent sees it before you do.
Before the first live run, reconcile deliberately: every active subscription on the old system should have exactly one match on the new one, at the same amount, on the same day. Check the total against last term\'s figure. If the two numbers disagree and you cannot explain the difference in a sentence, do not run it.
Then cancel the old mandates properly rather than leaving the old account dormant. A dormant billing system is the most common cause of a duplicate charge, because it is still perfectly capable of taking money and nobody is watching it any more.
How long it takes
For a bespoke build, migration is part of the project rather than a separate exercise, and a typical swim school system runs eight to sixteen weeks from the first call to launch. The data movement itself is a small share of that. Most of the time goes on agreeing how your rules actually work, which is time you would have spent anyway.
Plan on running both systems side by side for about a fortnight after launch. Not because the new one is doubtful, but because a fortnight covers one full weekly cycle twice, which is usually enough for anything odd to surface while the old system is still there to check against.
Common questions
No, provided you export before you cancel anything. Family records, class structures and active subscriptions can all be moved, and we handle migration as part of the project. The thing to protect is access: keep the old system readable until the new one has completed a full payment cycle, because an export you cannot re-run is a single point of failure.
In a gap between terms, when no classes are running and no payment is due. Avoid the fortnight before a term starts, which is when re-enrolment lands and your team has the least spare attention. If no gap is available, take bookings on the new system for the next term while the old one finishes billing the current one.
They are matched one to one onto the new system before the first live payment run, at the same amount and on the same day, and the old mandates are cancelled rather than left dormant. Reconcile the total against the previous term before running anything. Duplicate charges almost always come from an old billing system nobody switched off.
They should have to do as little as possible. Families are set up in advance so that a parent's first experience of the new system is signing in, not registering again. Expect to send one clear message explaining what is changing and when, and to answer questions for a week or so afterwards.
A bespoke swim school system is typically eight to sixteen weeks from first call to launch, with migration included rather than charged separately. Moving the data is a small part of that; most of the time goes on agreeing how your rules work. Allow a further fortnight of running both systems in parallel after go-live.
Where to go next
If you want a straight answer about your own situation, tell us what you are trying to do and we will say what we would do, including when the answer is that you do not need us. Start a conversation.