Guides
Most of the cost is not the software. It is the export, the checking, the weeks where two systems run at once, and the handful of records that come across wrong and are not found for months. Owners compare monthly prices, leave all of that out, and then never move at all because the whole thing feels too big to start. Here is what is actually involved, so the decision can be made on real numbers.
We do these moves. That makes us the wrong people to ask whether you should be excited about one, and the right people to ask what breaks. Most of this page is about what breaks.
More owners should stay than do. Four situations where moving is the expensive answer to the wrong question.
Reminders, waitlists, intake forms, recall, review requests, estimate follow up. Most businesses use a fraction of what they already pay for, because nobody had an afternoon to map the features to a real problem. Switching those on costs nothing and takes days. It is the first thing worth trying and the last thing anyone tries.
Take the monthly difference and divide it into what the move costs you: the work, the retraining, the weeks running both, and the drop in speed while everyone learns. A saving of forty dollars a month often takes two years to break even, by which time the new platform has raised its price too. Price alone is rarely a good enough reason.
No-shows, late payers, scope creep between the quote and the job. New software does not change any of those. A card on file, a deposit, a written change order, a confirmed arrival time: those are decisions. A business that migrates to fix one of them arrives on the new system with the same problem and a month of disruption behind it.
A migration copies what you have. Duplicate customers, missing addresses, records with no email, half finished jobs: all of it arrives on the other side, now spread across a system nobody knows yet. Cleaning first is cheaper than cleaning after, and sometimes cleaning is the whole project and no move is needed.
The case for moving is narrower and it is worth stating plainly: the system cannot do something the business actually needs, and no amount of configuration will make it. That is a real reason. Wanting a fresh start is not.
This is the part vendors summarise in a sentence and owners discover in month three.
Not between any two systems, by design and by regulation. Every stored card has to be captured again. If you take payment without the customer present, that is not a detail, it is the first month of the engagement. The workable answer is a habit rather than a feature: store the card at the next visit or the next job, using a zero value authorisation that saves it without charging anything.
Notes, attachments and job history usually come across as text in a field, stripped of the structure they had. What was a linked document becomes a line. What was a status becomes a word. Ask specifically what shape your history arrives in, because "we import your history" and "your history still works the way it did" are different claims.
Availability, capacity, recurring schedules, pricing rules, permissions. These are not records, they are settings, and they have to be rebuilt by hand in the new system's own logic. It is usually a larger job than the data itself and it is where the estimate goes wrong.
Names carrying nicknames in quotation marks, customers with no email address, duplicates that were never merged. On the Healing Waves move, twenty eight genuine exceptions came out of just over five thousand records. Those went to the practice as a list to fix. A migration that absorbs its exceptions quietly is a migration that hands you a problem in six months with no way to trace it.
Loud failures get fixed on the day. These are the ones that look fine on screen and cost you later.
If the two systems are matched to each other by customer name, a handful of records will attach to the wrong person, and nobody finds them for months. Every record should carry its old system identifier so a row on one side can always be proved to be the same row on the other.
The new system will happily send confirmations, reminders and cancellation notices while you are testing. Every outbound message has to be switched off at the account level before anything is touched, and every operation carries its own suppression on top of that. Healing Waves rebalanced thousands of records across two weeks with zero patients contacted in error, and that was the result of two independent switches rather than care.
Capacity rarely maps one to one. Four treatment tables, three crews, six units, two bays: the new system may model that as one resource and start turning work away while the screen looks plausible. This has to be checked against what the system thinks it can accept, not against what it displays.
It took bookings and cancellations all the way through the move, so the export you started from is already out of date. A second export and a proper comparison is not optional. Read only first: cancelled, moved, mismatched and never migrated look identical in a plain diff and need opposite responses.
Every link anyone ever shared, every bookmark, every directory listing and every indexed page points at the old addresses. Without permanent redirects they all become dead ends on the day you switch, and the search authority built over years goes with them. Fifteen redirects took an hour on the Healing Waves build. After the fact, it cannot be recovered.
Mail usually runs on the same domain settings as the website. Moving the domain wholesale to a new host is the common advice and it puts mail delivery at risk to gain the website nothing. The rule is that the domain stays where the mail is, and only the records pointing at the site change. Then you check afterwards rather than assuming, because detaching a domain from a host can silently remove records nobody was thinking about.
Not a timeline, because that depends on your data. This is the order, and skipping a step is where the horror stories come from.
A working session with the people who actually use the system every day, not only the owner. What they need the new system to do is the specification. Getting this from the software instead of the conversation is how projects arrive at technically correct and practically wrong.
Before importing anything. The export is where you find out how bad the data is, how many exceptions exist, and whether the plan still holds. This is also the honest moment to stop.
Every outbound message off, at the account level, before a single record lands.
Against the source export, not against the screen. Exceptions go to a file and to you as a list.
Availability, capacity, pricing, permissions, templates. Then test what the system will actually accept rather than what it shows.
The old system stays live and stays paid for. A second export, a read only diagnostic, then corrections. Anything that cannot be matched with confidence gets handled by a person rather than guessed at.
The first week is when the questions arrive. Whoever built it should be reachable during it, and the old system should still be there until the new one is confirmed correct.
The old system and its hosting stay running after go live. It is the only complete copy of the old world, and it costs one more month of a subscription you were already paying.
A chiropractic and massage practice moved its entire forward book to a new scheduling and payment system while seeing patients four days a week. 5,670 future appointments in scope, some booked into 2028. 5,008 records reconciled against the source. 28 exceptions handed back as a list. 0 patients contacted in error.
The full write up includes the parts that did not go to plan, including a problem with card payments that the practice could not have diagnosed and that had nothing to do with the migration at all.
It depends on the state of your data far more than on the size of your business, which is why anyone quoting a duration before seeing an export is guessing. What is predictable is the shape: a working session, an export you read before importing anything, the import and its record by record check, rebuilding the settings by hand, a period with both systems live, then go live with someone present. The parallel period is the part owners underestimate and the part that protects them.
You export them, and what you get back is rarely everything you can see on screen. Customer and job records usually come across cleanly. Notes and attachments often arrive as plain text stripped of their structure. Stored card details never transfer between systems, by regulation. Anything the old system calculated rather than stored, such as availability and pricing rules, is not in the export at all and has to be rebuilt. Ask for a sample export before you commit to anything.
They should not, and if they do it is almost always the same cause: the new system sending confirmations, reminders or cancellation notices while it is being set up. Every outbound message has to be switched off at the account level before any records are touched, with a second suppression on each operation underneath it. Done that way, thousands of records can be rebalanced over weeks without a single message reaching anyone.
Usually not. Divide the monthly saving into what the move costs in work, retraining and lost speed, and a modest saving often takes two years to repay, by which point the new platform has raised its price as well. Moving is worth it when the current system cannot do something the business genuinely needs and configuration will not get it there. If the honest answer is that you should stay and negotiate at renewal, we will tell you that, in writing, in the plan.
That is what the free AI plan answers. One conversation, a review of your own data, and a written recommendation with the costs on both sides, including the case for staying where you are.
