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

Problem

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

Migrating them the obvious way, by hand and one at a time across a large integration surface, was slow and repetitive for the combined providers, and any behavioral drift between the old and new execution paths would land in real customer tax and banking data.

Context

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

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

Constraints

• No customer-facing disruption during the migration, in a path that feeds tax and banking products directly.
• Each migrated integration had to prove behavioral equivalence to its legacy path before taking real traffic.
• The provider surface was large enough that a purely manual, case-by-case migration would not scale for the repetitive parts.
• Combined banking-and-tax providers carried more integration surface to get right than single-domain providers, so they needed the most consistent treatment.

My Role

I led this workstream as primary engineer. I owned the plan and the execution for migrating this set of Tier-1 provider integrations onto the modern engine.

For the combined banking-and-tax providers, I drove conversion with a Claude-powered migration agent, and I contributed to building that agent rather than owning it outright. I owned the automated unit-test migration for the affected downstream pipelines, and I owned the agent-upload flow inside the internal Model Context Protocol (MCP) integration that moves generated changes into the tool engineers use to author and manage provider integrations.

What I did not own: the execution engine's architecture, the wider organization-wide migration program, and the provider relationships themselves. The work here is technical integration and migration execution, not account ownership.

Architecture / Approach

Two conversion paths, chosen by provider shape. Combined banking-and-tax providers went through the Claude-powered migration agent, which translated their existing integration logic into the modern DSL. Tax-only script providers were migrated by hand, where the agent added little over doing it directly.

Shadow validation before every cutover. For each provider, its legacy and modern execution paths ran side by side and their outputs were compared. A provider only moved to the modern path once its behavior matched. Providers not yet validated kept running unchanged, so the migration's risk surface grew one validated provider at a time.

Generated changes delivered through MCP, landed by a person. Agent output did not go straight to production. It flowed through the internal MCP integration into the tool engineers use to author and manage provider integrations, so each change was landed by an engineer through the normal workflow rather than applied automatically. I owned the reliability, role handling, and workflow correctness of that upload flow.

Test migration in step with the integrations. The affected downstream test suites for the TurboTax, QuickBooks, and Credit Karma pipelines were migrated alongside the integration changes, and the migrated suite passed in full before the work was considered done.

Key Decisions

• Match the tool to the provider shape. The migration agent earned its cost on combined banking-and-tax providers, where there was more repetitive translation to do. Hand migration stayed simpler for tax-only scripts, so those did not go through the agent.
• Shadow-validate every provider, with no exceptions. Trusting the agent's output without a behavioral diff against the legacy path was not acceptable for customer financial data, so every provider went through shadow comparison regardless of how it was converted.
• Keep a person in the loop for landing changes. Routing agent output through the MCP upload flow into the authoring tool, rather than applying it automatically, kept an engineer accountable for each change to a production financial integration.

Trade-offs

Building and tuning a migration agent, then checking its output before landing it, is real overhead. It was worth paying for the combined providers, where consistent translation across many similar cases saved more than it cost, and not worth it for the simpler tax-only scripts.

Shadow-validating every provider before cutover was slower than a batch conversion and meant running two execution paths per provider for a while. That bought a bounded blast radius: a bad conversion stayed contained to one unvalidated provider instead of reaching customer data across the set.

Landing changes through the authoring tool rather than direct commits kept a human landing step in the path, trading a little speed for traceability on changes to production financial integrations.

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 suite passing. This is validation evidence for the migration approach, 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, not a way around validation. Its output still has to be proven equivalent to the thing it replaces, provider by provider, before it touches real data. The shadow comparison did not get cheaper because a model wrote the code.

The agent paid off where the work was repetitive and structurally similar across providers, and did not where each case was already simple. Deciding the method per provider shape mattered more than committing to one approach for everything.

Keeping generated changes on the same authoring and landing path people already used, rather than a separate fast lane, kept accountability clear without slowing the work down much.