Case study

Switching CAD/AVL vendors without losing the record

The record usually leaves with the vendor. Veodyn captures it into a warehouse the agency owns and serves the feed from the agency's own address, so the next contract starts with the history intact.

02

The setup

A transit agency's CAD/AVL contract is ending. The vendor's system has tracked every vehicle for years, counted every boarding through the APC units, and published the real-time feed that Google, Apple, Transit, and the regional 511 read. All of that lives at the vendor's address, in the vendor's portal, under the vendor's schema.

The new contract goes to a different vendor. The cutover date is set. Nobody has written down what happens to the last five years.

03

The data problem

The record leaves with the vendor. The AVL history that every on-time trend was drawn from, the APC counts behind every ridership filing, and the feed address every rider app points at are all vendor assets, and the contract says nothing about handing them over in a usable form.

The new vendor starts from zero. Year-over-year comparisons break at the cutover. A ridership number filed two years ago can no longer be reproduced, because the rows behind it were in a portal that no longer answers. And the feed URL is the vendor's, so on cutover day every consumer has to be found and told to move, or riders lose their arrivals.

Agencies discover this in the last quarter of the contract, when there is no time left to fix it.

04

The Veodyn architecture

Veodyn puts the record in a warehouse the agency owns, before the contract ends, and moves the public feed to an address the agency controls.

Capture before cutover. The node connects to the incumbent's AVL and CAD database, or to the vendor's feed where that is all there is, and captures scheduled query results into the agency's own historical warehouse. Retention is set by the agency, and can be set to keep everything.
Publish beside the vendor. The agency's real-time feed goes up at its own address while the vendor's is still live. Consumers move on their own schedule, and the data path underneath does not change until the agency is ready.
Prove the two feeds match. The same validator runs over both addresses against the same static archive, and the reports are compared, along with vehicle counts and route coverage, so the cutover is a decision made on evidence.
Cut over without an outage. The vendor stops publishing; the agency's address keeps serving. A failed publish is refused and the last version that passed stays up.
The next vendor connects to your data. The new CAD/AVL system becomes another source into the same warehouse and the same feed. Its history starts where the old one left off, in the same tables.

The agency keeps whichever dispatch system it buys. The record and the feed address stop changing hands.

05

What the agency keeps

The capability	What powers it
Year-over-year trends survive the cutover	Historical capture into a warehouse the agency owns, retention set by the agency
Filed numbers stay reproducible	The rows behind each filing sit under a capture timestamp the agency can point at
Rider apps never move again	The feed is published at the agency's own address, and the next vendor feeds it
The cutover is proven, not hoped	Same validator over both feeds against the same archive, counts compared
Consumers migrate on their own schedule	Both feeds run through the overlap; a private feed can stage one consumer at a time
Nothing goes dark on cutover day	A failed publish is refused and the last passing version keeps serving

06

We don't run your dispatch

Veodyn captures, checks, and publishes. It does not dispatch buses or replace the CAD/AVL system.

The vehicles are still tracked by whichever system the agency buys, and the operators still work in it. Veodyn sits beside it, reads what it produces into a warehouse the agency owns, and serves the public feed from the agency's address. When the next contract ends, the same thing happens again, and the record does not move.

07

Why the address is yours

A public feed address is a promise to every app that reads it. Once it is at the agency's own domain, on an open standard, served by a node the agency runs, no vendor change can break that promise. The Community node is free to run, the feed format is the one every consumer already reads, and the warehouse is a database the agency can query with anything. The vendor is a supplier of positions, not the owner of the record.

08

See it on your network

Tell us when your contract ends and who reads your feed today, and we will map the capture and the cutover. Book a call.

09