for Pharma
Toggle menu
Answers · Pharma operations

How do you replace a commercial pharma data vendor without breaking reporting?

Take the work over feed by feed, not on a cutover date. Inventory the feeds and the reports people read, confirm you own the code, credentials, and cloud account, put tests on each feed before you change it, then run old and new side by side until the numbers reconcile. The incumbent's run stays your rollback until each feed passes.

Chris Bergh Published

Key points

  • A vendor replacement needs no cutover date: the incumbent keeps running while feeds move one at a time, so there is no single day when everything has to work.
  • Put tests on each feed before changing anything, so you can prove a change did not move a number. A suite that passes on the incumbent's output is the baseline the new pipeline has to match.
  • At one rare-disease biotech, in a DataKitchen case published August 2026, 41 reports had already been cut to 10 before the switch, and the customer's own estimate was that about eight mattered. Inventory what people read before you rebuild anything.
  • The same rare-disease biotech moved two vendors' commercial data work to one in 30 days of planning plus an 11-week fixed-price implementation, covering everything from the vendor SFTP drop to the reports.
  • A matching row count does not prove a migration. In DataKitchen's October 2026 Table Comparison test on a Jaffle Shop migration, a 55-test health-check suite passed after 483 orders were dropped, while a 345-test Table Comparison suite caught it.

The rare-disease biotech in our Cadillac and Corolla story had two vendors, 41 reports, and 150 data quality checks. By the time anyone looked closely, the reports were down to 10, about 20 checks were still switched on, and one report showed an email open rate of 181% that nobody had flagged.

That’s the operation you inherit. Reporting is already partly broken, and the people reading it have stopped noticing. A replacement that just copies it moves the problems.

No cutover date

The safest switch has no switch day.

The incumbent keeps running while the new team takes feeds over one at a time, so there is no single day when everything has to work. Each feed gets its own small cutover, its own reconciliation, and its own rollback.

The cut-data-costs page calls the phases Assess, Take over, Run leaner, and Ready. The steps below are the Take over phase in detail.

The steps, and what done means

StepWhat you doDone when
1. InventoryList every feed, its cadence, and every report, with who reads itEach report maps to its feeds, and an owner has said whether it’s used
2. Ownership checkConfirm the warehouse is in your cloud account, the code in your repo, and you hold the SFTP and source credentialsYou could rebuild from raw without calling the incumbent
3. Tests firstPut freshness, volume, schema, and value tests on each feed before changing itThe suite passes on the incumbent’s current output
4. Parallel runBuild the new pipeline for one feed; run bothBoth produce the same gold tables on the same input
5. ReconcileRow counts and sums against the vendor control record; diff against the last snapshot; compare old and new outputEvery difference traces to a planned change
6. AcceptAgree criteria with the report owners before the run startsOwners sign off on that feed
7. Switch, keep rollbackPoint reports at the new output; leave the old run live for a period you agreeThe old run is retired

Steps assembled from DataKitchen’s published takeover approach. The “done when” column is an illustrative standard, not a contract term.

Inventory what’s read, not what exists

In that biotech’s case the customer’s own estimate was that about eight of the 41 screens mattered. The prior vendors had already cut the set to 10, and nobody missed the other 31. Rebuilding them is cost with no reader.

So the inventory has two columns, not one: what exists and what someone opens. The second is the scope.

Tests before changes

Coverage goes on the feeds first, so you can prove a change didn’t move a number. Without that baseline, every discrepancy after the switch turns into an argument about whose number was right. With it, a discrepancy is a failed test with a row behind it.

The feeds most likely to fight you are the ones you didn’t create: specialty pharmacy, claims, and syndicated data. That biotech’s specialty pharmacy sent four files a day and was its single biggest source of trouble. Test those first.

Reconcile with more than a row count

Two checks catch the usual breaks. Count rows and sum amounts against the vendor’s control record, so partial files stop in staging. Then diff each period against the snapshot you kept, which catches a restatement that reads as growth.

For the old-versus-new comparison itself, a row count lies. In DataKitchen’s Table Comparison testing, a 55-test health-check suite passed with zero failures after 483 orders were dropped. The 345-test comparison suite failed 61 times, and every failure matched a planned change. The same approach works across engines, and the migration answer for small teams covers setup.

Rollback you don’t have to plan twice

Keep the incumbent’s run live for each feed until it passes acceptance. Then rollback is a pointer change.

Underneath, FITT architecture does the rest. Raw data stays exactly as it arrived. Jobs are idempotent, so a failed load reruns without duplicate rows. Two stages mean there’s no chain of intermediate tables to unwind.

That biotech’s issue log recorded 30 data issues in 2024, from May when the log opens, and 43 in 2025 under the prior vendors, seven still open on handover day. As of the August 2026 write-up, it had recorded none since. The files didn’t get cleaner. The bad ones stop at a test now.

Follow-up questions

Frequently asked questions

Do we have to rebuild our platform to change vendors?

Usually not. Your warehouse stays in your cloud account, your dashboards keep working, and the new team changes what feeds them. At one rare-disease biotech, at most 40% of a two-year-old warehouse could be reused for a second indication, so some rebuilding was justified there. Ask the incoming team to name each rebuild and the reason during the assessment.

Can a new data team work alongside our current vendor?

Yes, and it is the normal case. On the BMS CAR-T warehouse, 41 contributors from five companies, including Beghou and Accenture, worked the same codebase over seven years. That works when tests are the contract, so a newcomer's change either passes or fails loudly instead of quietly breaking someone else's report.

How long does a commercial data vendor transition take?

One documented case took 30 days of planning followed by an 11-week fixed-price implementation. A rare-disease biotech moved ingestion, the warehouse, transformations, datamarts, reports, credentials, and daily triage from two vendors to one. The annual cost of running that commercial data then fell by about 58%, measured against the 10 reports still in use.

How do we know the new pipeline matches the old one?

Reconcile, then compare. Count rows and sum amounts against each vendor's control record, diff each period against the snapshot you kept, and run the same tests on old and new output. DataOps TestGen's Table Comparison tests profile the source and check the target against it; in one test they caught 483 dropped orders a 55-test health check passed.

What is the rollback plan if a feed breaks after the switch?

Keep the incumbent's run for that feed live until the new one passes acceptance, so switching back is a configuration change, not a project. Underneath, a FITT architecture keeps raw data exactly as it arrived, and idempotent jobs can rerun without double-counting, so a bad load gets fixed and reloaded rather than unpicked.

Talk to the team that tests this data every week.

Half an hour on your stack, your launch window, and what the first sprint would look like.