Leading an AI-Assisted Migration of Financial-Data Provider Integrations

Problem

Intuit's execution engine runs data-provider integrations for products like TurboTax, QuickBooks, and Credit Karma. A set of Tier-1 financial-institution provider integrations still ran on older execution paths. They needed to move onto the modern internal DSL engine. Some providers cover only tax data. Others cover both banking and tax.

The obvious approach was to migrate each one by hand. That was slow and repetitive for the combined providers. Any behavioral drift between the old and new paths would also reach real customer data.

Context

This was an existing platform, not a greenfield build. The modern engine was already established around an internal DSL, with production provider contracts, downstream consumers, and team conventions in place. I joined the team responsible for this work. I did not start it.

A separate workstream handled the 15-year-old legacy tax scripting pipeline. It has its own case study. This workstream covers the Tier-1 provider integrations and the tooling used to move them.

Constraints

• Each migrated integration had to prove it behaved like its legacy path before it took real traffic.
• Combined banking-and-tax providers had more integration surface to get right than tax-only providers.

My Role

I led these provider migrations as primary engineer. That scope covers this set of Tier-1 integrations. It does not cover the wider migration program.

• I converted the combined banking-and-tax providers with a Claude-powered migration agent.
• I contributed to building that agent. I did not own it.
• I owned the automated unit-test migration for the TurboTax, QuickBooks, and Credit Karma pipelines.
• I owned the agent-upload flow in the internal Model Context Protocol (MCP) integration. It lets AI agents upload generated changes into an internal authoring tool where engineers manage provider integrations.

I did not own the engine's architecture, the organization-wide migration program, or the provider relationships. My stakeholder work was technical: API contracts, provider-specific behavior, and integration correctness.

Architecture / Approach

Two conversion paths, chosen by provider shape. Combined banking-and-tax providers went through the Claude-powered migration agent. It translated their integration logic into the modern DSL. Tax-only script providers were migrated by hand.

Shadow validation before every cutover. For each provider, the legacy and modern paths ran side by side. Their outputs were compared. A provider moved to the modern path only after the shadow run held up. Providers not yet validated kept running unchanged. Risk grew one validated provider at a time.

Agent output delivered through MCP. The internal MCP integration lets AI agents upload generated changes into an internal authoring tool where engineers manage provider integrations. I owned that upload flow. I worked on its reliability, role management, and workflow correctness.

Test migration alongside the integrations. I migrated the automated unit tests for the TurboTax, QuickBooks, and Credit Karma pipelines. The migrated suites passed in full.

Key Decisions

• Split the work by provider shape. Combined banking-and-tax providers used the migration agent. Tax-only scripts were migrated by hand.
• Shadow-validate every provider. Every provider went through shadow comparison, however it was converted. Agent output was not trusted without a behavioral comparison against the legacy path. This is customer financial data.
• Keep the agent's output on the normal authoring path. Generated changes went into the same authoring tool engineers already use for provider integrations.

Trade-offs

Shadow-validating every provider was slower than a batch conversion. It meant running two execution paths per provider for a while. In return, a bad conversion stayed with one unvalidated provider. It did not reach customer data across the whole set.

An agent adds its own overhead. Its output still has to be checked. I split the work by provider shape instead of using one method everywhere.

Impact

Implemented behavior. The Tier-1 provider integrations in scope were migrated onto the modern engine, each shadow-validated against its legacy execution path before cutover, with combined banking-and-tax providers converted through the migration agent and tax-only scripts migrated by hand.

Validation. The automated unit-test migration for the affected downstream pipelines completed with the full migrated suites passing. This is validation evidence. It is not a business-impact, throughput, or incident-reduction claim.

Ownership boundary. This was primary-engineer ownership of this set of provider migrations and the tooling around them, not ownership of the execution engine, the organization-wide migration program, or the provider relationships. No transaction-volume, latency, revenue, or incident-reduction figures were measured or are claimed.

Lessons

An AI migration agent is a translation tool. It is not a way around validation. Its output still has to be proven equivalent to what it replaces, provider by provider, before it touches real data. The shadow comparison did not get cheaper because a model wrote the code.

Choosing the method per provider shape mattered more than committing to one approach for everything.