AI Cut Our Research Time From 7 Days to 15 Minutes — Gareth Yoder, Vanguard
Gareth Yoder of Vanguard describes modernizing a cash ledger handling up to 30 million calls per day by running data, producer, and consumer migrations in parallel. Key themes include exposing legacy code to AI through an MCP server, reducing a seven-day research cycle to fifteen minutes, reimagining rather than lifting and shifting, and maintaining observability throughout the migration.
Gareth Yoder, technical lead for Vanguard’s cash program, walks through modernizing a cash ledger that handles up to 30 million calls per day, with the talk framed as ‘No Cash Left Behind,’ a modernization journey that began after the Cash Plus launch for brokerage clients in 2022.
The cash ledger and the scale of the problem
A cash ledger records all money movement into Vanguard brokerage accounts from the outside world, plus cash moved between accounts. Payment rails include ACH and wires, and the system serves web, mobile, and batch channels. It runs as an active-active, multi-region, fault-tolerant ecosystem, receives up to 30 million calls per day, and generates roughly half a million ledgers daily. Yoder notes that once modernization became a whisper and then an enterprise priority, the team split the work into three pillars (data migration, producer migration, and consumer migration) and ran all three in parallel.
Research before and after AI tooling
At the start of the timeline, AI tooling did not exist. Determining the target data schema meant relying on mainframe engineers and architects who had to dig through legacy code and return with answers. The turning point came when the legacy codebase was exposed to AI tools through an MCP server. Research that previously took a mainframe engineer seven days now runs as an AI tool prompt in about 15 minutes. Yoder emphasizes that product owners, technical leads, and developers all benefited, which made the tool a shared contributor to the modernization effort.
Data migration
The team used standard change data capture (CDC) and scanned both databases, with a team running daily audits. Consistency was checked first through row-level counts, then integrity was verified column by column: amounts had to match between legacy and modern systems, and so did account information, state withholding, and federal withholding. Yoder’s practical tip is not to over-engineer the migration tooling, since this code will eventually be deprecated.
Producer migration
Producers reached the legacy infrastructure in three ways: service requests, an API wrapping those service requests, and direct table inserts. The last was the most daunting, because data appeared in the database without the team knowing how it got there or who produced it. The team placed the common data schema behind a gateway that wrapped the APIs performing cloud data inserts. Yoder encourages teams to treat modernization as a chance to reimagine the data ecosystem rather than replicate it. The team borrowed ideas from fintech, including idempotency and strong consistency across multiple writers, using a paradigm similar to Snowflake IDs. There was no lift and shift.
Of the 35 producers that had to move, early onboarding relied on manual documentation kept in the company wiki. Once AI tooling matured, that documentation was exposed through the MCP server as well. Previously many teams had to chat with the migration team, and those conversations were hard to organize. With the MCP available, those exchanges moved into prompts, and the volume of chats and producer support requests dropped significantly. The team also made ledger enums human-readable instead of legacy status codes, and AI tooling helped bridge the intent from legacy semantics to the cloud model.
Consumer migration
Consumers accessed ledger data through three patterns: real-time, batch, and streaming. A schema registry served as the common contract across all channels. The real-time case is the funds-available API, the heaviest-traffic endpoint, which determines the balance displayed to customers. Consumers call it through GraphQL and subscribe only to the attributes they need.
For batch use cases such as reconciliation and analytics, the data warehouse exposes data share views tailored to each consumer. Data governance strongly pushed for consumers to see only the attributes they are entitled to. For streaming, a Kafka topic carries all inserts and updates, and fraud teams use it for real-time ingestion into their tooling. Delivery is at-least-once, so the idempotency concepts from the producer side carried over. If a batch job fails midway, consumers can safely retry without creating duplicate ledgers, while still receiving every ledger event.
Onboarding 50 consumers and linking business context
Fifty consumers across the organization needed the data. Vanguard already requires a three-character application code for onboarding, but the team went further and asked each consumer for a description and a business justification. Examples include a trade order that needs a cash ledger to fulfill the cash obligation of a trade, a retirement account performing a mandatory distribution, and a 529 account making a tuition contribution. Aggregating these descriptions lets AI tooling map which use cases have been modernized and identify the most important business functions the platform supports.
Yoder also argues for capturing the impact of SLA breaches. If an application code falls below five nines of availability during a major incident, the response urgency depends on the consumer type: a batch application may leave hours to respond, while a real-time API with a client receiving errors leaves only minutes, so self-healing must be fast. The team is exploring how to attach business use-case justifications to observability and log traces to speed up response.
What the team learned
Although the journey started before AI tooling existed, the team kept adopting newer technologies, which accelerated research, development, and testing. Today 90 percent of the cash program’s engineers use AI tools daily. Teams work with multi-agent workflows and shared knowledge bases. A ’team brain’ stores knowledge produced during feature development so that every member can access it, and a new engineer can start with the same context as someone who has been on the team for five years.
Maintaining two codebases during migration is difficult. Yoder recommends fixing forward rather than fixing the past: when decades-old bugs surface, fix them in the modernized state and let that be the incentive for producers and consumers to move to the cloud. This disrupts audit logs, so allowlisting is essential, along with the right metrics, alarms, and traceability, which teams review often as the product grows.
Five takeaways
- Make the legacy codebase AI-queryable. Exposing it through an MCP server cut research from seven days to fifteen minutes.
- Treat migration docs as part of the product. Producers rely on them to onboard, and they remain critical until deprecation.
- Reimagine rather than lift and shift. The producers and consumers that struggled most were those replicating old behavior instead of using modern capabilities.
- Adopt AI incrementally. There is no perfect starting point, so begin, then enhance and adapt as the technology changes.
- Observability is non-negotiable. Teams must know who produces and who consumes the data, especially once modernization moves into business-as-usual operations.