Quick answer. Move the customer and vehicle list first, then pricing, then start washing in the new system on a fixed date and stop dual running. The migration that fails is the one where the spreadsheet stays open “just for now”, because within a month the two disagree and everyone trusts the file they can see. Three weeks is a realistic timeline for a single site.
Nobody starts a truck wash by choosing software. You start with a book, then a spreadsheet, then a second spreadsheet for invoicing, then a shared folder because two people need it. That works, genuinely, for longer than software vendors like to admit. The question is not whether the spreadsheet is bad. It is whether it has started costing you more than it saves.
When has a spreadsheet actually stopped working?
There are four honest signals, and none of them is “you have grown”.
Two people cannot use it at once. The moment someone has to wait, or worse, keeps a local copy, your data has forked and you will not notice until an invoice is wrong.
You cannot answer a customer question quickly. A fleet manager asks how many of their vehicles you washed last month and what it cost. If that is a twenty minute exercise, you are paying for the spreadsheet every time it is asked.
Invoicing takes a day. Month end that eats a full working day is not an admin problem, it is a data structure problem wearing an admin costume.
You have stopped changing prices. This is the quiet one. When updating a rate means editing four files, operators stop doing it, and a price that has not moved in three years is a margin problem nobody has noticed yet.
One of those on its own is survivable. Three of them together is the point where the spreadsheet has become the constraint.
What to move, and in what order
Sequence matters more than speed, because each step depends on the one before it.
First, customers and vehicles. This is the foundation and the part worth doing carefully. Every subsequent record hangs off a customer or a plate, so duplicates here become duplicates everywhere. Expect to find the same fleet listed three times with different spellings, and expect that to be the most useful hour of the whole project.
Second, pricing and programmes. Your wash programmes with their specifications and rates, plus whatever account specific pricing you have promised over the years. That second part usually lives in email rather than in the spreadsheet, which is why this step takes longer than people plan for.
Third, open items. Unbilled washes, outstanding invoices, anything half finished. Keep this list short by choosing a cutover date when it naturally is short.
Last, history. Deliberately last, and often not at all. See below.
What to do with years of history
Less than you think, and this is where we disagree with the instinct.
The urge is to import everything, because it feels wasteful to leave four years of washes behind. In practice, historical rows from a spreadsheet arrive without the structure that makes them useful. They have a date, a name and an amount, but no programme, no bay, no duration, and no link to a vehicle record that did not exist yet. Loading them gives you a longer report that you cannot slice.
The pragmatic route is to keep the old file, exported and archived somewhere safe, and start clean. You lose the ability to compare this March against last March for one year, which is a real cost and a survivable one. What you gain is a dataset where every row is complete from day one.
The exception is customer level totals for your largest accounts. Those are worth carrying across manually, because a fleet conversation benefits from “you have been with us three years” in a way that a report does not.
The cutover, and why dual running kills it
Pick a date, ideally the first of a month, and stop using the spreadsheet on that date. Not gradually. On the date.
Dual running feels safe and is the most reliable way to fail. Within two weeks the two records disagree, because someone was in a hurry and only updated one. At that point nobody knows which is right, confidence collapses, and the team drifts back to the file they have used for years. We have watched this happen more than once, and it is never a software problem.
What genuinely reduces risk is a quieter kind of preparation. Run a handful of real washes through the new system a week before cutover, with the same people who will use it, and let them find what is confusing while the spreadsheet is still there as a safety net. Then close the net on the date.
Keep the old file readable, obviously. Archive it, do not delete it. The rule is that nobody writes to it, not that it disappears.
The part that is not technical
The migration risk is almost never the data. It is the attendant who has done check in the same way for six years and now has to do it differently while a queue builds.
Three things help more than training documents. Choose a cutover in a quieter week, not at the start of the salt season. Make sure the person who is fastest on the counter is involved before go live rather than after, because their opinion decides the team’s. And accept that the first fortnight is slower, then say so out loud, so nobody concludes the system is bad when they are simply new at it.
If you run several sites, do one first and let it settle for a month before the next. Rolling out everywhere at once means every problem happens simultaneously and you learn nothing between them. Getting multiple locations onto one system is the goal; doing them in a single weekend is not the way there.
Questions we get asked
How long does a migration actually take?
About three weeks for a single site, of which the data work is a few days and the rest is preparation and settling. Multi site is not proportionally longer, because the second location inherits your pricing and programme setup and only needs its own customers and staff.
Can we import our spreadsheet directly?
Customers and vehicles, usually yes, once the columns are cleaned up. That cleanup is the real work and it is worth doing by hand rather than automating, because it is where you find the duplicates and the fleets that changed name two years ago.
What if our pricing is inconsistent across customers?
Then the migration is the moment you find out how inconsistent, which is uncomfortable and valuable. Carry across what you have promised, mark the ones that look wrong, and fix them at the next renewal rather than surprising a customer during a system change.
Do we need to stop washing during the switch?
No. The cutover is administrative, not operational. Vehicles keep coming through the bay; what changes is where the record lands. That is precisely why a quieter week is worth choosing, since attention rather than capacity is the constraint.
What happens to invoices already sent from the old system?
They stay valid and stay where they are. Only unbilled work needs to move. Trying to recreate historical invoices in a new system creates duplicates in your accounts, which is a far worse problem than having two years of records in two places.
Want to try the first step without committing to anything? Start a free trial and load your customer list into it.
