How to Switch Med Spa Software Without Losing Your Client Data

Switching med spa software is mostly a scheduling problem, not a data problem. Your client list, upcoming appointments and service menu usually come out of the old system in a standard export. Charts, photos and signed consents often need someone to carry them across by hand. What actually trips practices up is timing: knowing your notice date before you pick a new system, and rebuilding membership billing dates so nobody is charged twice in week one.
Most owners put this off for years because they assume they will lose their history. In practice the question is not whether your data comes with you. It is which parts arrive in an export, which parts someone carries across, and who does that work. This guide is vendor-neutral. It applies whichever practice software you are leaving and whichever one you are moving to.
One question is worth asking before any of it. Many practices start shopping for new software because they want something on the patient side: an app with their name on it, memberships that bill themselves, a loyalty program patients actually use. That is a reason to add something, and not always a reason to move. If it is your reason, read the section near the end on keeping your current software before you give notice.
The three things that actually matter
Everything else is detail. Get these three right and the rest is logistics.
Know your notice date before you shop. Most software agreements renew on their own and ask for notice before the end of a term. Find that date in your own paperwork first, because it sets your earliest sensible move date. Practices that pick a new system first and read the contract second are the ones who end up paying two vendors for a month or two.
Download your chart archive while you still have access. Charts, photos and signed consents, exported and backed up somewhere you control. Do this early, whatever else happens. It costs an afternoon, and it removes the one truly irreversible risk in the whole process.
Treat memberships as their own project. Saved cards can move between payment processors. The recurring billing schedules attached to them do not, so every active membership has to be set up again with its next charge date checked. This is the step that actually costs money if it is rushed, and it is the one nobody warns you about.
What usually moves in an export, and what someone moves by hand
There are two paths, and knowing which one each thing takes removes most of the anxiety. The table below is what practices typically see. Your old and new vendors can tell you exactly, and you should ask both in writing.
What | How it usually moves | What you do |
|---|---|---|
Client names, contact details, addresses | In a standard export. Almost every system produces this | Check the file opens and the columns make sense |
Service menu and staff records | Often in the export, sometimes rebuilt by hand | Check working hours and commission setup afterwards |
Retail inventory and stock levels | Usually in the export | Time the transfer near go-live so counts are current |
Upcoming appointments | Usually, sometimes with a date limit at the source | Keep an exported forward schedule as a backstop |
Past visit history | Usually, though some systems only release a recent window | Agree how far back you need before the transfer runs |
Gift cards, packages and unused sessions | Balances may move; the transaction trail behind them often does not | Reconcile the totals. This is money owed to clients |
Loyalty points and wallet credit | Varies by vendor, so ask both in writing | Decide how you will honor every balance before you switch |
Membership plans and members | Plans are set up again; members move; billing dates are rebuilt | Confirm every member's next charge date before go-live |
Charts and provider notes | Often as files attached to each client, where the old system will not release them as structured data | Decide how far back matters to you |
Before-and-after photos | Brought across and attached to the client, by hand when needed | Say early if you have a large library |
Signed consent forms | Archived as signed documents on the client | Spot-check a sample after the transfer |
Chart and consent templates | Rebuilt in the new system | Send your current wording to whoever sets it up |
Saved cards on file | Processor to processor, under PCI rules, without passing through anyone's hands | Start the request early. Details below |
Booking rules, policies, discounts | Set up fresh | A short call, not a data task |
The important line in that table is the one that repeats: where an export cannot do it, a person has to. That is the whole answer to "will I lose my history." Nothing needs to be stranded because a file format did not cooperate. It gets carried across by hand instead, and what is left to decide is how much of it there is and who does the carrying. Ask every vendor on your shortlist that second question directly: their team, a paid service, or yours.
What to expect from your charts
This is the part practices ask about most, so it is worth being straight about it.
Structured chart notes rarely move as structured notes between two different systems, because no two platforms model a chart the same way. What usually happens instead is that your history comes across as documents attached to each client, so it is there, it is readable, and it is where you would look for it. What it will not do on day one is feed a report in the new system the way a note written there would.
In practice this matters far less than it sounds. Historical notes are a reference you consult occasionally, not something you run reports on. New notes written in the new system behave normally from the moment you go live. And if there is a slice of history you genuinely need as structured data, raise it while the move is being scoped, so it is handled on purpose rather than discovered afterwards.
The same is true of photos and signed consents. They come with you, attached to the right client, and someone should check that they landed.
Saved cards and memberships: the one fiddly part
Card numbers are portable between payment processors. You never touch them: the old processor sends them encrypted to the new one under PCI rules, and processors publish a process for exactly this. It is routine, and it is not instant, so the request goes in early rather than at cutover.
The recurring schedules do not travel with the cards. Every active membership gets set up again, with its next charge date chosen deliberately. That is the single most common way a switch goes wrong after go-live, and it is entirely preventable: every member gets checked against their old charge date before the first billing run. Ask your new vendor who owns that check, and get the answer before you sign.
A realistic timeline
Step | Who | Move on when |
|---|---|---|
Find your notice date | You | You know your earliest exit |
Download your chart archive | You | Charts, photos and consents are backed up somewhere you control |
Get the move scoped in writing | Your new vendor | You have seen what comes across and what gets rebuilt |
Open the card transfer request | Your new vendor, with your authorization | Both processors have confirmed |
Transfer and check | Your new vendor, then you | A sample of records has been spot-checked |
Team training | Your new vendor | The front desk can book, check out and take payment unaided |
Run both systems for a week | You | A full week with nothing missed |
Go live and reconcile | Both | The checks below pass |
Give notice on the old system | You | Only now |
Notice goes last, not first. Serve it early and your notice period becomes a deadline instead of a buffer. There is no prize for cancelling sooner.
How to check nothing was missed
Seven checks before you sign off. The four in bold are money owed to clients, so those need to match exactly.
Check | Should match |
|---|---|
Clients seen in the last two years | Exactly |
Upcoming appointments by provider | Exactly |
Outstanding gift card balances | To the dollar |
Unused package sessions and their value | To the dollar |
Loyalty points and wallet credit | Every balance honored, or settled before the switch |
Active memberships and next charge dates | Every one |
A twenty-chart spot check, plus one live payment, refund and membership charge | All working |
Before you switch: keep your software and add the app
Plenty of practices shop for new software when what they actually want is on the patient side: an app with their practice's name on it, memberships that bill themselves, points and referral rewards that bring patients back sooner. None of that requires moving your practice software.
Velarya is a patient loyalty platform that runs beside the software you already use. Your EMR or practice software keeps the chart, and Velarya runs the app your patients use to book, earn and redeem rewards, with memberships, referral rewards and wallet credit in the same place. Leave Velarya booking on and patients book in the app, or switch it off and keep your current scheduler while patients buy treatments, earn points and check in with a QR code. Nothing is exported from your current software, because nothing has to be. We explain both setups in how Velarya runs beside your current software.
Your program starts in Velarya on day one: patients join by signing up in the app, and every point and membership lives there from then on. If the app is the reason you were thinking of switching, the loyalty program page shows what patients see, and our breakdown of what a branded client app costs covers the app side of the decision.
Ask every vendor for a sample export
One more thing, and it applies to every vendor you talk to, including us: before you commit, ask for a sample export. Not a description of one, the actual file. What comes back tells you more about how that company will treat you on the way out than any sales conversation will on the way in.
Ask for the cost of the move in writing too. Some vendors publish an onboarding fee, some price the move as a service in your contract, and some include it. Any of those is fine, as long as you know which before you sign.
Frequently asked questions
Will I lose my client history if I switch?
Not if you plan it. Client records, appointments and your service menu usually come across in an export. Charts, photos and consents come too, often attached to each client as documents and sometimes moved by hand. Download your own archive first, so nothing depends on the export working.
How long does switching take?
Usually a few weeks from scoping to go-live, and most of that is not waiting on data. The transfer and the checks are quick. The time goes into training, running both systems side by side for a week, and lining up the cutover with your notice date.
Do I have to close the practice?
No. Bookings move to the new system while the old one stays readable, and you cut over on a quieter day. Nobody closes. The one piece of advice: do not go live in your busiest week or the day before a holiday.
What is the biggest mistake practices make?
Giving notice before the new system is proven. That turns your notice period from a safety margin into a countdown. Give notice at the end, once everything reconciles.
How much does switching cost?
It depends on the vendor. Some publish an onboarding fee, some price the move as a service in your contract, and some include it. Ask for the number in writing, along with exactly what it covers, before you sign.
Can my clients' saved cards come across?
Yes. Card data moves processor to processor under PCI rules, without passing through your hands. Recurring billing schedules do not move with it, so memberships are set up again and every next charge date is checked before the first billing run.
What happens to loyalty points and wallet credit when I switch?
Treat them like gift card balances: they are owed to your patients. Export the balance list before you leave, then either give patients a clear date to use them or agree in writing with your new vendor how each balance will be honored. Tell patients which one you chose before the old program closes.
Can I keep my current software and still get an app?
Yes. Velarya runs beside your current software as the app your patients use to book, earn and redeem rewards, and your EMR or practice software keeps the chart. Nothing moves, so there is nothing to switch.
If that is the route you want to explore, book a demo and tell us what you run today. We will show you the app beside it.
Last updated