If the software you're replacing is the thing your staff open every morning, you can't switch it off for a weekend and hope. You move people over in small groups you can undo, and you keep the old system running beside the new one until the last group is across. Before most of the business depends on the new one, you put it under real working conditions with a few people who'll tell you when it's wrong. That's how we moved more than 340 car dealerships onto a rebuilt platform over about a year, without taking the platform away from any of them for a weekend. It's also where the plan went wrong once, and that part is worth more than the rest.
I wrote recently about why that platform needed rebuilding at all. This is the other half: how you get a working business off the old system and onto the new one without stopping it.
Why a weekend cutover wasn't an option
A service drive is the service lane at a dealership. Advisors write up repair orders and assign technicians, and customers get a text asking them to approve the brake job. At hundreds of dealerships, all of that ran through this platform every working day.
And the old platform was already letting them down. It had three to five serious incidents a month. Database connections dropped and background jobs stalled. The link to each dealership's DMS, the dealer management system that holds its own records, fell out of sync. At the busiest hours some screens took 10 to 15 seconds to load, and when the platform went down, advisors went back to doing it by hand.
The worst of it was customer messages. Texts and emails went out unreliably, and nobody could tell which ones had arrived. A customer who never got the "your car needs brakes, approve?" message never approved, and a technician stood beside a car in a bay waiting for an answer that wasn't coming. That's billable time a service department doesn't get back.
So downtime mattered more here than usual. Less of it was the whole point of the project, and a migration that opened by taking the platform away for a weekend would have started with exactly what we were brought in to stop.
Changing course while it was still cheap
Before any dealership moved, I made a call I had to take back.
We started the rebuild with Laravel on the server and Vue, a JavaScript framework, building the screens in the browser. On paper that was sound. We expected a highly interactive application, and that's what Vue is for.
Then we built the real workflows: updating a repair order, tracking what a technician recommends, recording a customer's approval. Almost all of the difficulty in them lived on the server, in the business rules and in the integrations with each dealership's DMS. The browser mostly needed to show the result. With Vue, every one of those screens meant building an API for it and then keeping a copy of the data in the browser in step with the real one. That was a lot of work that made nothing better for an advisor.
About four to six weeks in, I moved us to Livewire, which builds interactive screens inside Laravel itself. The business logic stayed in one place and there was far less front-end code to maintain, so the screens came faster and more of our time went to the reliability problems we'd actually been hired to fix.
The timing was the whole decision. Six weeks in, switching cost a few weeks of rework. Six months in, it would have cost the project. When the evidence says an early choice was wrong, the cheapest moment to act on it is the moment you notice, and the price goes up every week after that.
Run both, and decide who's on which
The old platform kept running the whole time. The new one ran beside it, dealership data was synced across and checked, and we built routing at the dealership level: a switch that decided, one dealership at a time, which system it was using.
Nobody at a dealership ever saw that switch, and it was the most important piece of the migration. It turned moving a dealership into a configuration change. Moving one back was the same change in reverse.
Start with a few who will tell you when it's wrong
The first group was a small pilot. They used the new platform for real, during real business, with real customers waiting on texts. Development and staging environments are useful, but they're quiet. A pilot is the first time software meets the actual load.
Which is how we found the problem staging couldn't.
The part that went wrong
One of the DMS integrations had passed everything in development and staging. In the pilot, once several advisors and technicians were working at the same time, repair order status updates started arriving late.
The DMS had a rate limit, a cap on how many requests it will accept in a given window, and it was stricter than anything we'd hit in testing. At busy moments our requests got throttled. Some updates were delayed and some failed to sync. Nothing was lost, but for a while the platform and the DMS could disagree about where a repair order stood, and in a service lane that sends an advisor to the phone.
We stopped the rollout. No new dealership moved until it was fixed.
The fix, in plain terms: every update to that DMS went into a queue, a waiting line the system works through at a pace the other side can take, instead of firing everything at once. When the DMS said slow down, the system backed off and tried again, waiting a little longer each time. Each update was made safe to retry, so sending the same one twice could never record it twice. And we added monitoring on how long that line got and how far behind the sync was running.
We checked the fix with the pilot dealerships and then picked the rollout back up. It changed the process for good, too. Before any more dealerships moved, every DMS integration was tested under realistic, simultaneous use, the way a busy morning in the service lane would hit it.
Had we moved everyone at once, that problem would have shown up at more than 340 dealerships on the same morning. In a small pilot it was a pause.
Batches, after hours, with a way back
Once the pilot held, dealerships moved in controlled batches, usually outside service hours, so nobody switched systems with a customer at the counter. Each one was watched after it moved. And because the old system was still running and the routing switch still existed, a dealership that hit trouble could go back while we fixed it, without touching anyone else.
That's hundreds of small, controlled transitions instead of one big one. It's slower on a calendar and far faster than recovering from a bad Monday at 340 dealerships.
What came out the other side
The whole thing took about a year, from the first line of code to the last dealership.
Screens that had taken 10 to 15 seconds at peak came down to one or two. Serious incidents went from three to five a month to fewer than one. Over a year of external monitoring, the platform measured 99.98 percent uptime.
Customer messages now go through the same kind of queue, with automatic retries and delivery receipts from the provider, so a dealership can see whether a text was sent, delivered, or needs someone's attention. They used to find out from a customer who never heard back.
And the dealerships didn't have to learn a new way of working to get any of it. We replaced the technology underneath and left their process alone, which is the rule from the last post: rebuild first, matching what you had, and improve it after.
What to ask before anyone replaces your system
You don't need to know what a rate limit is to check a migration plan. Ask these:
- Who moves first, and how many? If the answer is everyone on launch day, ask why.
- How does someone go back to the old system, and how long does that take?
- What gets tested under real, busy conditions before most of the business is on it?
- What happens to work that's halfway through on the day someone moves, like an order half entered or a message half sent?
A good answer to the last one is specific and a little boring. A developer who hasn't thought about it will tell you it'll be fine.
