Switching garage software, without losing the history.
Most workshops stay on software they have outgrown for years longer than they intend, and the reason is almost never the price. It is the fear of losing a decade of customer and vehicle history in the move, which is a reasonable fear and a manageable one.
Find out what you can actually export, first
Before comparing anything, establish what your current system will give you and in what format. This single question decides how hard the whole exercise is.
Ask specifically rather than generally: customers, vehicles, service history, invoices, outstanding balances, stock, and any attachments such as photographs or inspection records. Some systems export the first two cleanly and the rest barely at all.
Do it before you are emotionally committed to moving. If the answer is poor, that is a reason to plan differently rather than a reason to discover it mid-migration.
Decide what has to move and what only has to be readable
Not everything needs to live in the new system, and trying to move all of it is what makes migrations fail.
- Must move: customers, vehicles, and enough service history to serve a returning customer properly.
- Should move: outstanding balances and open jobs, or you start with a reconciliation problem.
- Nice to move: stock, supplier records and pricing, though these are often easier to rebuild cleanly.
- Readable is enough: old invoices and closed jobs, which can live in an archive export you keep.
- Leave behind: duplicate records and dead customers, since a migration is the one good chance to not carry them forward.
That last point is worth taking. Whatever you move, you will live with, so a migration is the cheapest opportunity you will get to clean the data.
Timing matters more than people expect
Switching garage software during your busiest month is how a manageable project becomes a crisis.
Pick a genuinely quiet period, and avoid running the change across a financial year end or a peak season such as the run-up to winter. The first creates accounting ambiguity and the second guarantees that any problem lands when you can least absorb it.
Allow for a period of running both, with the old system readable and the new one live. That overlap is not indecision, it is the thing that lets you check the migration against reality rather than against a spreadsheet.
Check the migration on the cases that matter
Verifying a migration by counting records tells you almost nothing. The counts can match while the content is wrong.
Pick a handful of real, awkward customers and check them properly: one with a long service history, one with several vehicles, one with an outstanding balance, one with attachments, and one with something unusual about how they were recorded. If those five are right, the bulk usually is.
Do that check yourself rather than accepting an assurance. It takes an hour and it is the only part of the process that finds the errors a summary hides.
What to ask a prospective supplier, and what to ignore
Feature lists are the least useful part of the comparison, because every system lists everything and almost none of it decides the outcome.
- Ask how a customer with ten years of history will actually look after migration, and ask to see it.
- Ask what they will export for you if you ever leave, which tells you how confident they are.
- Ask who does the migration work and what it costs, since "we can import that" and "we will import that" are different sentences.
- Ask what happens in the first fortnight: who trains the team, and who answers the phone on the bad morning.
- Ask what it does not do, because a supplier who cannot name anything has not understood the question.
The answers to those five separate suppliers far better than a feature grid does, and they are the questions people wish they had asked afterwards rather than before.
Plan the first fortnight, not just the switch
The change itself is a day. The fortnight afterwards is where a migration is judged, and it is usually under-resourced.
Expect the team to be slower, expect questions that seem obvious, and put someone specific in charge of answering them rather than letting everyone work it out separately. Book slightly less work than usual for that period if you can.
It is also worth agreeing in advance what would make you stop and reassess, so that a bad week is a decision rather than a drift.
よくある質問
What should I check before switching garage software?
What your current system will actually export, in detail: customers, vehicles, service history, invoices, balances, stock and attachments. Some systems give the first two cleanly and the rest barely at all, and that answer shapes the whole project.
Does all my data need to move?
No, and trying to move everything is what makes migrations fail. Customers, vehicles, enough service history, balances and open jobs need to move. Old closed invoices usually only need to be readable in an archive.
When is the best time to switch?
A genuinely quiet period, avoiding a financial year end and any seasonal peak. Allow an overlap where the old system is readable and the new one is live, so the migration can be checked against reality.
How do I verify the migration worked?
Not by counting records, which can match while the content is wrong. Check five awkward real customers: a long history, several vehicles, an outstanding balance, attachments, and something recorded unusually. If those are right, the bulk usually is.
What goes wrong after the switch?
The fortnight afterwards is usually under-resourced. Expect the team to be slower, put one person in charge of answering questions, book slightly less work, and agree in advance what would make you stop and reassess.