Sports, Fitness & Athletics// definition

The member export: what leaves your club platform and what stays

In short

An export is not a backup. It is whichever subset of your data the incumbent chose to serialise: reliably the people and their contact details, usually current bookings, rarely the attendance register, and almost never consent records, message threads or payment mandates. Two of those absences can stop a migration on their own.

Key takeaways

  • An export carries what the vendor chose to serialise, which is a much smaller set than what they hold about you.
  • People and contact fields nearly always travel. Attendance history, consent records and message threads usually do not.
  • Missing consent records force you to re-collect permission, and re-collection is where a membership list quietly shrinks.
  • Guardian-to-child links are the field most often absent and hardest to rebuild, because no adult is named on the child's row.
  • Ask for a real sample export from a live account before signing, not a schema description in a sales deck.

A member export is a file the incumbent generates from a query somebody wrote once, years ago, to satisfy the most common request. It is not a copy of your data. Whatever the contract says about ownership, what you can take is bounded by that query, and the boundary is where migrations run into trouble.

The useful question is never "do we own our data" — you almost certainly do, and owning it against being able to leave covers why that changes little. The useful question is which objects come out, with which identifiers, in what format, and how often you may ask.

What travels, what stays, and what breaks

Grouped by object, with the consequence of each absence. Run it against your own platform rather than trusting it as a description: the pattern is consistent across the category, the specifics are not.

ObjectUsually presentUsually missingWhat breaks without it
PeopleName, contact details, date of birth, membership type, join date, statusGuardian-to-child links, emergency contacts, medical notes, photo permissionsUnder-18 records arrive with no adult attached
BookingsFuture bookings for a short forward windowThe past: cancellations, waitlist positions, no-show historyYou cannot honour a credit or evidence a charge
AttendanceNothing, or a summary count per memberThe register — who attended what, marked by whom, whenRetention and funding reporting restart from zero
ConsentsA single marketing opt-in flagPurpose, timestamp, wording version, capturer, withdrawalsNo evidence of your basis, so you must re-collect
FinancialBalances and an invoice list, often as a report not dataMandate references, gateway ids, decline history, creditsCollection stops until every member re-authorises
MessagesNothingCoach-to-member and parent-to-coach threads, with timestampsSafeguarding evidence disappears from the record
MediaA bulk download with machine-generated filenamesThe link between a file and the person or permission governing itPhotos survive; the permission to publish them does not
A typical club or gym export, object by object

The 2 absences that end a migration

Most gaps are recoverable with a week of work. Two are not, and both are financial or legal rather than technical.

The first is the payment mandate. A recurring authorisation is held against a merchant, and if the platform is the merchant of record it does not travel in a file — every member re-authorises, and the fraction who never get round to it is your real migration cost. Settle whether member mandates move with you before a date is chosen.

The second is the consent record. A boolean opt-in flag is not one: the record is the purpose, the wording shown, the timestamp, the capturer and any withdrawal. Without it you cannot demonstrate the basis for holding a child's medical note or publishing a photograph, so the defensible move is to re-collect — and re-collection is where a list shrinks. The same boundary applies to data read from a phone's health store: what a health permission actually grants your app.

What to ask for, in the format you need it

  1. A sample export from a live account, before signature. A schema description in a deck is not evidence; a file with 50 real rows is.
  2. The exclusion list by name. Ask which objects are not included at all — the opposite question gets a longer, less useful answer.
  3. Stable identifiers on every row. An export keyed on name and email forces fuzzy matching later, the identity work in preparing a member file that will import.
  4. The register, explicitly. Attendance is the object most often absent and the one retention analysis depends on.
  5. The consent ledger with purposes and timestamps, not today's flag.
  6. The terms of the request: how long a file takes to produce, how many you may ask for, and how many days after termination the export still works.

Two neighbouring decisions stay separate from this one. If several systems already disagree about who is a member, exporting from all of them produces 3 wrong lists rather than 1 right one — start with three systems, three member lists. And a poor export surface is a reason to negotiate, not to build: most clubs should not build custom software. For a federation the question is which club data the centre may read at all — where the tenancy line goes.

Anything automated you build on a platform inherits its export surface, which is why we read it before scoping — see agents in production. Extraction and reconciliation of this kind is routine AI agents and automation work, under build, buy, extend or migrate in our sports and fitness practice.

Frequently asked questions

Short answers to the follow-ups this page tends to raise.

Does club management software export attendance history?

Usually not, or only as a summary count per member rather than the register itself. Attendance is stored against sessions and marked by staff, so exporting it properly means exporting sessions, marks, markers and timestamps together — more objects than a member file. Ask specifically and ask for a sample, because a summary count cannot rebuild a term's register.

What format does a member export usually come in?

One or more CSV files, sometimes zipped, occasionally an Excel workbook with a sheet per object. Check 3 things: the character encoding, whether dates carry a timezone, and whether the file is a report formatted for reading rather than data formatted for loading. Merged header rows and totals lines give away the last one.

Can we get our data after we cancel the contract?

Sometimes, and rarely for long. Admin access typically ends with the subscription and the export function lives inside it, so the practical window can be days rather than months. Agree the post-termination window in writing before you sign, and take a full export while the account is still live.

Is an export the same as a backup?

No. A backup is a copy of the system's own state, taken for the vendor's recovery purposes and not readable by you. An export is a curated subset serialised for portability. A vendor can hold complete backups and still offer an export missing half your objects, and both facts can be true without anybody being dishonest.

  • data export
  • migration
  • club software
  • member records
// shipped work

The work behind this page

Builds from our portfolio that this page draws on.

Working on something in this space?

Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.

Start the conversation