Why Most Migrations Go Wrong
Most pool operators who switch pool service software end up running two systems for three months longer than they planned. They tell themselves it is just until the invoices clear, or until they have time to move the old notes over, or until they figure out the new system. Then it is six months. Then a year. Meanwhile they are entering stops twice, reconciling two sets of records, and slowly going insane.
Running two systems indefinitely is not a safety net. It is a tax on every hour you work. The goal of a migration is to get out of the old system completely, on a specific date, and never look back. Everything below is built around that idea.
Step One: Export Everything Before You Do Anything Else
Before you cancel a subscription, before you sign up for anything new, pull a full data export from your current software. Do it today, even if you are not ready to move yet.
You want four things:
- Customer list with addresses, contact info, billing rates, and pool specs
- Service history — at minimum the last 12 months of visit records
- Open invoices and any outstanding balances
- Chemical and equipment notes tied to specific pools
Most software will let you export to CSV or PDF. Some will give you a proper data file, some will give you something ugly. Either way, get it out and save it somewhere that is not inside the software itself. A folder on your laptop and a copy in Google Drive is fine. The point is that this data exists outside the system you are leaving.
If your current software does not have an export function, contact support and ask them to send you your data. Every legitimate company will do this. If they refuse, that tells you something useful about them.
Step Two: Pick One System of Record
Before the cutover, decide what the new software will own. Customer profiles live there. Service history lives there. Invoices go out from there. Everything else — paper notes, spreadsheets, the mental model in your head — gets consolidated into the new system during the migration window.
The reason this matters: data integrity falls apart when two systems both contain the "real" version of something. If a customer updates their gate code and you put it in the old system out of habit, it will not be in the new one. If you issue a credit in one place and an invoice in another, your books will not match. Pick the new system and make it authoritative from day one of the cutover, not day thirty.
Step Three: Decide What to Do About In-Flight Invoices
This is where most migrations get stuck. You have open invoices in the old system. Some are from last week, some are 45 days old. You do not want to lose track of them, but you also do not want to manage receivables in two places forever.
Here is a practical approach that works for a small route.
Set a hard cutover date — say, the first of next month. In the two weeks before that date, work to close out as many open invoices as possible. Send reminders, collect what you can. On cutover day, take a screenshot or printed list of every invoice that is still outstanding in the old system. That list becomes a manual reconciliation document. You track those specific invoices to zero the old-fashioned way — a spreadsheet, a legal pad, whatever — while all new invoices go out from the new system. Once that old list hits zero, you close the old account.
It is not elegant, but it takes about two weeks to clear most normal receivables, and it means you are not paying for two subscriptions indefinitely.
Step Four: Import Customers and Build Your Route
Take the CSV you exported and import it into the new system. Every platform handles this differently. Some have a clean import wizard, some require you to map fields manually, some make you call support. Budget a few hours for this regardless of how easy it looks in the demo.
Once customers are in, set up your route stops. This is also a good time to audit your schedule. If you have been meaning to reorder stops to cut drive time — say, you currently drive 11 minutes between two pools that are three minutes apart in the opposite order — fix it now while you are rebuilding the route anyway.
Do not try to import every line of service history if it is going to take you 20 hours. Import what is genuinely useful: pool size, filter type, salt system info, recurring chemical quirks, anything a tech needs to do the job. A complete visit log from three years ago is nice to have. It is not worth a week of manual data entry.
Step Five: Set the Cutover Date and Hold to It
Pick a date. Put it on the calendar. Tell your tech if you have one. The date is when the old software stops being used for anything — not invoices, not notes, not lookups. New system only from that morning forward.
Give yourself two to three weeks of overlap for testing and learning, but make the overlap period about learning the new system, not running both systems in parallel. Do your actual work in the new software starting on day one of the overlap. Use the old system only to look up historical data you have not imported yet.
The switch pool service software migration that works is the one with a firm end date. Without it, the overlap becomes permanent.
What to Do if Something Goes Wrong
You will lose something small. A note will not come over. An invoice will get issued twice. A customer address will be wrong. This is normal. The cost of these small errors is much lower than the cost of running two systems for another six months. Fix the errors as they surface and move on.
The data you exported at the start is your safety net. If you need to look something up that did not make it into the new system, it is in that folder.
One More Thing
If you are evaluating options and want to see how a system built by a working pool operator handles route management and billing, getLucci is free for your first 50 pools — no trial period, just free. Worth a look before you commit to anything.