Your Salon Data Imported Successfully. How Do You Know Nothing Was Lost?

I began with the most reassuring migration scenario: the import message says “successful.”

That is the moment a salon owner would expect to relax. The difficult work of deciding what the salon required and narrowing the software field to candidates that could pass those requirements is already done. The files are prepared. The progress bar reaches the end. The new system accepts them.

So I wrote down the first check I would run: search for one regular client whose complete history is already familiar.

Suppose her profile appears twice—one copy with the phone number and another with the appointment history. Neither record is obviously wrong on its own. The problem becomes visible only when both are compared with what the complete client should look like.

“Complete” described the job, not the business

I had treated the import message as a verdict. The official instructions made it look more like a status.

Fresha’s client-import documentation describes column matching, ignored columns, invalid rows, and duplicate detection. Square’s customer-import guidance separates results into new profiles imported, rows matched to existing customers, and rows that failed. Those are useful controls. They also show that one import job can contain several different outcomes. (Fresha client import; Square customer import, accessed August 13, 2026.)

“The job finished” could therefore coexist with “some rows failed,” “some fields were ignored,” or “some people were matched to records already present.” None of those outcomes automatically meant disaster. They meant I needed the result report, not just the green message.

My first question changed from “Did the import run?” to “What exactly happened to every expected record?”

The same total could hide a different client list

The obvious check was a count. If the old system held 1,000 clients and the new one held 1,000, it would be tempting to call the client migration balanced.

A simple counterexample made the weakness visible: one missing client and one duplicate still produce 1,000 rows.

Square and Fresha both document duplicate-handling behavior in their current customer tools. Their rules are not identical, which was precisely the point: identity is a decision, not merely a row count. A shared phone number might indicate one person, a family contact, or a reused business number. A changed email might be the same client rather than a new one. (Fresha duplicate handling; Square customer profiles, accessed August 13, 2026.)

I needed to compare stable identifiers where they existed, then review the ambiguous people separately. Counts became the opening check, not the acceptance decision.

A row could arrive without the relationship that made it useful

Once the client list looked plausible, the next check would open appointments, notes, staff assignments, and services.

That exposes a second assumption: if all the pieces are present, the business has survived.

But an appointment is not just a date and time. It belongs to a client, a service, a staff member, often a location, and sometimes a deposit or payment. A note matters because it belongs to the right client or visit. A package balance matters because its owner and redemption history remain understandable.

Fresha’s official Data Connector documentation illustrates this structure directly: booking records use identifiers that connect appointments with clients, locations, team members, and services. That documentation describes Fresha’s current analytical tables. It does not prove that a standard export or another product’s import preserves those relationships. It does show why checking isolated rows is too weak. (Fresha Data Connector tables, accessed August 13, 2026.)

This was why the exit inventory had included connected records rather than only a client spreadsheet. During migration, that inventory became the expected population: the list of objects and relationships the new system had to account for.

Familiar values could return with different meanings

The next checks were harder to see.

A status labelled “cancelled” might include or exclude late cancellations. A future appointment might arrive in the correct month but the wrong timezone. A consent field might be present without the source, date, or scope that made it defensible. A blank value might mean “none,” “unknown,” or “not imported.”

Official import documentation provides concrete warnings about transformation. Fresha says unmatched columns are ignored during its client import. Square warns that spreadsheet software can remove leading zeroes or convert identifiers into scientific notation, and its item-import documentation notes that some relationships and reporting settings require separate configuration. These are examples from specific workflows, not evidence that every migration behaves this way. They show why values must be checked for meaning as well as presence. (Fresha client import; Square import troubleshooting; Square bulk item import, accessed August 13, 2026.)

The safer record would place each important source state beside its target state. If one became another, the mapping would need an explanation. If no target state existed, the difference would need a disposition—not a guess.

Money refused to accept an approximate answer

Client notes could be sampled. Money required a tie-out.

Deposits, gift cards, package balances, credits, refunds, disputes, tips, and unpaid amounts were not interchangeable totals. Two systems could display the same overall balance while assigning it to different clients or states.

I could not verify any real salon’s financial migration from public documentation, and this article does not claim to. The evidence would have to come from that salon’s source ledger, processor records, accounting references, target records, and exception report.

The practical test became narrower and stronger:

• reconcile totals by state, not only in aggregate;
• trace selected balances to the correct client and originating transaction;
• separate imported history from newly created activity;
• explain every difference before treating it as accepted.

That was the point where “close enough” stopped being a migration result.

The exception list became more important than the success message

At first, errors felt like evidence that the project had failed. Then I noticed that a visible exception was safer than a silent transformation.

Square documents partial item imports that can accept some entries and produce a downloadable error report for others. Fresha documents downloading invalid client rows, correcting them, and re-uploading the subset. Those mechanisms do not prove completeness, but they preserve something essential: an accountable list of what still needs attention. (Square import troubleshooting; Fresha client import, accessed August 13, 2026.)

I stopped trying to make the exception count reach zero by any means. Each difference needed one of three outcomes:

• resolved and rechecked;
• accepted deliberately, with an owner and deadline;
• unresolved and therefore blocking migration completion.

UNKNOWN could not quietly become PASS.

The proof was a small package of records

By the end, the migration result was no longer a screenshot of a green banner. It was a compact evidence package:

1. a dated source baseline;
2. the target extracts taken after import;
3. the import and invalid-row reports;
4. identity and duplicate decisions;
5. relationship and state checks;
6. operational and financial reconciliations;
7. an exception ledger showing what was resolved, accepted, or still blocked.

The decision rule became simple:

Mark the migration VERIFIED only when the required records and relationships reconcile to the declared thresholds and every material exception has a disposition. Mark it CONDITIONAL when an accepted exception still has an owner and deadline. Otherwise, it is NOT VERIFIED.

That rule did not make migration effortless. It made the conclusion inspectable.

Here is the question I would now copy into a search or AI tool:

My salon software says the import succeeded. What source-to-target checks would prove that client identities, future appointments, notes, consent, deposits, credits, gift cards, and payment history survived correctly?

One boundary remained. Verified data continuity did not prove that reception, stylists, managers, and clients could complete their real work in the configured system.

So the next question was no longer about the files:

Before we sign off and go live, how do we prove that the configured salon operation actually works?

Sources

• Fresha Help Center, Import your existing client list, accessed August 13, 2026.
• Fresha Help Center, Data Connector tables, accessed August 13, 2026.
• Square Support, Add new customers to Customer Directory, accessed August 13, 2026.
• Square Support, Troubleshoot item library importing, accessed August 13, 2026.
• Square Support, Bulk import items, accessed August 13, 2026.
• Square Support, Edit, merge, or delete customer profiles, accessed August 13, 2026.