Switching beauty-and-wellness software in 14 days without losing bookings

You don’t have to lose a single appointment to switch platforms. The studios that pull this off cleanly don’t have a secret — they have a plan, a parallel-run window, and a one-day cutover that fits inside a calmer week of the year.

This guide is the playbook we hand to migrating studios. It assumes you currently run a booking-and-payments tool that you’ve outgrown and want to move to a single platform that handles scheduling, payments, clients, memberships, and marketing in one bill.

It’s not a sales pitch. It’s the order to do things in, the data to ask for, and the failure modes to plan around.

Why 14 days

A two-week window is the sweet spot. Less than that and you don’t have time to validate imports, train staff, and run one parallel weekend. More than that and the dual-system overhead (people forgetting to check both calendars, payments split across two reports) starts costing more than the switch itself.

A solo provider can compress this to 5–7 days. A medspa with consents, memberships, and multi-provider chairs may need three weeks. Adjust the calendar; the order doesn’t change.

Pick your cutover week

Before anything else, pick the week you’ll cut over. Aim for:

• A week with at least one slow day midweek
• No major holiday, no industry event, no school break
• A staffing roster that includes your most-senior front-desk person
• A week before payroll close, not on or after — so reconciliation lives inside one period

Block the cutover day on the calendar. Tell your team. Tell your clients with a small heads-up two weeks out: “We’re upgrading our booking system. You won’t see anything change — your appointments are all kept and your loyalty stays put.”

Day 1–3: Export everything

Pull every export your current vendor offers. You’re not committing to anything yet — you’re collecting evidence. The exports you’ll need:

1. Clients — every record, including phone, email, birthday, notes, tags, lifetime value if available, signed consent dates, and allergy/health-history fields.
2. Services — every service, with duration, price, deposit policy, and which providers can perform it.
3. Providers — every staff member, their roles, their pay rates if applicable, and their commission rules.
4. Schedules — provider working hours, blocked time, recurring blocks.
5. Appointments — past 12 months (for client history) and future bookings (everything not yet served).
6. Payments — past 12 months of transactions for reconciliation, plus any open invoices, deposits held, gift card balances, and package balances.
7. Memberships — current member roster, plan, next renewal date, billing status.
8. Forms and consents — intake-form templates, completed forms (last 24 months minimum).

If a vendor doesn’t give you a clean CSV for any of these, ask for read-only API access. If they refuse both, that’s a flag — you’ll be paying a “switching tax” of someone manually re-keying data later. Build that into your timeline.

What to do if you can’t export memberships cleanly

Memberships are the most painful migration object because they have a billing history and a renewal cadence. If your current vendor doesn’t export them:

• Pull the member list manually (name, plan, next renewal date, credit card on file).
• Pause auto-billing on the old platform for migrated members two days before cutover.
• Re-create members in the new platform with the same renewal date.
• The first month after cutover, audit every renewal to confirm it hit the right card and the right amount.

Day 4–6: Set up the new platform

While your migration data is being normalized, you should be setting up the destination in parallel — not waiting for the import.

Order of setup:

1. Business profile — name, address, hours, time zone.
2. Service menu — services, durations, prices, deposits. Get this right before staff. Services are the foundation.
3. Providers — staff members and their service capabilities, working hours, commission rules.
4. Booking rules — buffers, online-booking visibility, deposit policy, no-show policy.
5. Payment processor — connect your Stripe account or set up a new one. Verify it can process a $1 test charge.
6. Forms — recreate consent and intake forms; you’ll attach them to services in the next step.
7. Memberships and packages — set up plans, recurring tiers, credit accounts.
8. Communication templates — appointment confirmations, reminders, follow-ups.

Skip anything you don’t actively need on day one. Reports, deep marketing automations, integrations — those land in week two.

Day 7: Import clients and services

This is the highest-risk day in the project. Watch for:

• Duplicates — same person under two emails, or a typo’d phone number creating two records.
• Garbled characters — names with apostrophes, accents, or non-Latin characters. Spot-check the import.
• Lost tags and notes — soft data (preferences, allergies, who-likes-who) is what your senior staff cares most about. Validate a sample of 20 high-value clients manually.
• Wrong consents — if signed-consent dates don’t migrate, your medspa-side service menu may demand re-consent at the next visit. Plan for that.

After importing clients and services, run a small live test:

1. Pick a real test client (yourself, your manager, a friend).
2. Book them in the new system as if it were live.
3. Take a real $1 deposit through real payments.
4. Confirm the confirmation email lands.
5. Cancel the test booking and verify the refund.

If anything in that loop fails, fix it before importing future appointments.

Day 8–10: Import schedules, appointments, and memberships

This is the part where the parallel-run window starts.

Import future appointments — every booking from cutover day forward goes into the new system. You may need to do this twice: once during this window, and once on the morning of cutover to capture any last-minute bookings on the old system.

Import past appointments for client visit history — these are needed so client profiles show the right last-visit dates, rebook cadence, and lifetime value. They don’t need to be perfect; they need to be present.

Activate memberships with the same next-renewal date as the old system. Confirm the renewal will hit the right amount on the right day before you pause the old vendor’s auto-billing.

Now you’re in parallel-run: bookings can be created in either system. Train your front desk to:

• Default to the new system for all new bookings.
• Use the old system for lookups only.
• Mirror any edits made in the old system (rescheduling, cancellations) into the new system within the same day.

Day 11–12: Parallel-run weekend

Pick a Friday–Saturday or Saturday–Sunday for the parallel run. The whole team takes new bookings in the new system. The old system is read-only for the team — only used to confirm a past detail.

At the end of the parallel weekend, you’ll have:

• A short list of friction points (the new payment terminal is in a different spot, the calendar view defaults differently, etc.) — fix these Monday morning.
• High confidence that the new platform handles your real-world bookings.
• Two days of revenue you can reconcile against to make sure the numbers add up identically.

If the reconciliation doesn’t match, stop. Don’t cut over until you understand why. Most often it’s a tip-tracking difference or a gift-card redemption that was logged in one place and not the other.

Day 13: Cutover

Cutover is a 2-hour task, not a 12-hour task, if you’ve done the prior steps.

Morning of cutover:

1. Final export from the old system at 7 AM (or before opening) — appointments, payments, any new bookings since last sync.
2. Import the delta into the new system.
3. Update your booking link everywhere it lives — your website, your Instagram bio, your Google Business profile, your email signature. Search “estheticsense” + your booking-link references and update each one.
4. Activate online booking in the new system; deactivate in the old.
5. Switch any active integrations: Google Calendar sync, Mailchimp, accounting software.
6. Test one live booking end-to-end as a client would.

Tell your team it’s done. From this moment, the old system is read-only. Anyone defaulting to it gets a friendly correction.

Day 14: First-day-live audit

The day after cutover, run a deliberate audit:

• Are all confirmation emails landing? Send a test from each service.
• Are reminders firing 24h ahead? Check tomorrow’s appointment list.
• Are the right tips routing to the right providers? Pull one closing-day report.
• Are memberships still scheduled to renew on the right day with the right card?
• Are the right consent forms appearing at the right service-booking step?

Anything off this list is a same-day fix. Past day 14, you’re in business-as-usual, not migration.

Risks worth pre-planning

A short list of things that go wrong, ranked by frequency:

A client books the same service in both systems. Mitigate by setting the old system’s online booking to “offline” three days before cutover. Front-desk does manual phone bookings into the new system for those three days.

A payment refund needs to be issued from the old vendor. Refunds for anything paid before cutover go through the old system. Keep the old account active and read-write for at least 90 days for this exact reason.

Memberships double-bill on cutover day. Pause auto-billing on the old vendor for any migrated member two business days before cutover. Confirm each pause manually.

Reports don’t match. First-month reports will look strange because the data is half in the old system. Plan to do an end-of-month reconciliation manually for the cutover month, then trust the new system from month two.

Staff forget the new login. Send credentials in writing two days before cutover. Have a printed quick-reference at the front desk for the first week.

What to do on day 30, day 60, day 90

By day 30 the new platform should feel native to your team. The “muscle memory” complaints stop. Anyone still defaulting to the old workflow needs a check-in.

By day 60 you should be using at least one capability you couldn’t use before — automated rebooking nudges, member-only pricing, package balances at checkout — because that’s what justified the switch.

By day 90 you can cancel the old vendor. Pull one more full export for the archive, confirm no outstanding refunds or open balances, and close the account. Most studios save more in month two and three from the consolidation than they spent on migration time.

The shortest version of this guide

If you read nothing else above:

1. Pick the cutover week.
2. Export everything from the current system.
3. Set up the new platform in parallel.
4. Import services and clients first; validate manually.
5. Import schedules and memberships; start parallel run.
6. Run one parallel weekend.
7. Cut over on a calm midweek day.
8. Audit the next day.
9. Keep the old account active for 90 days for refunds.
10. Cancel at day 90.

That’s it. No magic, no luck — just the order to do things in.