Switching booking or membership software? How to preserve your customer history

A platform switch should not reset your understanding of the customer.

Before moving systems, preserve the records that let you understand who a customer is, how their membership changed, when they attended, and what happened before and after they joined. Where the data exists, that may also include guest or trial activity and transactions that can be associated with the customer.

The practical test is simple:

After the switch, could you reconstruct one customer’s history from the information you kept?

You do not need every historical record displayed inside the new platform to preserve that understanding. You do need to know what has been preserved, where it is available for reconstruction, and what remains uncertain.

A migration and a split system need different checks

A platform migration is an intentional move from one system to another. Check what can be exported, what the destination can import, and what will remain available separately. Preserving a file and making its contents usable in the new platform are separate tasks.

With split systems, different parts of the customer journey live in different places: billing in one tool, attendance in another, and guest or trial activity somewhere else. Check which source holds each record and what evidence allows those records to be associated with the same customer. Identifiers may differ between systems.

The two can coexist.

You might change your booking platform while keeping your payment system. In that case, check both the transfer of booking history and how you will reconstruct the customer’s journey across the systems that remain.

What history should you preserve?

Start with the questions you want to answer afterward.

Use this as a preservation checklist, not as a universal minimum that every export must satisfy.

• Customer identity — What to look for, where available: Original customer IDs, source-system names, relevant identifying attributes, and confirmed mappings between old and new records. What it helps you understand: Whether records refer to the same person, and which matches remain uncertain.
• Membership history — What to look for, where available: Membership or package identifiers, type, original start date, changes, status history, and cancellation or end dates. What it helps you understand: How the customer’s relationship with the business developed.
• Visits and attendance — What to look for, where available: Dated activity, class or location, and booking, attendance, or cancellation status. What it helps you understand: What the customer booked and what the records show they actually attended.
• Guest and trial activity — What to look for, where available: Guest identifiers, offer or trial information, dated activity, and any recorded relationship to a later membership. What it helps you understand: What happened before membership, without assuming every guest can be matched to a member.
• Transactions — What to look for, where available: Transactions with identifiers or attributes that allow customer linkage where available; dates, amounts, transaction types, and statuses. What it helps you understand: Payment context alongside the customer journey, where the relationship can be established.
• Record context — What to look for, where available: Source, export date, date coverage, filters, field definitions, and the dates systems changed. What it helps you understand: What each file includes and the limits of any reconstruction.

Preserve distinctions as well as values.

A booking is not evidence of attendance.

A current membership status does not, by itself, describe every earlier status.

A new system’s record-creation date should not be assumed to be the customer’s original joining date.

If a field is unavailable, record that limitation. Do not fill it with an inferred event just to make the history look complete.

Your practical pre-switch checklist

1. Map where the history lives

List the systems holding customer, membership, visit, guest, and transaction records.

For each, note:

• the available date range
• who can obtain the records
• whether access will continue after the switch

For split systems, include the tools you are keeping. Their records may still be needed to understand activity on either side of the change.

2. Inspect sample exports before committing to the transfer

If possible, request sample exports before committing to the transfer and examine what they actually contain.

Ask the destination provider which fields and historical records it can import, and how you will access anything it cannot import.

Check the export filters:

• Does the file include former members as well as current ones?
• Does it cover the dates you need?
• Does it contain status history or only the latest status?

Keep a note of the answers alongside the files. An export’s filename alone will not explain its coverage.

3. Preserve original identifiers and confirmed mappings

Keep the original source IDs, including the system each ID belongs to.

If the new platform assigns different IDs, request or document a mapping between the old and new records where one can be established.

Do not assume matching names identify the same person.

Leave uncertain matches visible for review rather than forcing them into a single customer history.

Where several people share contact details or one person pays for another, preserve any explicit relationships the source provides.

4. Record the changeover and the meaning of the fields

Note when each system stops or starts recording activity.

If the transition is phased, record the relevant dates for each source.

Keep the meaning of important fields:

• whether a date means booking, attendance, payment, or membership start
• whether a status means active, frozen, or cancelled
• any timezone information supplied with timestamps

Different labels should not silently become the same event during reconstruction.

5. Decide what will be imported and what will be retained separately

Make an explicit plan for history the destination will not import.

Record:

• where the preserved files will be kept
• who will have access
• how someone can locate the relevant customer records later

Keep original exports alongside any transformed copies so you can refer back to what the source supplied.

Store preserved exports securely, limit access to people who need them, and follow your business’s applicable privacy and data-retention requirements.

Preserving history does not require pretending it all lives in one application.

6. Reconstruct one customer’s history before the cutover

Choose a customer whose available records include more than a current active membership.

A useful example might include:

• a trial
• a membership change
• visits
• a payment

Using the sample exports and any test import, answer:

• Can you identify the customer’s original record and any corresponding new record?
• Can you find their original membership start and subsequent recorded changes?
• Can you distinguish booked visits from attended visits?
• Can you find guest or trial activity, if supplied?
• Can you associate transactions with the customer where the source supports it?
• Can you say which dates or relationships remain unknown?

This is a test of your preservation plan, not proof that every record transferred correctly.

If the reconstruction depends on someone remembering what happened, document the missing information or unresolved relationship before proceeding.

7. Check the final records after the switch

Repeat the reconstruction using the final exports and destination records.

Check the coverage dates and compare the same customer’s history across the changeover.

Where useful, compare record counts for equivalent filters and date ranges. Matching totals alone do not establish that the right history belongs to the right people.

Keep a short list of:

• missing periods
• unavailable fields
• uncertain matches

Assign each an owner for follow-up, or mark it as a known limitation if it cannot be resolved.

Make gaps visible afterward

If you have membership records from January but attendance history only from April, say so when answering questions about that customer’s earlier activity.

The absence of a visit in an incomplete record does not establish that the customer stopped attending.

The same principle applies to membership history: a record missing from an export is not, by itself, evidence of cancellation.

Describe what the preserved information can support.

If the history needed for a particular answer is missing, keep that answer qualified or unresolved rather than inventing continuity.

The TailorLoom point of view

TailorLoom’s point of view is that customer history should remain useful even when the systems around it change.

Persistent business memory means preserving enough context to understand the customer journey over time, applying consistent definitions, and being able to investigate the people behind a pattern rather than treating each platform as a fresh start.

Before your next switch, request a sample export and try to reconstruct one customer’s history.

Identify what you can explain, what has been preserved and is available for reconstruction, and what still needs an answer — while you can still act on it.