CRM Migration Without Losing Customers: A Checklist

Most owners put off a CRM migration for the same reason: the old system holds every customer, every note and every future booking, and losing one of them feels worse than living with software that no longer fits. The fear is reasonable, but most of what goes wrong in a CRM data migration goes wrong in a few predictable places, and each can be checked before it costs you a customer. This checklist covers how to migrate to another business system without losing customers, history or bookings, whether you are leaving a booking app, a sales CRM or a spreadsheet. Work through the steps in order.

1. Export everything before you change anything

Before you cancel a subscription, create the new account or clean a single row, take a complete copy of what you have. Exports are the one part of a migration you cannot redo once the old system is gone. One file per record type:

• Customers, with every column the tool will give you, including the ones you think you do not need.
• Appointments or jobs, past and future, with the customer, the worker, the service, the start time and the duration.
• Notes and activity history.
• Files and photos attached to customers or jobs. Many tools have no bulk file export; check before you assume.
• Invoices and receipts as PDFs.
• Your services and prices, plus the settings that are hard to remember: working hours, cancellation rules, intake questions, message templates.

Where the export lives, as of September 2026, varies by tool. Google Sheets: File, then Download, then Comma Separated Values, one sheet at a time. Excel: File, then Save As, type “CSV UTF-8”. HubSpot: the Export action in the contacts table menu. Pipedrive: Settings, then Export data. Zoho CRM: Setup, then Data Administration, then Export. Booking apps such as Square Appointments and Fresha export the customer list from the customer directory, and appointment history often only as a report, so run it for the widest date range allowed.

Ask for CSV or XLSX, never PDF, for anything you intend to import, and count the rows in every file against what the old system shows on screen. An export that silently stopped at 1,000 rows is a common trap, and far easier to notice now than after you have canceled.

2. Decide what not to move

Reasonable candidates to leave out:

• Customers with no contact details, no visits and no notes. They are placeholders, not people.
• Test records, and the “Walk-in” or “Unknown” customer a booking app forced on you.
• Canceled bookings older than a year or two, unless you use cancellation history to decide who pays a deposit.
• Fields that were never filled in. A “Referral source” column that is empty in nine of ten rows is not data.
• Marketing lists you no longer send to, especially contacts who never consented to be messaged.

“Not migrated” does not mean “deleted”: whatever you leave out still lives in the export from step 1.

3. Clean the export in a spreadsheet

Do the cleaning in a spreadsheet, not in the new system. Every import tool we have used, ours included, does better with a tidy file than with a raw dump. If your source is already a spreadsheet, this is where most of the work happens; our guide on moving from a spreadsheet to a workspace covers the layout in more depth.

• One record type per tab: customers in one, appointments in another, notes in a third. A tab that mixes customers and their bookings on the same rows cannot be imported cleanly by any tool.
• One header row with plain names, no merged cells, no blank rows above it. “Phone” beats “Phone (mobile, for SMS!)”.
• One date format for the whole file. Pick ISO (2026-09-01): it is unambiguous, sorts correctly and every importer reads it.
• One phone format, ideally with the country code (+1 415 555 0134), with “Tel:” prefixes and “(home)” notes moved to their own column.
• Keep the old system’s ID column. It ties customers to appointments and notes in step 6, even if you never display it again.

Save the cleaned workbook under a new name and leave the raw export untouched.

4. Map every field to its new home

Field mapping is the step a CRM migration checklist most often skips, and it is why “the import worked but half the data is in the wrong place” is such a common complaint. Before you import, write down, column by column, where each field goes. For a salon leaving a booking app:

Old column	New field	Note
Client name	Customer: Full name	Split into first and last if the new system has two fields
Service booked	Appointment: Service	Must match the service list you create first
Staff	Appointment: Worker	Must match a worker who exists in the new system
Start	Appointment: Start time	Date and time together, one timezone
Client ID	Customer: External ID	Hidden field, used for linking

Ifa handles this step differently from a fixed template. You describe the business in plain words, Ifa proposes the records, fields, relationships and views, and you check the plan before anything is created. Do the mapping before you approve that plan, not after, so the fields fit your export rather than the other way round.

5. Handle duplicates before the import, not after

Every system used for a few years contains duplicates. Merging after the import is slow, because by then each copy has appointments and notes hanging off it; merging in the spreadsheet is quick.

1. Sort the customer tab by phone number and scan for adjacent rows that match. Phone is usually the most reliable key.
2. Sort by email and do the same, then by last name and first name to catch pairs with a different phone and no email.
3. For each pair, keep the fuller row, copy any notes across, and record the discarded row’s old ID next to the kept one, so appointments that pointed at it can still be linked.
4. Mark true duplicates in a “Merge into” column rather than deleting them, so the decision stays visible and reversible.

Some import tools run their own duplicate check. Ifa’s import previews the file and flags probable duplicates, empty values and unreadable dates before anything is written, and you approve the import after reading the checks. That is a useful safety net, not a substitute for this step: a tool can flag what looks alike, but it cannot know that “Chris Park” and “Christina Park” are the same regular.

6. Import in the right order

Records that reference other records must come after the records they reference. Getting the order wrong is the most common cause of appointments that arrive with no customer attached.

1. Workers and staff. Appointments will reference them.
2. Services or job types, with durations and prices.
3. Customers, with the old ID in a dedicated field so later files can find them.
4. Notes and history that reference customers.
5. Past appointments and jobs, which reference everything above.
6. Files and documents, attached to the customer or job they belong to.

Import a sample of twenty customers and their appointments first; fixing twenty records is painless. Then run the full file. Ifa’s import, described on the import your data page, accepts CSV, TSV, JSON, JSONL, XLSX, XLS and inert XLSM files, shows a preview with the checks, and waits for your approval before creating records. Most booking apps offer no import for appointment history at all.

A note on files. Ifa keeps uploaded files attached to the record they belong to, with a preview, as described on the customer files page. Ifa does not produce invoices itself, so the PDFs from step 1 are the invoices; attach them to the customer or keep them in your accounting tool, but do not leave them only in the old system.

7. Set working hours, then re-create future bookings

Future bookings get their own step because they are the part of a migration customers actually notice.

1. Set working hours per worker, including planned days off, and set booking policies: buffers, minimum notice, cancellation window.
2. Only then load or re-create the future bookings. Loaded before hours exist, bookings are refused or land in slots nobody staffs.
3. Print the old calendar for the next eight weeks and tick off each booking against the new one, by hand. It takes a few hours for most shops and is the most valuable check in the whole migration.
4. Watch for timezone shifts. An export in UTC imported as local time moves every appointment by several hours, and a screen that shows only the date will not reveal it.

If future bookings are few, re-creating them by hand is often faster and safer than importing them. In Ifa, bookings are created, rescheduled, canceled and completed by your team inside the workspace, with availability checked against the hours you set, and customers can book through a booking page Ifa creates or in chat on a connected channel. Ifa has no Google or Outlook calendar sync, and reminders are a workflow you define rather than a switch, so set the reminder workflow up in week one and point your site’s booking link at the new page as part of the cutover.

8. Run both systems for a short overlap

Do not switch on a Friday and cancel the old subscription on Saturday. Keep both running for one to two weeks, the new one as the source of truth and the old one read-only.

• Every new booking and every new customer goes into the new system only. Writing to both doubles the work and guarantees drift.
• The old system stays open for lookups: a note you forgot to migrate, a photo, an old invoice.
• At the end, take one final export for anything created in the old system by mistake, and fold it into the new one.

Ifa has no live two-way sync, and we would not recommend one from any vendor for a two-week overlap; “new system only” is the simpler rule.

9. Tell customers what changes

Most of a migration is invisible to customers and should stay that way. Tell them only what changes for them, and tell them before it happens.

• If the booking link, phone number or messaging channel changes, send the new one a week ahead and again on the day.
• If reminders will stop or come from a different sender, say so and ask them to save the new number.
• If you hold consent records, keep the evidence with the customer file rather than asking everyone to consent again.

Keep it short. “From September 15 we are using a new system for appointments. Your existing bookings are unchanged. To book, call or message us at the same number as always.”

10. Keep the old export as a file

When the overlap ends and the subscription is canceled, do not delete the exports. Put the raw files from step 1, the cleaned workbook from step 3, the mapping table from step 4 and the final overlap export from step 8 in one folder, name it with the date, and store it somewhere that survives a laptop failure. You will use it more than you expect. An archive costs nothing. Rebuilding one is impossible.

What goes wrong and how to avoid it

Failure	What it looks like	Prevention
Truncated export	Row count on screen is higher than in the file	Count rows before cleaning; ask support for a full export
Mixed date formats	Appointments land on the wrong day or month	One ISO format across the whole file before import
Timezone shift	Every appointment is off by the same number of hours	Import one sample booking and compare the clock time
Orphaned appointments	Bookings with no customer attached	Customers first with the old ID, appointments second
Merged duplicates lose history	Notes vanish when two customers become one	Merge in the spreadsheet with a “Merge into” column
Hours set after bookings	Future bookings rejected or placed in unstaffed slots	Working hours and policies first, bookings second

Be honest about scope. If you are moving several thousand customers with years of history and a large photo archive, the steps hold but the time estimate does not, and a freelancer for the spreadsheet cleaning is money well spent. Ifa does not offer a paid migration service, so with Ifa that work is yours or a contractor’s, supported by the preview and checks in the import. Some other vendors offer assisted migration on higher tiers; ask before you commit if your data is large.

Questions people ask

How long does a CRM migration take for an owner-led team?

For a two-chair salon, a four-person cleaning crew or a solo consultant with a few hundred customers, the exports and cleaning take an afternoon, the import and booking check take another, and the overlap runs one to two weeks in the background. Larger histories scale with the cleaning step, not the import.

Should I switch CRM at a quiet time of year?

Yes, if you have one. Fewer future bookings means a shorter check in step 7, and fewer walk-ins makes the overlap easier to police.

Can I migrate appointment history, or only customers?

It depends on what the old tool exports. Most sales CRMs export activities in full. Many booking apps export the customer list readily but expose history only as a report. If history will not export cleanly, migrate customers with at least a “Last visit” and “Visit count” column so the new system knows who your regulars are, and keep the old report as the archive.

Do I have to ask customers for consent again after switching CRM?

Generally no, if the consent was collected lawfully and the record of it moves with the customer. What matters is that you can still show who consented, to what, and when. Bring the consent field and its date across, and keep the original export as evidence. If the old tool never recorded consent, treat that as a gap to fix in the new system rather than something the migration caused.

Last updated September 2, 2026.