Team & operations16 min read

What should a lash and brow studio test before switching booking software?

A practical switching checklist for lash and brow studios, covering bookings, client records, photos, forms, deposits, artists and payments.

OpenChair1 September 2026

On this page

What should a lash and brow studio test before switching booking software?

Changing booking software is easy if all you need to move is a service list.

A working lash and brow studio usually has much more attached to the system.

There may be future appointments, client notes, forms, private photos, patch-test records, deposits, artist schedules, commission rules, booking links and payment settings.

That means the useful question is not:

Can we import our clients?

It is:

Which parts of the studio need to keep working on the day we switch?

Start there.

Write down what the current system is holding#

Before choosing a replacement, make an inventory.

For a lash and brow studio, that might include:

client names and contact details;
future appointments;
previous visit history;
artist notes;
private client photos;
forms;
patch-test records;
services and prices;
artist availability;
deposits;
gift vouchers;
packages or memberships;
commission rules;
product records;
marketing preferences;
booking policies.

You may not need to migrate every category.

You do need to know which ones matter before somebody promises that switching will be simple.

Separate future bookings from historical records#

These deserve different treatment.

A future appointment affects the working diary after the switch.

Historical data gives the team context from visits that have already happened.

If a migration can only preserve one perfectly, future bookings usually deserve particularly close attention because mistakes can affect clients immediately.

Check:

client;
service;
date;
time;
artist;
duration;
price;
booking status;
deposit or payment state where applicable.

Then separately decide how much historical information the studio needs in the new system.

Do not assume every export contains the same fields#

Two salon systems can both offer CSV exports and still export very different information.

One may provide:

clients;
appointments;
services.

Another may also include:

notes;
tags;
forms;
payment references;
communication preferences.

Photos may be exported separately.

Some information may only exist in PDFs.

Some may not have a useful bulk-export path.

Ask to see the actual export before committing to a migration scope.

The file tells you more than a checklist that says "data migration available".

Review the client record field by field#

Client records are especially important in a repeat-appointment studio.

A name and mobile number are only the beginning.

Check whether your current data includes:

visit history;
notes;
preferred artist information;
private photos;
submitted forms;
patch-test records;
future bookings.

Then ask what the new system can reasonably map.

Do not assume a free-text note in one platform can become a structured field in another.

It may remain a note.

That can be perfectly useful, but the distinction should be clear before migration.

Treat private photos as their own migration question#

Client photos are easy to overlook because they may not be part of the main client export.

Ask:

Can the current system export them?
How are they associated with clients?
Is visit/date context preserved?
Can the new platform import that structure?
Are private photos kept private after migration?

Do not assume a folder containing several hundred images can automatically be matched to the right client.

The migration may need filenames, IDs, metadata or a separate mapping process.

If keeping historical private photos is important, put it in the written migration scope.

Keep public portfolio images separate#

A studio may have both:

private client reference photos;
images published as portfolio work.

Do not treat those as one data set.

Private client context and public marketing content have different purposes and consent boundaries.

If portfolio content needs to move too, scope it separately.

OpenChair keeps private client-photo context separate from public portfolio workflows.

That separation should remain clear during migration.

Check forms separately too#

A form template and a completed client submission are different things.

A migration might be able to recreate the form template without carrying over every historical response.

Or it may preserve responses but not reproduce the old form builder exactly.

Ask about:

current templates;
old versions;
completed submissions;
signatures where applicable;
timestamps;
client associations.

Do not accept "forms can be imported" without clarifying which of those things it means.

Treat patch-test records as a distinct record type#

The same applies to patch tests.

A note saying:

patch test passed 4/7

is not necessarily equivalent to a structured patch-test record with its own date, result and review information.

If the studio relies on historical patch-test records, check:

how the old platform exports them;
whether they have structured fields;
whether those fields can be mapped;
whether older entries need to remain searchable.

Do not convert incomplete information into certainty during migration.

If the source does not contain a field, the import should not invent it.

Check what happens to future recurring appointments#

Recurring series need particular attention.

An export may contain the individual future appointments but not the rule that created the series.

For example, you may successfully transfer four upcoming bookings while losing the instruction:

repeat every four weeks.

That can still preserve the immediate diary, but the new system may need a new recurring series created afterwards.

When testing the migration, distinguish:

existing future occurrences;
the recurring-series rule.

Do not assume preserving one preserves the other.

Review deposits before the cutover#

A booking with money attached deserves extra care.

For every future booking with a deposit, identify:

how much has been paid;
what the payment represents;
which booking it belongs to;
whether the funds have already been settled;
how the new system will display or account for that amount.

Moving the booking record does not necessarily move the money.

Likewise, transferring a note such as:

$50 deposit paid

does not create a payment transaction in the new processor.

The financial record and the underlying funds are separate things.

Do not assume saved cards can move#

Saved payment credentials are another major boundary.

A card stored with one payment provider usually cannot be treated like an ordinary client field.

Do not promise that saved payment methods, payment mandates or recurring-payment credentials will migrate unless the providers and migration process explicitly support it.

The safer assumption is that payment credentials require separate verification.

For OpenChair migrations, preserving a financial record does not by itself establish the transfer of saved payment credentials or funds.

Check gift vouchers, packages and memberships separately#

These can have financial value attached.

If your studio uses them, review each category.

For gift vouchers, ask about:

voucher code;
original value;
remaining balance;
expiry;
purchaser;
recipient;
redemption history.

For packages:

remaining services;
package type;
expiry;
client association.

For memberships:

active membership status;
included benefits;
recurring billing;
payment mandate.

A list of active memberships does not automatically recreate the underlying recurring payment arrangement.

Scope these carefully.

Rebuild artist availability deliberately#

Staff schedules often look simple until you try to reproduce them.

Check:

normal working hours;
recurring days off;
breaks;
time off;
service assignments;
individual service durations;
individual pricing where used.

The new system should reflect how each artist actually works.

Do not rely on imported appointments alone to reconstruct the roster.

A full diary can hide an incorrectly configured availability rule for weeks.

Test preferred-artist booking after migration#

A returning client's experience matters too.

If Mia's regulars used to have a direct booking route, what happens after the switch?

OpenChair supports individual Staff Booking Links & QR Codes.

After the new studio setup is ready, make sure:

each artist's public profile is correct;
their services are assigned;
availability is correct;
their new direct booking link works;
old links are updated where possible.

That may involve changing links in:

Instagram bios;
Google profiles;
the studio website;
email templates;
QR codes;
printed material.

The migration is not complete if the database moved but clients are still clicking the old booking page.

Update the studio's main booking route#

The same applies to the venue.

Check:

website booking buttons;
Instagram bio;
Google links where controlled by the business;
social profiles;
email signatures;
automated messages;
QR codes;
printed material.

Decide when those links will change.

Changing them too early can send clients into a new system before the diary is ready.

Changing them too late can keep creating bookings in the old system after cutover.

Plan the moment.

Decide when the old system stops taking bookings#

This is one of the most important migration decisions.

If both systems accept live bookings at the same time, the studio can end up with two conflicting diaries.

A cleaner cutover usually has a defined point where:

the old booking route stops being promoted;
the new storefront becomes the active route;
staff know which calendar is authoritative.

The exact approach depends on the two systems and migration scope.

The important part is to make the authority clear.

One working diary should win.

Keep a reconciliation window#

Do not delete the old system the minute the new one goes live.

Keep enough access to verify the migration according to your contractual and data-retention arrangements.

Compare:

client counts;
future bookings;
service prices;
artist assignments;
deposits;
forms;
key client records.

Pick a sample of real clients and inspect them manually.

Bulk counts can look correct while an important field is wrong.

A short reconciliation period gives the studio somewhere to check the source while issues are being resolved.

Test clients with complicated histories#

Do not test only the easy records.

Choose examples such as:

Client A
Several past visits, notes and photos.

Client B
Future recurring appointments.

Client C
A deposit on the next booking.

Client D
Forms and a patch-test record.

Client E
A package, voucher or other relevant balance.

If those records survive in a useful form, the simple clients probably will too.

Preserve communication preferences#

Client contact data is not only a phone number and email address.

The studio may also have records of:

marketing preferences;
unsubscribe state;
reconnect preferences;
communication choices.

Do not silently treat migrated clients as though they have opted into everything again.

Check which preference data exists in the source and what the new system can accept.

Where the old system cannot provide reliable preference information, flag the gap rather than guessing.

Recreate reminders after the diary is stable#

Booking reminders are important, but they should not be the first thing turned on during an uncertain migration.

Before activating them, verify:

future bookings are correct;
client contact details are mapped;
appointment times are correct;
duplicate reminders will not come from both systems.

If both platforms send reminders during cutover, clients can receive duplicate or conflicting messages.

Decide which system owns communication at each stage.

Connect Instagram after the booking routes are ready#

The same principle applies to messaging.

If the studio uses Instagram heavily, make sure the new booking routes and artist links work before pointing automated or drafted replies towards them.

OpenChair's Inbox supports connected Instagram DMs.

On Pro, Smart Replies can Auto-send eligible, high-confidence Instagram replies for configured intents, while booking actions remain review-first.

Do not connect an automated booking-link response to a route that has not finished cutover.

Messaging should follow the working booking system.

Rebuild booking protection carefully#

Do not assume imported services inherit the deposit policies you used before.

Check the new setup deliberately.

Review:

which appointments require deposits;
percentage or fixed rules where supported;
card-protection rules;
cancellation policy wording;
client acknowledgements.

OpenChair's Booking Protection can apply supported deposit and no-show card rules to the new booking workflow.

Those settings should be verified after the service menu is correct.

The software should reflect the studio's policy.

It should not infer one from the old system.

Check commission rules before the first completed week#

Commission settings are another item that should not be reconstructed from memory after launch.

Document the current rules before switching.

For each artist, confirm:

service commission;
product commission;
any relevant basis;
which work is attributed to whom.

OpenChair supports Commission Tracking for supported service and product commission rules.

It is not payroll.

If the current system also performs payroll or contractor settlement, treat that as a separate requirement when evaluating the switch.

Keep the accounting boundary clear#

Migrating a salon-management system does not automatically migrate your accounting system.

Check how the new product records:

completed sales;
payment methods;
refunds;
deposits;
taxes;
external card payments.

Then decide what needs to flow into the accounting workflow afterwards.

Do not treat an exported transaction history as proof that accounting balances have been transferred correctly.

Financial migration deserves reconciliation.

Use the new system on mobile before launch#

A studio can complete the desktop setup and still discover problems on the first busy day.

Before cutover, test the new setup on the phones and tablets staff will actually use.

Try to:

open today's calendar;
find a client;
review notes;
review a form;
open a future booking;
reschedule;
complete checkout;
take payment where supported.

For OpenChair, relevant working-day workflows are available across supported iPhone and Android surfaces alongside web.

Do not wait until launch morning to discover that the team does not know the new mobile workflow.

Give every artist their own account before cutover#

Avoid using one shared owner login as a temporary migration shortcut.

Create staff access properly.

OpenChair supports Owner, Manager and Staff roles.

For shared studio devices, supported shared-device workflows can preserve staff attribution.

This matters immediately after migration because the studio may need to know who changed a migrated booking or client record.

Update the team before the clients#

The staff should understand the new system before clients start using it.

A short team run-through should cover:

today's calendar;
client search;
booking changes;
notes;
forms;
patch-test records;
checkout;
rebooking;
Instagram or Inbox workflow where relevant.

Do not make the first real appointment the staff training session.

A 20-minute test with realistic sample clients can uncover a surprising number of gaps.

Do not promise a complete migration before seeing the export#

This is the most important expectation to set.

A platform cannot responsibly promise to migrate every field from another system without knowing:

what the source exports;
how those fields are structured;
whether there is a compatible destination;
what needs manual review.

OpenChair's migration service works from the data the salon supplies.

The team can use AI models to assist mapping and consistency checks, then review the results with the salon and correct or rerun the import until the agreed result is ready for cutover.

That is an assisted service.

It is not proof that every field from every provider can be transferred automatically.

Broader migrations should have written scope.

OpenChair's standard service-menu import request has a documented commitment to work on the service import within two business days.

That applies to the service-menu import.

It is not a guarantee that an entire studio migration, including bookings, photos, forms and financial records, will be finished within two business days.

Keep those promises separate.

A narrow commitment is useful when it stays narrow.

Ask for the migration scope in writing#

Before switching, the studio should know what is included.

For a Lash & Brow business, the written scope might specifically address:

clients;
services;
staff;
future appointments;
historical visits;
notes;
private photos;
forms;
patch-test records;
deposits;
vouchers;
packages;
memberships.

If a category is not in the scope, do not assume it is included.

That is better than finding out during cutover that both sides meant something different by "client data".

A practical three-artist switching plan#

Imagine a studio with Emma, Mia and Priya.

The owner decides to switch booking systems.

Before migration they export the current data and document:

three artist schedules;
services and prices;
future appointments;
client records;
deposits;
forms;
patch-test records;
direct artist links;
commission rules.

The migration scope confirms what can be imported and what needs to be recreated.

A sample group of clients is checked after the import.

The team tests the calendar, mobile workflow and checkout.

The studio updates artist links and the main booking URL at the agreed cutover point.

The old diary stops accepting new appointments.

The new storefront becomes authoritative.

For a short reconciliation period, the owner can still check the old records where contractually available.

That is a migration plan.

"Export CSV and hope" is not.

A switching checklist for lash and brow studios#

Before cutover, verify:

Client data#

client details;
visit history;
notes;
private photos;
forms;
patch-test records;
communication preferences.

Calendar#

future bookings;
recurring appointments;
artist assignments;
durations;
prices;
time off.

Services#

service names;
categories;
prices;
durations;
staff assignments;
booking options.

Money#

deposits;
gift vouchers;
packages;
memberships;
payment records;
outstanding balances where relevant.

Team#

individual accounts;
availability;
roles;
commission rules;
artist booking links.

Client-facing setup#

storefront branding;
policies;
deposits;
website links;
Instagram links;
Google links controlled by the studio;
QR codes.

Communication#

confirmations;
reminders;
Inbox;
Instagram connection;
unsubscribe preferences.

Launch#

staff training;
mobile testing;
final reconciliation;
clear cutover time.

If one of those areas matters to the studio, know what happens to it before switching.

How OpenChair approaches switching#

OpenChair separates simple service import from broader migration work.

Service-menu import
The standard request hands the supplied service data to the OpenChair team for managed import work, with the documented service-menu commitment applying to that scoped task.

Broader migration
OpenChair reviews the export and agrees the scope for fields that reasonably match.

AI models may assist with mapping and consistency checks.

The OpenChair team and salon review the result, with corrections or reruns where needed before agreed cutover.

Broader migration scope should be confirmed for areas such as: