When Schwab acquired TD Ameritrade in October 2020, it inherited one of the largest institutional advisor businesses in the industry: more than 4,000 registered investment advisor accounts on TD Ameritrade’s institutional platform, collectively responsible for an estimated $350B in advised assets.
The acquisition closed on paper in months. The integration took years, and the engineering work to move those advisors onto Schwab’s platform was at the center of it. A botched migration was not a technology problem. It was an asset retention problem. Advisors who lost confidence in either the platform or the transition would move their clients elsewhere, taking the AUM with them.
Brooks served as Senior Director, Software Engineering and Technology Owner for Advisor Web Trading and Online Money Movement at Schwab from 2017 to 2024. He led the engineering organization responsible for delivering the $50M application modernization program that migrated TDA Institutional accounts onto Schwab’s platform.
The starting position
The institutional advisor business is unlike retail brokerage in two ways that matter for engineering execution.
First, the customers are not individuals. They are firms running their own clients on the platform. A single advisor account can represent hundreds of underlying clients and hundreds of millions of dollars. The platform is the operational infrastructure for entire wealth-management businesses, not a tool a customer logs into once a week.
Second, the cost of disruption is asymmetric. A retail customer might tolerate a thirty-minute outage. A registered investment advisor cannot, because they have their own clients waiting on transactions, statements, and reporting. Any visible degradation in the migration would trigger advisor conversations with competing custodians the same week.
That asymmetry shaped every engineering decision.
The execution model
The work spanned 20+ concurrent product workstreams running through a scaled-agile delivery model, supervising Senior Managers, Architects, Analysts, Product Owners, and Scrum Masters across the engineering organization. Three things made the model hold up under the pressure.
Operating cadence built for asymmetric risk
The team operated on a rhythm where every release went through three layers of review: technical readiness, business-impact assessment, and an advisor-side simulation. The third layer was the one most companies skip. Advisors run their businesses on the platform, and “it works in QA” is not the same as “it works the way an advisor runs their practice on a Monday morning at market open.” Building that simulation into the release cadence caught issues that would have been visible to clients otherwise.
Financial discipline tied to scope discipline
Concurrently, as Chief of Staff to the Head of Advisor Service Experience Technologies, the role included managing a $40M+ business unit P&L across a 300+ person organization. Cost-saving initiatives executed during this period exceeded CIO directives by 15%, and multi-year financial forecasting kept the modernization program funded without crowding out the BAU work it ran in parallel with.
Financial discipline is what separates a $50M program that delivers from a $50M program that quietly grows to $80M. Treating the budget as a constraint rather than a target shaped which features made the cut and which were deferred to a later phase. The program delivered on time and within budget. Most programs of this scale do not.
Migration sequencing that prioritized retention
Not every advisor account migrated on the same day. The sequencing prioritized the largest, most complex accounts at the front of the program (where dedicated engineering and operations support could be applied) and tail accounts later. This is the opposite of how most platform migrations are sequenced, which usually start with simple accounts to “build muscle.” The bet was that the cost of losing one large account to a competitor was higher than the cost of the engineering complexity required to migrate it first.
The bet paid off. The largest accounts migrated cleanly. By the time the long tail of accounts moved, the migration playbook was well-rehearsed and the platform’s stability was demonstrable.
What kept the team together
A program of this scope, run for years under acquisition pressure, will burn out an engineering organization unless something is consistently true: the people doing the work feel like the work matters and that they are trusted to do it well.
Through this period, the engineering organization ranked in the top 1% of leaders firm-wide for employee engagement, for six consecutive years. The downstream measures: near-zero voluntary attrition, above-average velocity, multiple internal talent pipeline promotions, and consistent on-time delivery across 20+ concurrent product workstreams.
The retention number is the one most often missed in case studies of large integration programs. A migration that delivers on time but breaks the team is not a successful program. It is a deferred cost. The integration team’s institutional knowledge is the only thing that makes the post-migration platform supportable. Losing that knowledge to attrition during the program is the most common form of integration failure, and it does not show up in the program’s P&L for years.
What the numbers actually mean
The headline numbers from this engagement:
- 4,000+ institutional advisor accounts migrated.
- $350B in advised AUM protected through the migration.
- $50M program delivered on time and on budget.
- 20+ concurrent product workstreams maintained throughout, with consistent on-time delivery.
- Top 1% employee engagement, six consecutive years.
Underneath those numbers: a six-year stretch during which the engineering organization ran a multi-billion-dollar daily transaction platform for thousands of registered investment advisors, executed one of the largest wealth-management integrations in industry history without losing the asset base it was migrating, and did it with a team that did not burn out.
What made it work
Three patterns separated this program from the integrations that fail.
The first was treating advisor experience as the unit of work, not engineering features. Every backlog item was scored against its impact on an advisor’s daily operations. Engineering velocity was not the goal. Stability under advisor workflow was.
The second was sequencing for retention before sequencing for ease. Migrating the largest accounts first absorbed more engineering complexity early but eliminated the risk of competitor poaching during the long tail of the program.
The third was running financial and program discipline as a single function. The Chief of Staff role and the engineering ownership were not separate jobs. Treating them as one prevented the common failure mode of engineering scope creeping past financial constraints, or finance forcing engineering shortcuts that show up as production issues two years later.
What is portable
Most companies will never run a $50M integration of a $350B advisor business. The asymmetric risk framing transfers anyway. Anywhere the cost of disruption is higher than the cost of caution, the engineering execution model has to be built to absorb caution as part of the cadence, not bolted on as a separate quality gate.
The retention pattern transfers too. A program that consumes its team is not a successful program. It is a successful first phase of a longer failure.