Coaching Software Migration Checklist: Test Before Switching

What must move, and what can remain in an archive?

Start with commitments, not file volume. Upcoming sessions, accepted actions, current goals and payment obligations keep the engagement running. Historical material needs a retention and access decision, but it does not all need to become editable content in the new system on day one.

Preserve the coaching baseline as a dated starting position, not as today's value in a newly created field. Keep private session notes separate from shared summaries. A migration that mixes those visibility rules can be more damaging than one that leaves an old document in a secure archive.

The 2025 ICF Code of Ethics addresses secure, confidential handling and disposal of records. Migration does not suspend those responsibilities. Confirm lawful handling, contractual requirements and access arrangements for your circumstances; this checklist is operational guidance, not legal advice.

Successful migration preserves the next client commitment before it preserves the appearance of the old system.

How do you check whether the export is usable?

Request a representative export before committing to the move. Open it and list what each file contains, what its dates mean and which identifiers connect related records. Check whether attachments are included as files or merely linked to the old service. A link that requires a cancelled account is not an independent archive.

Formats serve different purposes. CoachAccountable's client export instructions, checked in 2026, describe readable HTML history with selectable content. That does not imply a destination can reconstruct structured actions from it. Ask the receiving provider which fields and relationships its importer supports.

Spreadsheet exports have their own losses. Microsoft's file-format guidance, checked in 2026, explains that CSV saves displayed text and values from the active worksheet and loses formatting. Export each required sheet deliberately and preserve the original workbook when formulas or additional tabs matter.

Do not treat data portability language as an import guarantee. The ICO's portability guidance, checked in 2026, describes a defined individual right and says it does not require technically compatible processing systems. Commercial migration needs a separate agreement about the actual records and formats supplied.

1. Record source field, destination field, data type and the rule for an empty value.
2. Map client identifiers before importing dependent notes, actions or invoices.
3. Check date formats, time zones, line breaks and non-English names using representative records.
4. Document fields that cannot be imported and decide whether to archive or recreate them.
5. Keep an untouched source export with its export date and controlled access.

Readable history and editable imported records are different migration deliverables.

Which tests must pass before clients are invited?

Choose a small pilot that represents difficult cases, not only your tidiest account. Include a client with a rescheduled session, several open actions, a private note and a shared file. Use invented records for the initial technical checks, then a limited authorised real-data pilot when access controls and handling are confirmed.

Record who checked each result and when. A count match alone is insufficient: 100 notes attached to the wrong client still totals 100. Inspect content and relationships, then have a pilot client confirm that the shared view makes sense without the mentor explaining every field.

For calendar records, Google's export guidance, checked in 2026, describes ICS files and the permissions required to export. An export is only an input to your test. Confirm recurring sessions, changes to individual occurrences and time-zone behaviour in the destination before altering the working calendar.

Matching record counts is necessary; matching ownership, meaning and visibility is what makes the move usable.

How should you switch an active coaching practice?

Choose a switch window with enough time before the next session to resolve access problems. Tell clients what changes, what stays the same, where their next session will appear and how to contact you if access fails. Do not ask them to maintain the same actions in both systems.

1. Name the migration owner and record the go-or-no-go decision after pilot tests pass.
2. Take a final export and record the last source update time.
3. Pause source automations that could send duplicate invitations, reminders or invoices, using a checked inventory.
4. Import the remaining agreed records and reconcile changes made since the pilot.
5. Invite clients in manageable batches and confirm access before their next commitment.
6. Make the new system authoritative for agreed record types; keep the old system as a controlled reference.

Treat payment migration as a separate workstream. Identify where existing subscriptions actually live and who is authorised to change them. Moving a client profile is not permission to recreate a recurring charge. Reconcile the next collection date, existing invoices and provider identifiers before enabling any new billing automation.

For MentPass, current plan information distinguishes direct file downloads from a packaged workspace export available on request. Import support varies by plan. Booking links remain external, Google Calendar sync is native, and eligible plans support Stripe Connect invoicing and subscriptions. Confirm the exact migration deliverables instead of assuming every record has a self-service importer.

A switch needs one authoritative record for each kind of work.

What makes rollback practical?

Set rollback triggers before the move. Examples include cross-client exposure, missing active commitments or an unresolved payment risk. Minor formatting differences can be repaired after switching if they do not affect delivery, but the owner should document that judgement rather than quietly accepting every defect.

A rollback plan must cover new work. Keep a change log of sessions, actions and payment events created after the final source export. If you return to the old system, reconcile that log before restarting its automations. Otherwise, rollback restores yesterday's software while losing today's client commitments.

Reverting the application does not unsend an email, reverse a payment or recall a shared file. Handle those effects explicitly and communicate corrections to affected clients. Retain necessary records of the incident and repair, following the applicable agreement and retention requirements.

Close the migration only after the agreed observation period covers normal sessions and a relevant billing check. Confirm archive access, remove unnecessary temporary copies and cancel the old service deliberately. Use the client portal guide to review the client experience once the transfer mechanics are finished.

Rollback must recover work done since the switch, not merely reopen the previous application.