Sequencing an MDM migration around the systems that depend on it

1. Dependency data

   ~500K claims-gateway calls a day; ~50K digital; 100K+ eligibility
2. Consequence

   Source-by-source migration delivers no benefit until complete
3. Proposal

   Critical consumers first, then sources with request routing
4. Decision

   Leadership agreed; I owned it across both platforms
5. Scale

   1M+ claims, 8M+ customers, 20,000+ calls served by the new services

Product workflow, shown through the decisions and handoffs.

The decision

Integrate the critical consumers first (digital, eligibility, the provider portal, the claims gateway), then migrate sources behind request routing so each consumer moved when it was ready. Leadership agreed and put me in charge of the initiative across both platforms. The migration began with seven critical systems plus a request-routing program.

The new services were sized to support more than a million claims, eight million customers and more than twenty thousand customer calls. The same evidence-first stance carried through the platform: a master identifier service created about 4 million unique IDs used across IVR, digital and customer service, and a demanded proof of concept on streaming throughput turned an assumed six claims a second into a measured one, before the design was fixed.

The claims work happened inside a larger job. At a healthcare platform business I led product work across master data, enrollment, claims and policy capabilities. The scope expanded across teams and portfolios, with operating-budget responsibility and a funding case I had to make.

You do not lead multiple teams by attending every stand-up. We ran the Scaled Agile Framework: program-increment planning every quarter, features prioritised by weighted shortest job first, and an explicit balance between enabler work — the platform investment nobody sees — and business-value features the sponsors could point at. I have earned SAFe product-owner/manager credentials, and I still believe its central idea: that the plan is a negotiation between capacity and value, made visible.

The platform used Reltio for master data. When leadership proposed a source-by-source migration, I disagreed and brought dependency evidence: the business capabilities relying on that information, the consequences of interruption and the readiness of their consumers. The sequencing changed to protect dependent capabilities. I was asked to lead both platforms.

We modernized enrollment with Kafka. Before launch, a performance problem led to a focused investigation with engineering; the team found avoidable repeated processing and improved it. I also worked on a digital member migration and reverse-engineered Medicare deductible logic for an accumulator application. Those projects connected platform behavior with usable access and customer-service needs.

And the people. I hired early-career engineers from a development program and supported their growth. When a direct report was caught between competing outage-window requests, I took the escalation and helped secure a workable alternative. Leading a platform is mostly making sure the people who build it can.

Tools in this chapter Reltio MDM · Kafka · Teradata · SQL · Java / XML / XSD · Jira Align · SAFe PI planning · WSJF · Tableau · Salesforce integration

Bring the dependency with its business consequence. A plan is easier to change when the argument is a number every leader in the room can check.

From my original account

I directed the transaction data platform at Evernorth: a 14-person product team that grew to 14 scrum teams after a reorganization, an $18M operating budget across 15 products and 4 portfolios, and $24M in annual funding I secured for the following year. After the acquisition the decision was to keep one master-data platform. Merging the legacy customer book-of-record into it was hard because of how many sources fed it and how many systems read from it.

The disagreement

Leadership wanted to migrate source by source. I pulled the consumption data: the claims gateway called the legacy system about 500,000 times a day for member validation, the digital platform about 50,000 times for authentication, and provider eligibility transactions exceeded 100,000. A source-by-source migration would deliver no benefit to any of them until it was entirely complete, and would carry the full risk the whole way.