The Data Paradox of Transit Modernization: Why New Systems Still Deliver Old Results

INDER PREET SINGH
Principal Consultant
Intueor Consulting Inc.

Across the U.S., public transit agencies are replacing aging finance, maintenance, and operations platforms with modern cloud-based systems: enterprise resource planning (ERP) for finance and human resources, project management information system (PMIS) for capital delivery, enterprise asset management (EAM) for fleets and infrastructure, and computer-aided dispatch/automatic vehicle location (CAD/AVL) for the dispatch backbone of real-time operations. These platforms now sit at the center of how agencies budget, acquire, manage, and run their fleet and deliver capital projects. The sales pitch is generally the same: integrated data across the agency, better and more accurate dashboards, and more reliable decision support.

In our work with agencies after go-live, executives often see familiar problems: reports that do not reconcile across ERP and EAM systems, capital project status tracked offline on spreadsheets despite having implemented a new PMIS, and performance metrics assembled by hand. The organization has new technology, but leaders still receive late, incomplete, conflicting, or inconsistent information. While the system integrator (SI) convinces the leadership that the systems are modern, the results feel old and recycled.

In one large metropolitan agency we worked with, the first major board meeting after the ERP and EAM go-live revealed three different fleet replacement numbers in the same packet: one from the ERP, one from the EAM, and one from a capital delivery spreadsheet. All three views were internally consistent and none could be reconciled in time for the public session, forcing the leadership to rely on “Excel truth” rather than the new systems.

This is not a software problem but a data problem: agencies have modernized platforms without equally modernizing the underlying data structures, ownership, and governance that the platforms depend on. Until data is treated as core infrastructure, designed, cleansed, and governed with the same rigor as capital assets, new systems will continue to deliver the same old results, albeit in a new format and style.

Migration ≠ Transformation

When large modernization programs succeed technically, it is tempting to declare victory. Interfaces work, basic reports are generated, and the SI signs off on the contractual milestones; on paper, the data migration is complete and the system is live. But what has moved is often the shape of the old world, legacy codes, fragmented ownership, and inconsistent definitions, rather than information designed for how the agency needs to operate today. Even before lunch on the first day, the finance team was back to their spreadsheets.

This is why legacy outcomes persist. Old cost centers, project IDs, asset hierarchies, and location codes—stuff nobody remembers creating are simply mapped forward into the new tables and objects. Finance continues to view the world through one chart of accounts. Maintenance has its own asset structure. Planning uses a service taxonomy that matches neither. The executive who asks, “How much did we spend on this line extension last year?” gets three different answers. Instead of using modernization to rationalize these structures, agencies frequently preserve them “for continuity” under tight timelines, baking yesterday’s compromises into tomorrow’s platform.

In practice, the hidden costs accumulate quietly but relentlessly. Analysts spend hours reconciling numbers before each board meeting; project managers maintain shadow spreadsheets because capital reports do not reflect how work is actually delivered; maintenance leaders cannot reliably link work orders, parts, and lifecycle costs at the asset level. None of these activities show up as line items in ERP or EAM business cases, yet they translate into lost productivity, slower decisions, and diminished confidence in official reports.

For leadership, the core problem is not that data was migrated incorrectly, but that it was never truly transformed—never re-designed, cleaned, and governed, to support enterprise decision-making rather than legacy habits. Until agencies confront this distinction explicitly, modernization will continue to deliver new systems wrapped around old information.

Five Pillars That Decide the Outcome

Five factors separate agencies that derive value from modernizations from those that do not, and none are about the software. These are not implementation checkboxes; they are enterprise disciplines that determine whether the investment really paid off or just looks different.

The first pillar is understanding what data the agency owns today, how it is structured, and whether it actually supports current business reporting needs. FTA’s Transit Asset Management materials and APTA’s guidance on asset information both start there rather than with technology. Governance and ownership form the second, central pillar: clear roles, a chief data officer or equivalent, and a governance council with explicit authority to define standards and resolve conflicts. Data quality, third, is an ongoing discipline rather than a one-time cleansing event. The fourth pillar is lifecycle: how long high-resolution CAD/AVL history is kept, how EAM work history supports long-term state-of-good repair analysis, and how ERP and PMIS records satisfy audit and grant requirements. Technology is last, selected and implemented in service of the agency’s data and governance strategy.

Starting Now

For executives, the most important step is to treat data work as a front-loaded, leadership-owned stream and not as a back-office activity buried in implementation. Sound Transit’s ERP/EAM Systems Transformation Program is a useful model. Leadership framed ERP and EAM as “critical business information systems,” and before launching system implementation, the agency funded a dedicated effort to prepare and standardize data, redesign its chart of accounts, and catalog key reports so that information going into the new ERP, EAM, and future PMIS would support enterprise decision-making.

Better data is not always universally welcome. Greater visibility into true project schedules, asset conditions, or service performance may unsettle existing narratives and expose long-standing workarounds. Treating data as enterprise infrastructure means tying leadership evaluations to shared metrics, backing data owners when standards are unpopular, and insisting that “shadow systems” are temporary bridges and not permanent alternatives.

Four immediate actions that cannot be delegated are:

1. Designate accountable executive sponsors for key data domains
2. Charter and empower an enterprise data governance body
3. Require a formal data assessment and readiness workstream ahead of each major system modernization
4. Ensure cleansing, standards, and lifecycle decisions are explicitly funded and scheduled, not assumed to be handled by the systems integrator

These decisions cannot be delegated because they are, at their core, decisions about how the agency will define its business, measure its performance, and demonstrate stewardship of public funds.