Switching Pool Service Software: What Moves, What Doesn't, and When to Do It

Every pool company that buys software eventually shops for different software. The route grows past what the old system was built for, or a price goes up, or the thing you actually needed turns out to be an add-on. At that point the question stops being which product is better and becomes a much more practical one: what does it cost to move, and what breaks while you do it.

That question is badly served. On 2026-10-22 we read every page five pool platforms publish for exactly this moment: migration guides, onboarding answers, getting-started manuals and pricing FAQs. Four of the five publish something. The fifth, Pool Brain, publishes no migration or import process at all, only "FREE SETUP" on its pricing page. And of the four that do publish one, every page tells you what comes across and not one tells you what doesn't. That gap is the subject of this piece, because the data a migration quietly leaves behind is the data you re-enter by hand in June, when you have no time to do it.

The two ways a vendor will move your data

Migration offers in this market fall into two shapes, and the shape tells you where the work lands.

The first is done for you. Skimmer's onboarding page says a migration team will "export, clean up, and import your data so you're not entering everything by hand", and that "Your service history, customer info, and route data all come across". Pool Office Manager's pricing FAQ is blunter still: "Data migration is free, including from competitors", and you start it by emailing your customer file to a named address, with imports that "usually land within 1 business day". Both read 2026-10-22.

The second is self-serve. PoolDial's switching guide tells you to "Export your data from Pool Brain as a CSV, then use PoolDial's import tool to upload it", and says the tool "maps your columns automatically", with customers, addresses, emails and phone numbers "imported in minutes, not days". The work is yours, but so is the control, and you can run it twice.

Neither shape is better in the abstract. Done-for-you is right when your records are messy, because cleaning data is the part that takes the time and a team that has done it a hundred times is faster at it than you are. Self-serve is right when your records are already clean and you want to rehearse the import before you commit, because you can throw the result away and do it again.

What every migration page leaves out

Four pages, all written to reassure a switcher, and the exclusion list appears on none of them. Skimmer's page says service history, customer info and route data come across, and says nothing about what does not. PoolDial's says customers, addresses, emails and phone numbers arrive in minutes, and on what cannot be moved it offers only that if you need something specific, "reach out and we'll let you know how PoolDial handles it". EZ Pool Biller's getting-started manual, restamped on 2026-10-21, does not mention importing from another system or exporting your own data at all.

This is not a trap anyone set. A migration page is a sales page, and listing what you lose is a poor way to win a signup. But it leaves you to work out the exclusions yourself, and in this industry they are predictable. The things that tend not to travel are the things that were never in a tidy table to begin with: photos attached to visits, chemical readings going back years, the custom fields you invented for gate codes and dog names before the field existed, your invoice templates, your automation rules, and anything a technician typed into a free-text note.

So make the vendor say it. One email, before you sign anything: list the six or seven record types you actually rely on, and ask which of them arrive and in what form. A vendor that answers precisely is telling you something real about how the import works. A vendor that answers warmly and vaguely is telling you something too.

Parallel run

Keeping the old system live and paid for while the new one carries the real work, so you can compare them on the same week of visits before you cancel. PoolDial suggests it in its own switching guide ("Run both systems side-by-side if you want, then cancel Pool Brain when you're confident"), and it is the single cheapest piece of insurance in a migration: one extra month of a subscription you were leaving anyway.

The free trial is where this gets expensive

The obvious way to test a migration is to import your book into a free trial and look at it. Read the trial terms first, because on at least one platform that test is not free.

The safe version of the same test costs nothing extra: import a slice. Take one route, twenty to thirty properties, ideally your messiest ones, and move only those. You will learn everything the full import would have taught you about column mapping, duplicate addresses, multi-body properties and recurring schedules, and you will learn it without crossing a plan threshold.

Get your records out before you cancel, not after

The access you are relying on to export your data is access you are about to switch off. Once the subscription lapses the export tool goes with it, and what you are left with is whatever you downloaded while you still could. Do it in the week you decide, not the week you leave.

The order that keeps you out of trouble

A migration that goes wrong usually went wrong in sequencing, not in the import. The common failure is switching the billing over before the route has been proved, which means the first thing your customers see of your new software is an invoice generated from data nobody has checked.

1. 1

   Decide, then export the same day

   Work the checklist above while you still have a paid login. Store the files somewhere that is not the old system and not a technician's phone.

2. 2

   Import one route, not the book

   Twenty to thirty properties, chosen because they are awkward: two bodies of water, a commercial account, a property with two addresses, a customer who pays annually. This also keeps you below trial thresholds that bill in arrears.

3. 3

   Check the import against your own records, not against itself

   Open the printed customer list next to the screen. Count the properties, then count the bodies of water, because those two numbers diverge and most billing errors live in the gap. Confirm the rate and the frequency on every one of the twenty.

4. 4

   Ask what goes out to customers, and silence it

   An import that creates customer records can also trigger portal invites, welcome emails or texts. Get the answer in writing before the full import, not after your whole book has been emailed twice in one morning.

5. 5

   Run one full cycle in parallel

   Route and visit logging in the new system, invoicing still in the old one. One month of overlap on a subscription you are cancelling anyway is the cheapest insurance available, and it is what PoolDial itself recommends.

6. 6

   Move the billing on a cycle boundary

   One system issues this month's recurring invoices and the other issues next month's. Never both, and never half each. Then cancel, after one clean invoice run has cleared and settled.

What leaving actually costs, and what the new meter does to your first bill

Nobody in this market publishes a notice period, and on the evidence they do not have one. Pool Office Manager answers the contract question with "No. Month to month, cancel anytime", and adds that you can deactivate a user any time and stop paying for that seat the next month. PoolDial says "Cancel anytime". Skimmer's pricing page says "no contracts" and goes further, offering "a full refund in 30 days if it doesn't change your business" and telling you to "simply cancel and request a refund within the first 30 days" to get the subscription fee back. All read 2026-10-22. That is a genuinely low exit cost across the board, and it is the one part of switching that is easier in pool software than in most industries.

The cost that does bite is on the other side, and almost nobody warns you about it: the moment you import, the new vendor's meter starts counting whatever you imported. These platforms do not measure the same thing. Skimmer bills per serviced location, at $1 a month on Getting Started with 49 included from $49, or $2 on Scaling Up with 49 included from $98. Pool Brain bills $65 per active technician. Pool Office Manager bills $125 for the first user and $25 for each one after. Pool Runs bills $45 for 50 properties and $1.75 for each one after that, counted only in a month you actually service it.

So the file you upload is a bill. Import a customer list that still carries the twelve accounts you lost last winter and the eight seasonal closures you will not touch until April, and on a per-location or per-property meter you have just bought twenty units of nothing. Clean the list before the import, not after: it is five minutes of work against a charge that repeats every month until someone notices. Which unit each vendor counts, and what each one counts as one, is set out in how six vendors actually charge for routing.

When in the season, and why the answer is a date on your invoices

The two timelines published in this market are about speed, not timing. PoolDial says "Most businesses switch in under a week"; Skimmer says most pool pros are "fully up and running in days, not weeks". Both are plausible and neither answers the question an owner is actually asking, which is which week.

The constraint is the billing cycle, not the calendar. Recurring invoicing is the one function where running two systems at once does real damage, because a customer double-billed in October remembers it in March. So the cutover date is the first day of a billing period, and everything else arranges itself around that: the parallel run covers the period before it, the cancellation happens after the first invoice run on the new system has cleared and any failed cards have been chased.

Season matters second, and in the obvious direction. A migration consumes office hours, and office hours in July are worth more than office hours in November. If you are in a market with a real off-season, the window between closing and opening is the cheapest time you will ever do this. If you are in Phoenix or Orlando and have no off-season, the next best thing is the gap between your billing cycle and your busiest service week.

What Pool Runs does here, and what we are not claiming

We publish both routes in. Our team will do it from an export you send, which is how the Skimmer comparison describes it: you export your customers and service history and send us the files, and that is the only file work on your side, after which our team moves customers, properties, bodies of water, equipment and recurring schedules. Or you do it yourself, and customer management explains that you upload a CSV and Pool Runs suggests which column is which: names, email, phone, billing and service addresses, gate code and monthly rate. On QuickBooks Online you can match and import your customers from there instead.

The one row in the table above where we are the only yes is the customer-notification question, and it is worth being precise about what it means rather than claiming it as a feature nobody else has. Our pricing page states that no texts, emails or portal invites reach your customers during the import. The other four vendors' pages do not address it either way, which is not the same as them sending things. It only means you would have to ask them, and you should.

Where we lose rows in this comparison, we lose them clearly. Pool Office Manager publishes the most generous commercial terms of the five: migration free "including from competitors", "no setup fees, no onboarding fees, no implementation charges", month to month, and a seat you can deactivate and stop paying for the next month. We publish no migration timeline at all, where Skimmer and PoolDial both do. And we do not publish a settings or configuration importer, which means the screenshot step in the checklist above applies to a move onto Pool Runs exactly as it applies to a move anywhere else.

One case this page has treated as a single thing is really two. Moving between two pool-specific systems is mostly a data problem: the fields line up and the work is in reconciling them. Moving off a general field-service platform is a different exercise, because the readings and the equipment history you want on the other side were never recorded in a form the old system could hold, so there is nothing to export and the first season on the new system is where that history starts. What a move off Jobber actually involves is set out separately, with the cost arithmetic at two route sizes and the cases where staying put is the better call.

We also keep the old system in your hands rather than ours. You review everything before go-live and you can keep your previous software running until you are happy with the switch, which is the same parallel-run advice above and not a concession. If you want to see what the arithmetic looks like before you move, the line-by-line cost of a pool software stack is the piece that does the sums, and a demo is the fastest way to find out whether your awkward twenty properties survive an import.