AI Made Vanguard’s Legacy Ledger Research Queryable in 15 Minutes

Gareth Yoder describes Vanguard’s cash ledger as infrastructure for money moving into brokerage accounts and between accounts, including through ACH and wire payments. It supports web, mobile, and batch channels in an active-active, fault-tolerant, multiregion ecosystem. The system receives as many as 30 million service calls a day and creates about half a million ledgers daily.

Vanguard began its mainframe-to-cloud modernization in 2022, after launching its Cash Plus offering. The work was divided into three migrations: moving data, moving the systems that produced ledger data, and moving the consumers that used it. Because modernization was an enterprise priority, Yoder said, the teams had to pursue all three in parallel.

At the outset, research into the mainframe depended on mainframe engineers and architects. A product owner or developer with a question about the existing schema might wait for an engineer to inspect the code and return with an answer. Yoder put the typical turnaround at about seven days.

The turning point was making the legacy codebase queryable through an MCP server. Vanguard connected AI agents to COBOL code, copybooks, and DB2 catalog metadata, so a question could be traced from a code search to the relevant file and then to the database’s definition of a field. In Yoder’s example, asking how a transaction-reversal flag was stored led to the TXN_HISTORY table, the REVERSAL_FL column, and its type, alongside information about the program and batch jobs that set it.

Yoder said the change cut the time to answer a legacy research question from seven days to 15 minutes. The gain was not only faster research: product owners, technical leads, and developers could get answers without waiting for the same small pool of mainframe expertise.

Yoder’s three workstreams had distinct problems. Data had to be reconciled between DB2 and the cloud. Producers needed a supported way to create cloud ledger records. Consumers needed access suited to their different workloads, with consistent schemas and clear rules about what data they could see.

For data migration, Vanguard used change data capture and daily audit jobs to compare the legacy and cloud databases. The team began with row counts, then checked individual columns to confirm that values—including amounts, account information, and state and federal withholding—matched across the two systems. Yoder described the first check as establishing consistency and the column comparisons as verifying integrity.

He cautioned against over-engineering this validation process: it was interim code that would be deprecated when modernization was complete. Timestamp comparisons also needed to account for replication lag. The approach was to check carefully without building a permanent solution for a temporary phase.

The producer migration exposed a less visible problem: legacy data had been created in several ways. Some producers called a service request directly; others used an API wrapper; still others inserted records straight into database tables. Direct inserts were especially difficult to trace because data could appear in the database without a clear path back to the producing application.

Vanguard put a common data schema behind a gateway and APIs for cloud inserts. It also used the migration to change the design rather than reproduce the old paths unchanged. Yoder cited idempotency—the ability to retry an operation without creating duplicate effects—as important for consistency during retries, along with consistency across multiple writers in a multiregion system. Batch jobs also needed to avoid creating traffic spikes that could overwhelm autoscaling.

The migration involved 35 producers. To help them move, the team wrote documentation mapping legacy data and behavior to the cloud model, then made that material available through the MCP server. One example mapped DB2 status codes and flags to cloud ledger states. The mapping surfaced a substantive schema difference: two fine-grained legacy flag fields could collapse into one cloud field, whose value was derived from the activity code rather than the coarser status.

Yoder said teams had previously contacted the cash program staff repeatedly to ask how to interpret and migrate data. With migration documentation accessible through an AI prompt, producers could answer more of those questions themselves, reducing support chats. The cloud’s human-readable ledger enums also gave the AI a clearer way to bridge the intent behind legacy codes and the new model.

The consumer side involved 50 applications and three access patterns. Real-time consumers used APIs with pagination; batch consumers accessed data through warehouse views; streaming consumers received Kafka events. Across these channels, Vanguard maintained a schema registry so consumers could work from a consistent description of the data.

For real-time use, Yoder pointed to the “funds available” API, which helps determine the balance displayed to a client. Consumers called it through GraphQL and could subscribe to the attributes relevant to their use case. For batch workloads such as reconciliation and analytics, the data warehouse provided views tailored to each consumer. Yoder said the data governance team supported restricting each view to the attributes that consumer needed.

For streaming, Kafka topics carried database inserts and updates. The fraud teams used the stream for real-time ingestion into their tools. Delivery was at least once, which meant consumers needed to make their operations safe to repeat: if a batch failed partway through, they could retry without creating duplicate ledgers. The same idempotency principle used on the producer side therefore mattered to consumers as well.

Vanguard asked each application to register with a three-character code, but Yoder said the team also required a business-use description and justification for the requested data. Examples included a trade order needing cash data to fulfill an obligation, a retirement account making a required distribution, or a 529 account receiving a contribution.

That information could then be used to generate an up-to-date description of a service, identify the business functions it supported, and describe possible client impact if service levels were breached. Yoder’s point was operational: during an incident, the response window depends on the use case. A batch application might allow hours; a real-time API returning errors to clients might require action within minutes.

He said Vanguard was continuing to evaluate how to bring those business justifications together with observability data, including logs and traces, to improve response times. The registration information was intended not just to document who consumed the ledger, but to help teams understand what was at stake when a dependency degraded.

AI tools were not available when the modernization began. As they became usable, Yoder said, Vanguard adopted them for research, development, and testing. He reported that 90% of engineers in the cash program used the tools daily, and that teams were developing multi-agent workflows, shared knowledge bases, and an evolving AI harness to meet modernization demands.

One part of that approach was a shared “team brain”: engineers’ product knowledge went into common storage that other team members could use. A new engineer could start with context accumulated by colleagues, rather than having to build it all from scratch. Yoder framed this as a way to make knowledge less dependent on how long any individual had been on the team.

Running two codebases during a migration brought a separate discipline: fix forward rather than keep repairing the legacy system. Yoder advised fixing defects in the modernized state and letting that become an incentive for producers and consumers to move over. He noted that this could disrupt audit logs, making it important to whitelist known mismatch scenarios.

Observability was not a final-stage add-on. Teams needed metrics, alarms, and traces, and had to review them regularly as the product grew. In Yoder’s closing guidance, teams needed to know who produced data, who consumed it, and whether messages were dropped or delayed. That visibility mattered during the migration and would remain part of routine operations after it.

Yoder’s five lessons follow from the constraints of doing modernization while a critical system remains in use. First, make legacy code and schema knowledge AI-queryable: in Vanguard’s case, that changed a research cycle from days to minutes. Second, treat migration documentation as part of the product, because producers need it to adopt the new system even if the documents themselves are temporary.

Third, reimagine rather than lift and shift. Yoder said the producers and consumers that were hardest to onboard were those that tried to transfer the old system directly, rather than reconsidering how the cloud ledger’s capabilities could improve the product. Fourth, adopt AI incrementally instead of waiting for a perfect starting point; the tools and the team’s practices can develop together.

Finally, do not treat observability as optional. A modernized system still needs to make its producers, consumers, failures, and operational behavior visible—especially once the migration ends and teams support it as business as usual.