A cloud-native TMS, with IoT on the buses.
A public-transit operator was running its Transportation Management System on aging on-prem hardware, with no live view of where its buses actually were. I rebuilt the platform cloud-native, designed and deployed IoT devices across the fleet, and stood up a real-time telemetry pipeline, all without taking daily service offline.
An on-prem TMS,
and buses you couldn't see.
The system ran the operation, but it ran it blind. Hardware was aging out, scaling meant buying servers, and nobody could say where a given bus was right now without calling someone.
Legacy on-prem core
The TMS sat on physical servers in one location, brittle to scale, expensive to maintain, and a single point of failure for a service the public depends on.
No live fleet visibility
Vehicle position was estimated from schedules and radio, not measured. Dispatch and planning ran on stale, partial data.
Hardware on every bus
Putting telemetry on the road meant real devices, on real buses, surviving heat, vibration and patchy cellular, not a slide deck.
Service can't stop
This is public transit. There was no maintenance window where the buses simply stop running while we cut over.
From the device on the bus
to the cloud that runs it.
This spanned the full stack, firmware on the metal up to a cloud-native platform, because a fleet telemetry system is only as good as its weakest layer.
Cloud-native re-platform
I re-architected the legacy on-prem TMS into containerized services on Kubernetes, designed to run across AWS, Azure or GCP rather than a single rack. Scaling became a config change, not a purchase order.
IoT devices on the fleet
I designed and deployed the on-bus hardware and its firmware, ruggedized for vibration, temperature and intermittent connectivity, then rolled it out across a live public-bus fleet.
Real-time telemetry pipeline
GPS and vehicle telemetry stream off every bus into an ingestion pipeline built to absorb bursts, tolerate dropouts, and deliver position data in real time instead of after the fact.
Fleet visibility, finally
Dispatch and planning got a live picture of the whole fleet, where every bus is, right now, turning guesswork into operational data the operator could actually run on.
Zero-downtime migration
I moved the operator off on-prem and onto the cloud-native platform over roughly a year, in stages, without disrupting daily transit service. The public never saw the cutover.
Built to be owned
Infrastructure as code, observability and runbooks so the operator's own team could run and extend the platform, the same discipline I bring as a <a href="/services/fractional-cto">fractional CTO</a>.
Modernized under load,
without a service gap.
A transit operator can't take a maintenance window, the buses run whether your migration is ready or not. So you modernize underneath a moving service, not on top of a paused one.
What people ask about this build.
How do you migrate a TMS without stopping the buses?
In stages, with the old and new systems running side by side. I moved workloads onto the cloud-native platform piece by piece, validated each one against the live system, and only cut traffic over once it was proven, so daily transit service never went dark during the year-long migration.
Why did this involve hardware and not just software?
Real-time fleet visibility starts on the bus. There's no telemetry to ingest until a device is physically capturing GPS and vehicle data and surviving the road. I designed and deployed the IoT devices and firmware as well as the cloud platform, so the work spanned from the metal on the bus up to Kubernetes.
Why cloud-native instead of replacing the on-prem servers?
Buying more servers solves today and recreates the same problem next year. Re-architecting onto containers and Kubernetes meant the operator could scale on demand, run across AWS, Azure or GCP, and stop carrying a single physical point of failure for a public service.
Got a legacy platform
that needs to go cloud-native?
Whether it's a transit TMS, an IoT fleet, or an on-prem system you can't afford to take offline, let's talk through what a clean migration looks like.