Atlas Logistics runs regional freight dispatch across a fleet of independent contractors. Their dispatch system — a 15-year-old on-premise Windows application — couldn't support real-time GPS tracking customers were starting to expect, and the team that built it had long since moved on. We modernized the platform behind a strangler-fig architecture, migrating one workflow at a time over eight months without a single day of dispatch downtime.
Atlas Logistics ran dispatch operations on a 15-year-old on-premise system that couldn't support real-time tracking.
Dispatch never stops — freight moves around the clock, seven days a week. Any downtime during migration would mean missed pickups and broken customer commitments, and the old system's original engineers were long gone, making every change riskier than it should have been.
B2B freight brokerage — Atlas Logistics earns margin coordinating dispatch between shippers and independent contractor drivers, so dispatch software isn't a side tool, it's the operating core of the business.
Regional freight dispatch, a mature industry where customers increasingly expect real-time shipment visibility as a baseline, not a premium feature.
A 15-year-old on-premise Windows dispatch application, originally built in-house, whose original engineering team had since left the company.
Larger national freight brokers already offered real-time tracking to shippers; Atlas Logistics risked losing accounts to competitors who could answer "where's my shipment" without a phone call.
Reverse-engineered the undocumented parts of the 15-year-old system by reading its database schema and observing dispatcher workflows directly.
Spent a full week shadowing dispatchers across day and night shifts to understand workflow patterns the ticket queue never surfaced.
Audited 15 years of accumulated dispatch records for the inconsistencies that inevitably build up in a system without strict validation.
Migrate behind a strangler-fig pattern, one workflow at a time.
Reasoning
A full cutover risked total dispatch failure if anything went wrong; incremental migration limited blast radius to one workflow at a time.
Trade-off
Took roughly twice as long as a big-bang rewrite would have, and required running both systems in parallel for months.
Preserve the existing dispatcher interface's core layout.
Reasoning
Dispatchers had over a decade of muscle memory; a completely reimagined interface risked adoption failure regardless of technical quality.
Trade-off
Constrained some UI improvements the design team wanted to make immediately.
Build real-time tracking as a new capability, not a retrofit.
Reasoning
The legacy schema had no concept of continuous location updates; bolting it on would have meant fighting the existing data model.
Trade-off
Required a genuinely new service rather than extending existing code, adding scope early in the project.
Legacy Dispatch System
The original on-premise Windows application, kept running for not-yet-migrated workflows until the strangler-fig migration completed.
What happened
Real-time location updates at fleet scale created far more database writes than the legacy system had ever handled.
How we resolved it
Partitioned the tracking table by time range and moved to batched writes for less time-sensitive location history.
What happened
Dispatchers reported the new interface felt unfamiliar during the first migrated workflow, risking adoption.
How we resolved it
Ran a two-week feedback loop with dispatchers before migrating the next workflow, adjusting layout details based on direct input.
Approach
We modernized the platform incrementally behind a strangler-fig architecture, migrating one workflow at a time so dispatch never had to stop.
Outcome
Dispatch teams moved onto the new platform with zero unplanned downtime during the entire migration.
Platform uptime
Dispatch time reduced
Migration downtime
Predictive ETAs based on historical route and traffic patterns
Byld IQ recommendationExtending real-time tracking visibility directly to end customers, not just internal dispatchers
Client planMigrating the remaining legacy-adjacent reporting tools onto the new platform
Client planBuildPath turns your version of this problem into a personalized roadmap in about three minutes — or talk to Byld first if you still have questions.