How to Switch Dispatch Software Without Losing a Job
Most shops look at new dispatch software in the quiet weeks and start on it in January. Here is what actually has to move, what can safely stay behind, and how to change systems without dropping a job in the handover.
By Oren, founder of BH Dispatch
Why this conversation always happens in the fall
Almost nobody changes dispatch software in the middle of their busy season. They think about it in the fall, when the phone finally settles down enough to look up, and they start on the new thing in January. That rhythm is not an accident. Q4 is when an owner has the head space to price out next year's tools, and January is the closest thing a service business gets to a clean page.
The quiet stretch is a genuine advantage, and it is worth using. But a slow week does not make a migration safe on its own, because the ways these moves go wrong are specific and repeatable. They are almost never about the software being bad. They are about the handover.
Decide what actually has to move
The instinct is to bring everything across, because everything feels important when you are looking at years of accumulated records. Resist it. A migration that tries to move all of it usually stalls, and a stalled migration is the one that runs into your busy season.
Sort your data into three piles before you move a single record.
- Must be perfect on day one. Open jobs, anything already scheduled, and any deposit or commitment you have made to a customer.
- Must be there, can be imperfect. Customer names, addresses, phone numbers, and the access notes that live nowhere else, such as gate codes, dog warnings, and which door the crew should actually use.
- Nice to have, rarely urgent. Job history, old photos, completed invoices, and closed estimates. This is the pile that eats a migration alive if you let it go first.
The third pile is where owners lose weeks. Years of job history feels like the crown jewels right up until you ask how often anyone actually opens a job from three years ago. Usually the honest answer is that it gets looked up a handful of times a year, and the old system can stay readable for that. Move it later, or leave it where it is and keep your export.
Open jobs are the part that actually breaks
Customer lists are forgiving. If a phone number lands in the wrong field, someone fixes it the next time that customer calls. Open jobs are not forgiving at all, because an open job has a person on the other end of it who is expecting a truck.
A job that exists in both systems is worse than a job that exists in neither. Two people looking at two boards will each assume the other one has it covered, and nobody drives out.
The fix is to make one board the truth at a stated moment. Pick an hour, stop booking new work into the old system at that hour, and move every open job across by hand. Yes, by hand. This is the one part of the migration where an import script is the wrong tool, because the count is small enough to eyeball and the cost of a silent failure is a customer standing in a driveway.
Count the open jobs in the old system before you start and count them in the new one when you finish. If the two numbers do not match, you are not done, and no amount of feeling finished changes that.
The phone number is the part shops forget
Dispatch and the phone are the same problem wearing two hats, which is the whole argument for keeping them in one place. It also means a software change can quietly become a telecom change, and telecom does not move at software speed.
If your business number currently rings through your old system, moving it is not a setting you flip on cutover morning. Ask both vendors the same three questions, and get the answers in writing: what happens to the number, how long the move actually takes, and what the fallback is if it stalls halfway. If you also text customers from that number, ask separately what happens to your messaging registration, because that is its own process and it does not automatically travel with the number.
The safe pattern is to keep the old number answering somewhere the entire time. Forwarding is cheap insurance, and a caller who reaches a human does not care which system took the call.
Run both systems in parallel for a week
A single overlap day proves almost nothing. Most shops have a weekly shape rather than a daily one: the Monday backlog, the Friday afternoon scramble, the one recurring commercial account that only shows up midweek. A day of parallel running skips whichever of those falls outside it.
A workable parallel week looks like this. Every new job goes into the new system only. The old system goes read-only and stays open on a second screen for lookups. Nobody books into it, nobody updates it, and everybody knows which one is real. At the end of the week you have run a full cycle on the new tool with the old one still sitting there as a safety net you did not need.
Pick the cutover day on purpose
Not Monday, because Monday already carries the weekend's backlog. Not the first of the month if that is when your recurring and contract work lands. Not the day before a holiday weekend, and not the week a cold snap or a storm is in the forecast, which for most trades is the same thing as saying not the week your call volume triples.
A Tuesday or Wednesday morning in an ordinary week is the boring, correct answer. You get a full working day with the vendor reachable, and you get three more days to find problems before the weekend hides them.
What to test before you commit
Trials get wasted on feature tours. A demo is designed to look good, so watching one tells you how the software behaves when everything goes right, which is not the condition you need information about. Test the ugly path instead.
- Take one real job all the way through, from the call landing to the job closed. Not a made-up job, a real one you were going to run anyway.
- Do it on a phone, standing up, outside, with one hand full. That is the actual working condition for the person using it most, and plenty of tools that are excellent on a desktop fall apart there.
- Hand it to your least technical tech without a tutorial. If they need a walkthrough to close a job, you are going to be that walkthrough forever.
- Close a job and look at whatever the customer receives on the other end. That is a piece of your reputation and you should see it before a customer does.
- Try to get your data back out. Export the customer list and open it.
That last one matters more than any feature on the comparison grid. A tool you can leave is a tool you can safely commit to, and the vendor's answer tells you a great deal about how the relationship is going to go. If getting an export requires a support ticket and a wait, you have learned something important while it is still cheap to learn it.
If you are earlier than this and still working out what the category even covers, start with what dispatch software actually is, then look at dispatch software by trade for the version of the day that matches yours.
How long does switching dispatch software actually take?
The software part is usually days. The parts that set the real timeline are anything involving your phone number and anything involving people changing a habit. Plan in weeks rather than days, put the phone question first because it has the longest lead time, and you will usually finish early rather than late.
Should I import years of job history?
Usually not on day one. Move the customer list and the open work first, get the shop running, and treat history as a second project once nobody is thinking about the migration any more. Keep an export of the old data regardless, whatever you decide.
What if my techs hate it?
Find that out during the trial, not after the cutover, and take it seriously when you hear it. A dispatch tool the crew works around is worse than the whiteboard it replaced, because now the real schedule lives in someone's head and the software is a story you are telling yourself about what is happening in the field.
See what the move actually looks like
Side-by-side comparisons against the tools most shops are switching from, and the call-to-cash flow they are switching to.