Regional freight carrierSample
Replacing a 15-year-old dispatch system without stopping the trucks
A regional carrier running 180 vehicles depended on a desktop dispatch system built in 2009. Planning was done by hand and driver updates came in by phone. The vendor had stopped supporting the product. We replaced it with a web planning board and a driver app, one workflow at a time, while the operation kept running.
- Client
- Regional freight carrier
- Industry
- Logistics & Supply Chain
- Year
- 2024
- Duration
- 9 months to full cut-over
- Team
- 6 people
Illustrative figures for a representative engagement.
The challenge
Where things stood when we arrived.
The dispatch system was the operational heart of the business and everyone was afraid of touching it. It ran on a single on-premise server, exposed no APIs, and its only integration was a nightly CSV export to the ERP. Planners built routes by hand each morning. Changes during the day were phoned through to drivers and re-keyed later.
Customers had no visibility beyond a phone call. The customer service team spent most of its day answering 'where is my delivery' by ringing drivers in turn. The business wanted live tracking, self-service for customers and a planning tool that could suggest routes as well as record them.
A big-bang replacement was ruled out on day one. Any interruption to dispatch would stop deliveries, so the new system had to go in around the old one.
The solution
What we built, and how it fits together.
We designed a strangler-pattern migration. A new PostgreSQL-backed platform sat alongside the legacy system, mirroring its data at first through a change-data-capture pipeline and then taking over the workflows in sequence, starting with driver communication and finishing with planning itself.
The driver app (React Native, offline-first) replaced phone calls with structured status updates, proof of delivery and photos, syncing whenever the driver had signal again. A portal gave customers live tracking and their documents. Then a web planning board, with drag-and-drop re-planning and constraint checking, replaced the legacy desktop screens.
The legacy system was decommissioned eleven months after kick-off, once every workflow had run in parallel long enough for the operations team to trust the replacement.
Approach
The order we did things in.
Technology
- TypeScript
- React
- Next.js
- Node.js
- PostgreSQL
- Kafka
- React Native
- AWS
- Terraform
- Grafana / OpenTelemetry
- 01
Discovery on the dispatch floor
Three weeks shadowing planners and drivers, mapping every workflow (including the ones nobody had written down) and agreeing the order of replacement with operations leadership.
- 02
Data bridge first
The CDC pipeline and a reconciled data model came first. Both systems had to agree on every shipment before we changed how anyone worked.
- 03
Workflow-by-workflow release
The driver app went out in month three, the customer portal in month five and the planning board in month eight. Each one ran alongside the legacy process until the ops team signed it off.
- 04
Cut-over and hand-over
Each cut-over was rehearsed beforehand, with feature flags to roll back if needed. A support retainer followed, and an in-house developer had been trained alongside the team the whole way through.
Results
What changed.
- No operational downtime at any point in the migration
- Live customer tracking cut inbound status calls by roughly 38% within two months of the portal going live
- Planners reported saving around 2.5 hours a day that used to go on re-keying and phoning updates
- The vendor contract and the on-premise server were retired; hosting moved to AWS, with the infrastructure as code
- The client's IT team now ships its own changes to the platform each sprint
“We had been told for years that replacing dispatch would mean stopping the business for a weekend and hoping. It never stopped once.”
Sample quote. Replace with an attributed client statement.
Similar situation?
Tell us about it. If we're not the right people for the job, we'll say so.