Cloud & Enterprise IT for Transit & Transportation
Cloud and Enterprise IT for Transit and Transportation Agencies
Migrating and running infrastructure for agencies whose dispatch, fare, and roadside systems have no maintenance window.
A transit agency's most important systems do not stop. Dispatch and vehicle location run while service runs, which in many agencies means from before dawn until after midnight, seven days a week, with rail and paratransit stretching the window further. Transportation departments face the same problem in a different shape: traffic management centers, signal systems, and roadside devices that are expected to work during the storm, the incident, and the evacuation. Cloud and infrastructure work in these agencies is constrained less by technical difficulty than by the hours available to do it and by what happens if a cutover goes wrong at four in the morning.
The second constraint is money, and specifically what kind of money. Much of the technology in a transit agency was bought as a capital project with federal or state participation, and capital dollars behave differently from operating dollars. Replacing a server with a subscription can move a line item from one column to the other, which changes who approves it, which fund pays for it, and how it is reported. Eligibility rules differ by program and change over time, so the finance question belongs inside the architecture discussion rather than after it.
What these environments look like
- Dispatch, vehicle location, scheduling, and maintenance systems from specialized vendors, often running on servers inside an operations or maintenance facility and certified by the vendor on particular versions
- Operational technology the IT department did not install: signal and train control, fare gates, station and tunnel systems, roadside signal controllers, message signs, and cameras in field cabinets
- Fare collection that touches payment card data and carries its own segmentation and assessment obligations
- Agency-owned fiber in the right of way alongside leased circuits and cellular links, connecting garages, yards, terminals, park and ride lots, and field cabinets
- Onboard systems that offload video and vehicle data in bulk when buses and trains return at night, producing storage and bandwidth patterns that look nothing like office use
- A workforce that is mostly not at a desk: operators, mechanics, supervisors, and dispatchers sharing kiosks and terminals, many without an individual mailbox or assigned computer
- At ports and airports, tenants, carriers, and federal agencies operating on or beside agency networks under rules the agency does not set
Where HQT helps
- Inventory and disposition: which workloads can move, which are pinned to a facility by vendor certification or latency to field equipment, and which should be retired instead of migrated
- Landing zones built before the first workload arrives, with account and subscription structure, network paths back to operations facilities, logging, and guardrails defined as infrastructure as code, so environments can be rebuilt rather than reconstructed from memory
- Network design across garages, yards, terminals, and roadside cabinets, with segmentation that keeps operational technology, fare systems, tenant connections, business systems, and public Wi-Fi apart from one another
- Identity and access for a shared-device workforce: badge or PIN sign-on at common terminals, role-based access tied to job assignment, and joiner, mover, and leaver processes that keep pace with operator and contractor turnover
- End-user computing for dispatch consoles, garage kiosks, supervisor tablets, and administrative staff, managed as one estate rather than as separate fleets per department
- Cost governance: tagging and account structure that allocates cloud spending to programs, funds, and grants, with budgets, alerts, and monthly reporting a finance office can reconcile
- Disaster recovery with recovery objectives set by operations rather than by IT, including what the agency does if the control center itself is unavailable, and restore tests that prove the plan rather than assuming it
How an engagement usually starts
Work of this kind usually begins with a date on someone else's calendar. A vendor announces that the next release of a dispatch or asset management system is available only as a hosted service. A maintenance facility is being rebuilt and the communications room inside it has to be designed now. Hardware reaches end of support in the middle of a capital program. An insurer or a state oversight body asks how long the agency would run without dispatch after a failure, and nobody has an answer that has been tested.
The first step we recommend is an assessment rather than a migration proposal. That means an inventory of what is running and where, dependency mapping done with operations and maintenance staff instead of from a spreadsheet, a recovery objective written down for each system and agreed by the people who would be running service without it, and a disposition plan that names a likely funding source for each item. The result is something an agency can take to a board, a general manager, or a state partner, and it keeps the first migration wave small enough to prove the approach before the systems that carry service depend on it.