Guides  ·  2026-08-29  ·  9 min read

How to Switch Club Software Without Stopping: A Migration Guide

The fear is reasonable, the leap is not necessary

A club cannot afford a weekend with two people booking the same court. That is why most software changes get postponed indefinitely: it is not that the current system is loved, it is that switching it off is frightening and switching on an untested one is worse.

The good news is that the frightening part — the cutover — is avoidable. Almost any management system can publish its calendar in a standard format, and that lets two platforms coexist without stepping on each other: the old one stays the source of truth for what is already taken, and the new one simply does not offer those slots.

Three weeks later you are not deciding on a demo: you are deciding on three real weeks of your club in both tools. And if the new one does not convince you, you have switched nothing off.

The piece that makes it work: the iCal calendar

iCal (.ics files) is the standard calendar format. It is what Google Calendar and Outlook use, and what most club management software exports. An iCal feed is a URL that, each time it is polled, returns the list of busy events.

Here is how the coexistence is set up in BookrGo:

1. In the system you use today, find the iCal feed URL for each court. It is usually under settings, export or calendar sync.
2. In BookrGo you go to Edit court → iCal sync and paste that URL. If your feed is private and needs authentication, there is a field for the header and its value.
3. From then on BookrGo polls that feed every 15 minutes and blocks the hours that show as busy. Nobody can book an hour here that is already sold there.

And in the other direction, so your current system also sees what gets booked in BookrGo: there is a subscribable .ics feed with your venue's bookings for the next 60 days, obtained with an API key from your panel. You subscribe to it in the system you use today and new bookings show up there as blocks.

The limits of iCal, said before you meet them

• It is not real time. Polling is every 15 minutes, so worst case that is the lag. For a court schedule that is perfectly workable; for a centre selling the same hour in two places by the minute, it is not.
• It is set per court, not per club. Eight courts means eight URLs. That is a copy-and-paste session, once.
• It only reads. The inbound iCal feed blocks slots; it does not create bookings in your current system. During coexistence, each booking lives in the platform where it was made.
• It depends on your current system publishing the feed. If it does not export .ics, this route is not available and you have to check whether its API works instead.
• A 90-day horizon. Events for the next three months are imported; anything beyond that is picked up when it comes into range.

The members: the CSV

The second half of the fear is the member file. Nobody hand-enters 300 people, and rightly so.

• Format: a header with email, name and optionally tier (the membership tier, matched by name against ones you have already created). With no header, that column order is assumed.
• Limits: 2 MB per file and 10,000 rows per import. Plenty for a real club; beyond that, split it in two.
• You can repeat it safely. Re-importing the same CSV updates instead of duplicating. That is what lets you test with twenty rows, check the result, and then upload the whole file.
• What happens to each row: the member is created as pending (no fee paid yet). If that email has no account, an invitation is sent; if it already has one, an in-app notice.
• It is on every plan, including the free one: you can complete the whole migration before paying anything.

If your file is not clean — and many clubs' are not — there is an alternative that needs no CSV: QR sign-up at the front desk. The member scans, registers themselves and is attached to your club. It handles the trickle of people left over after the import.

First of all: get your data out of the current system

This is the forgotten step and the expensive one. Before moving a single court, export everything exportable from the system you use today: members with email and phone, booking history, fees and payment status, and any invoicing files.

Do it even if you are not switching. If your current provider will not let you export yourself in an open format, you have just learned something important about that relationship — and it is exactly one of the four things to check when choosing.

The four-week plan

Week 0 — prepare, touch nothing

1. Export everything exportable from the current system (above).
2. Claim or create your venue page and check the public data is right: name, address, sports, opening hours, photos.
3. Create your courts with their real names, the ones your team already uses. Do not invent new naming in the middle of a migration.

Week 1 — coexistence

1. Paste each court's iCal feed. Make a test booking in the old system and check that within 15 minutes the slot disappears from the new one.
2. Subscribe to BookrGo's .ics feed in your current system, so information travels both ways.
3. Do not announce anything to members yet. This week is for you and the two or three people on your team who will use the panel.

Week 2 — a genuinely small group

1. Set prices per court and time slot, and the rules you already have: maximum lead time, per-person quota, cancellation policy.
2. Import twenty rows of the member CSV, not three hundred. Check the invitations arrive and the tiers matched correctly.
3. Ask those twenty to book for real for a week. Whatever goes wrong here goes wrong with twenty people, not your whole club.

Week 3 — everyone else

1. Upload the full CSV. Since re-importing updates, the previous twenty rows are not duplicated.
2. If you are going to charge online, connect the receiving account: it is opened in the name of whoever runs the centre, and Stripe runs the verification, not us.
3. Tell members about the change with a concrete date and one sentence on why.

Week 4 — switch off (or not)

1. Leave the old system running read-only for another week or two, with the iCal feed still connected. It costs nothing and it is your safety net.
2. When no bookings come through there any more, remove the iCal URLs from the courts and cancel the old contract respecting its notice period — if it auto-renews, that detail can cost you a whole year.

What does NOT migrate, and it needs saying

• Past booking history. There is no booking import: the only thing imported is the member file. Your history stays in the CSV you exported, which is where your accountant needs it anyway.
• Balances, wallets and packs already sold in the previous system. You re-create the packs you sell from now on; what you already charged there is settled there.
• The direct debit mandates you already hold signed. Fees can go by direct debit here — the member picks card or direct debit when authorising — but they sign the mandate again: mandates are not imported, and we do not generate the remittance file a club prepares and sends to its bank. What migrates is the member list; the authorisation to charge is given afresh by each member.
• Your invoicing and your accounts. We do not issue your invoices or keep your books. You export bookings and members as CSV and hand them to whoever does your accounting.
• We do not run the migration for you. It is designed for your team to do in an afternoon: paste URLs, upload a CSV. There is no assisted migration service, and saying so up front is more useful than discovering it in week 2.

The three mistakes that sink a software change

1. Announcing it to members on day one. If the whole club arrives before you know the panel, everyone sees the first failure and there is no second chance. Your team first, then twenty, then everyone.
2. A clean cutover on a Sunday. There is no reason to do it if both schedules can coexist. The clean cutover is the number one cause of Monday's double booking.
3. Forgetting the old contract's notice period. Many fixed fees renew themselves with 30 or 60 days' notice. Read that clause in week 0, not week 4.

And what you gain along the way

While you are testing, there is something the system you use today cannot give you: your venue page is published in a catalogue people use to find somewhere to play, and the dashboard shows how many people looked up your centre this month even without booking. That is a fact about the past you can look at before deciding anything, not a traffic promise.

The technical detail on iCal, the API and webhooks is in integrations; on members and fees, in membership and fee management. If you run courts, your page is padel club management software. And before settling on a destination, it helps to know what each pricing model costs.

See BookrGo plans and pricing: it opens the table of what each plan includes and its commission: with no fee it is 2% of what you collect online, dropping with a fee down to 0%. No sign-up needed to read it.