Ask them to prove it
on your actual file

Why we give this away

Moving data between membership systems is never automatic, because no two systems store a family, a membership status or a payment the same way. Someone has to make decisions about your data. The only real question is whether those decisions are made deliberately, or guessed by an importer that fails quietly.

A bad import is worse than no import. If your records do not move, you know it. If they move badly, you believe they are fine — until a parent is billed the wrong amount, a grading history turns out to be missing, or a report is wrong and nobody can say why.

So we would rather show you the awkward parts of your own data first, while you are still deciding.

What the checker actually does

You export from your current system and drop the file above. It is read in your browser — nothing is uploaded, nothing reaches us, and there is no account to create. It works out what it is looking at from the columns, so the file names do not matter.

• Members that belong to no family. The most common problem in a real export, and the most expensive to find late. A member with no household loads, looks correct, and then bills separately from the rest of the family.
• Duplicate records, where one row would silently overwrite another.
• Ambiguous dates. 03/04/2019 is the third of April in one country and the fourth of March in another, and nothing in the file says which. It flags them rather than picking.
• Your status words — Active, Frozen, Trial, Cancelled, whatever you use — listed so each can be mapped by a person.
• How full each column is. If phone numbers are 12% populated, better to know now.

It gives you three lists: what must be fixed, what needs a decision from you, and what is merely worth a look. Send us the output and we will tell you what it takes to sort out, whether or not you switch.

Your system stores members. We store households.

Almost every system in this market keeps a list of people, each with a note about who pays for them. It knows that Aiden is paid for by Maria. It does not really know that Aiden, Sofia and Maria are one family with one bill — that idea does not exist in it, so it is not in the export either.

Rebuilding that is most of the work of moving. The checker does it in front of you: it finds whatever your file uses to tie people together — an account number, the payer's email, a family name, or a shared phone and surname — groups your people by it, and tells you how many households came out and how many rows it could not place.

It also separates the adults who only pay from the adults who payand train. That distinction is worth money: the first become contacts on the family and are not billable, the second are one contact and one member, counted once. Getting it wrong is the classic way a first invoice comes out too high.

The one that decides your invoice

Your rate here is based on your active and suspended members. So a member marked Frozen or On hold in your current system might or might not count, depending on what that word means in your business.

We will not guess at that. The checker lists every status word in your file and we map them with you before anything is loaded — because the alternative is somebody's first invoice being wrong, and that is not a mistake worth being efficient about.

Where we are honest

Bringing records across is manual work today, and building the import properly is the next thing we are doing. Until it ships, this is what you get: we read your actual file, tell you what moving it involves, and quote it — before you commit rather than after.

We do not move stored card details, and no vendor should. Your members re-enter them once with your payment provider. Anything else would mean a software company handling card data that was never theirs to hold.

Questions

Can you import from Kicksite, Jackrabbit, Zen Planner, Mindbody or PushPress?

All of them export CSV, and that is what we work from. There is no one-click connector to any of them today, and any vendor claiming a true one-click migration between two membership systems is describing a person doing it by hand. What we do is read your actual export and tell you what maps cleanly and what does not.

What does not come across?

Stored card details, and that is deliberate — nobody should move those. Your members re-enter payment details once, with your payment provider, and that is the only safe way it can work. Attendance and payment history are a later phase; if either matters to you, say so and we will tell you where we have got to.

Will my member statuses transfer correctly?

Only if a person maps them, which is why the validator lists every status word in your file rather than guessing. Your rate here depends on active and suspended members, so mapping a frozen or trial member wrongly would change your first invoice. We will not guess at that, and you should be suspicious of anything that does.

How long does it take?

It depends almost entirely on how clean the export is, which is exactly what the validator tells you before anyone commits to a date. A tidy file from a system that exports properly is quick. A file with orphaned members and three different date formats is not, and we would rather you knew that at the start.

What does it cost?

We quote it once we have seen your file, because the honest answer depends on what is in it. We are not going to publish a flat fee and then discover your export needs a week of work — or charge you for a week when it needs an afternoon.

Do I have to move everything at once?

No, and often you should not. The trial runs 30 days with every feature switched on, so bringing one program across and running it alongside what you have is a more honest test than any demo — including ours.