Migration · practical guide

Move Your Club from Spreadsheets

A careful club membership migration guide with the actual Member Link CSV field mappings, required values, duplicate rules and fictional sample file.

A safe migration protects the old register, defines one row per person, tests field mappings and reconciles the results before the committee relies on the new system. This guide describes the application's current CSV importer behavior so the sample can be checked before use.

Updated 2026-10-02 Member Link editorial team

Start a trial Talk to our support team

Prepare the file and keep a secure original

Export a working copy as UTF-8 CSV with a single header row and one person per row. The importer strips a leading UTF-8 byte-order mark, reads the first row as headers, skips empty lines and reports a preview. Keep the original spreadsheet in restricted storage; do not attach it to email or use a live member export for a demo.

Download the sample file below: its people and addresses are fictional and use the reserved example.org domain. It demonstrates column names, not a ready-made plan: the membershipPlan value must match a plan already configured in the destination organisation.

Use the importer's actual field names and mapping rules

The import's internal mapping keys include firstName, lastName and email (all required mappings). Auto-detection normalizes header spelling by lowercasing and removing punctuation, then looks for known names or matching patterns. It supports phone, memberNumber, status, notes, memberSince, dateOfBirth, membershipPlan, street, city, state, zip, country and optional household fields.

For a predictable file, use these headers exactly: firstName,lastName,email,phone,memberNumber,status,memberSince,dateOfBirth,membershipPlan,street,city,state,zip,country,householdName,householdKey,relationship,primaryContact,primaryPayer. Field mappings remain editable in the import UI. Custom fields use separate custom-field mappings.

Required: firstName, lastName and email mappings. Each row needs first and last name.
A blank email is accepted only for a row mapped as dependant/dependent with a nonblank householdName. Other rows without email are rejected.
An email must match the importer's basic address format; existing member duplicate detection uses lowercased email.
membershipPlan resolves by case-insensitive match to an existing plan name. Unknown names do not map to a plan.
Duplicate action is skip by default, or update if selected; inspect the consequences before choosing update.

Households require deliberate setup and consistent values

Household mappings are opt-in. If any household field is mapped, household memberships must first be enabled in the organisation settings. The supported relationship values are primary, spouse, guardian, dependant, dependent, other and member; blank relationships default to member when a household is attached.

Household identity is based on a key when provided, otherwise its name. Keep each household's name/key consistent across rows. A key cannot refer to different names, a name cannot mix conflicting keys or omit a key when an existing keyed household requires it, and ambiguous existing identities are rejected.

primaryContact and primaryPayer accept true/false, yes/no, 1/0 or y/n. The importer rejects conflicting nominations for the same household. Use one intended primary contact and payer, and do not assume that importing a relationship authorizes every kind of guardian access.

Household membership feature

Test, reconcile and retain a rollback path

First preview the CSV and check detected columns, auto-mappings, sample rows and plan list. Test a small approved batch, read each row-level result and confirm a dependant without email is actually linked to the intended household.

The importer reports imported, updated, skipped and row errors. Reconcile those totals to source rows; inspect existing-email duplicates and household conflicts before re-running. Keep a dated migration log, preserve a secure backup and do not retire the spreadsheet until the committee has checked record counts, plans and open financial work.

Download the fictional CSV import sample Download the membership-data checklist Member database feature

Good to know

Common questions

Does every imported member need an email address?

The importer requires first and last names. Email is required for ordinary member rows, but may be blank for a row explicitly mapped as a dependant/dependent with a household name.

Can the CSV create membership plans?

No. Membership-plan values are matched to plan names already configured for the organisation; the file does not create plans.

Can an import update an existing member?

The importer identifies duplicates using lowercased email and offers skip (the default) or update behavior. Review mappings and choose deliberately before importing.

Take it with you

Useful downloads

Download the fictional CSV import sample

Open or download

Download the membership-data checklist

Open or download

Ready when you are

Bring the club admin into one clear place.

Member records, renewals and household access—plus practical guidance when you need it.

Get started