How to move personal training clients from a spreadsheet to a CRM

What you're actually migrating

A spreadsheet migration isn't moving rows — it's moving from a system that holds a number to a system that holds a history. The difference matters:

• Spreadsheet: "Sessions remaining: 7." Edited by hand. Nobody knows when the 7 became 7.
• CRM: "10-pack purchased 12 Jan, sessions logged on 14, 18, 21, 25, 28 Jan, 1, 4, 8 Feb — 8 used, 2 remaining." Auditable.

You can't migrate the history you never recorded. You can migrate the current state and start the history from today.

Before you import: decide the rules

A spreadsheet lets you be vague. A CRM will make you specific. Answer these before importing a single row, or you'll re-import twice:

• Package types: list every distinct pack you sell (5, 10, 20, unlimited). Collapse near-duplicates.
• Expiry per package: a number of weeks or a date. No "open-ended" — open-ended packs are why you have clients with 3 sessions left from 2024.
• Session deduction rules: 24-hour cancel policy, no-show policy. Decide once, apply to all.
• What counts as the "current balance": the sessions-remaining number from your sheet, as of import date.

Decide these in writing. The CRM will enforce them; your spreadsheet didn't.

The four-column export

Your spreadsheet probably has 20 columns — notes, colours, formulas, a tab for old clients. For import you need four clean ones:

1. Client name
2. Email (the unique key — dedupe on this)
3. Package purchased (mapped to one of your package types)
4. Sessions remaining (the number the CRM starts counting down from)

Drop everything else for the import. Notes, goals and phone numbers can be added to each client record after — they're not blocking data. Import the skeleton, then enrich.

The three migration mistakes

1. Importing the sessions-remaining number as history

The CRM starts with "2 remaining" and counts down from there. It does not know the 8 sessions already used. That's fine — the history starts today. Don't try to backfill past sessions; it's not worth the time and the audit trail only matters going forward.

2. Keeping the spreadsheet "just in case"

The moment you import, stop editing the spreadsheet. If you keep both, the two will drift within a week and you'll have two sources of truth, which is worse than one bad one. Export the CSV, keep it as a backup file, never touch it again.

3. Not setting expiry dates on import

Importing a 10-session pack with no expiry recreates the exact problem the spreadsheet had. Set the expiry based on the package rule you decided above, calculated from the purchase date you can estimate. An estimated date is better than none.

The first-week test

For the first week, log every session in the CRM and nowhere else. The migration only sticks if the spreadsheet leaves your daily workflow immediately. By day seven you'll have found the clients whose imported balance was wrong — fix those individually, don't re-import. By day fourteen the CRM is your system and the spreadsheet is a file on your desktop.

What you get that the spreadsheet never gave you

• Renewal alerts at 14, 7 and 1 day before expiry — no more lapsed packs.
• An at-risk list of clients with sessions left but no booking in 10 days.
• A disputed-count answer in 10 seconds: "here are the eight logged sessions."
• One balance, calculated, never typed.

See the deeper guide in how to manage personal training packages and why the structure matters in why replace spreadsheets with a gym CRM.

Final thoughts

Migrating is a one-evenight job, not a project. Export four columns, decide your package rules, import, and stop touching the spreadsheet the same day. The hard part isn't the move — it's committing to one system. Start the migration with the package tracker or the personal trainer CRM.