Move field teams from Veeva CRM, OCE, or Health Cloud to Salesforce Life Sciences Cloud without a big-bang cutover — put System APIs in front of the old and new CRM, run both side by side by country wave, cleanse and reconcile data through Informatica on the way across, and roll a wave back by repointing an API rather than restoring a database.
Tags: life-sciences, life-sciences-cloud, pharma, medtech, salesforce, veeva, migration, informatica, api-led, crm
Veeva CRM to Life Sciences Cloud Migration: Abstract, Coexist, and Repoint by Wave
Objective: Replace a pharma or MedTech CRM with Life Sciences Cloud one country or business unit at a time, while every downstream system keeps working. The trick is to stop downstream systems talking to the CRM directly: once they call a System API, which CRM sits behind it becomes a configuration choice per country, and a cutover or rollback becomes a repoint rather than a rebuild.
What's Getting Built
- Legacy CRM (System API) — wraps Veeva CRM, OCE, or Health Cloud accounts, calls, and samples behind a CRM-neutral contract ·
GET /accounts, GET /calls, GET /samples/transactions
- LSC CRM (System API) — the same contract implemented against Life Sciences Cloud Account, HealthcareProvider, Visit, and ProviderSample objects ·
GET /accounts, POST /visits, POST /samples/transactions
- CRM routing (Process API) — reads the wave configuration and sends each call to the legacy or LSC System API by country and business unit ·
GET /routing/{country}, PUT /routing/{country}
- Migration and reconciliation (Process API) — extracts a wave, cleanses it through Informatica, loads LSC, and reports record-level differences ·
POST /waves/{waveId}/extract, POST /waves/{waveId}/load, GET /waves/{waveId}/reconciliation
- Delta sync during coexistence (Scheduler) — keeps shared master data in step across both CRMs until the last wave moves ·
SCHEDULER every 15 min, PUBLISH crm.record-changed
Value chain phase
Phase 06 — Commercial & Patient Services. Marketing to healthcare providers (HCPs) and patient support program delivery.
- Scope of this plan: Moving the commercial CRM to Life Sciences Cloud by wave, with coexistence and rollback built into the integration layer.
- Data in this phase: CRM (Veeva / Salesforce Life Sciences Cloud), prescription data, and logs.
- Receives from: Phase 05 — Supply Chain & Logistics.
- Hands off to: Nothing downstream — this phase closes the loop back to Research & Discovery with real-world evidence.
Prerequisites
- Anypoint Platform org with API Manager, Runtime Manager, and a non-production deployment target.
- Salesforce Life Sciences Cloud org with a connected app and an integration user scoped to the objects this plan writes.
- Secrets Manager or secure properties configured for every system credential.
- Named owner for each source system — integration stalls on access, not on code.
- API access to the legacy CRM — Veeva CRM, OCE, or Health Cloud — for every object in scope.
- Informatica Cloud Data Integration or MDM for cleansing, deduplication, and reconciliation.
- A wave plan agreed with the business: which countries or business units move, in what order, and the go/no-go criteria for each.
- An inventory of every system that reads from or writes to the legacy CRM today, including file drops.
Choose your path
- Wave by country — Choose when countries run on different processes or data rules — each wave proves one country end to end before the next moves.
- Wave by business unit — Choose when one global process spans countries — each wave moves a franchise or therapy area across every market at once.
Platform notes
Veeva CRM
- Expect country variants in the data model — custom fields, picklists, and call types differ by market, so map per country rather than once globally.
- Freeze configuration changes in the legacy org for a wave once its extract starts, or reconciliation chases a moving target.
Life Sciences Cloud
- Providers land as Account plus HealthcareProvider; visits, samples, and engagement have their own objects — build the System API against those, not against a re-creation of the legacy model.
- Use Bulk API 2.0 for wave loads and keep the REST API for coexistence deltas.
Informatica
- Run cleansing and match before the load, not after — the migration is the cheapest moment to fix duplicates.
- Keep the legacy-to-LSC ID map as a governed crosswalk; reconciliation and rollback both depend on it.
Architecture
1. Abstract the CRM
- Define one CRM-neutral contract for accounts, providers, visits, samples, and consent, and implement it twice — once over the legacy CRM, once over LSC.
- Move every downstream consumer onto the contract before the first wave. A system still calling Veeva directly is a system that breaks at cutover.
- Keep country variants in configuration — field maps and picklist translations per country — not in branching DataWeave.
2. Coexist
- Route each call by country and business unit from a routing table the program team can change without a deployment.
- Sync shared master data in both directions only where both CRMs must see it; everything else stays one-way to LSC.
- Tag every record with its system of record during coexistence, so a write never lands in the CRM that no longer owns it.
3. Migrate a wave
- Extract the wave from the legacy CRM, cleanse and match it through Informatica, and load LSC with Bulk API 2.0.
- Reconcile at record level — counts alone hide the dropped affiliation or the call with no account.
- Hold the load if reconciliation breaks the agreed tolerance; a wave that moves dirty data is harder to fix than one that waits.
4. Cut over and roll back
- Cutover is a routing change: point the wave's countries at the LSC System API and stop the legacy delta for them.
- Rollback is the same change in reverse, provided legacy writes were replayed for the coexistence window.
- Retire the legacy System API only after the last wave has run a full business cycle on LSC.
5. Security, privacy, and data integrity
- Validate the integration under GAMP 5 — requirements, design, IQ/OQ/PQ evidence, and a traceability matrix retained for inspection.
- Meet 21 CFR Part 11 and EU Annex 11 for electronic records and signatures on every GxP-relevant flow.
- Preserve ALCOA+ data integrity — attributable, legible, contemporaneous, original, and accurate — with audit trails no operator can edit.
- Encrypt regulated data in transit and at rest, and keep production payload visibility to validated support roles only.
- Treat a mapping change on a GxP flow as a controlled change under change management, never as a hotfix.
- Keep consent and data-processing basis intact through the migration — a record that loses its consent flags must not be contactable in LSC.
- Retain migration and reconciliation evidence per wave for audit.
For pre-built API specifications, implementation templates, and reference architecture, see the MuleSoft Accelerator for Life Sciences on Anypoint Exchange.
Sample payload — Wave routing entry
{
"country": "DE",
"businessUnit": "oncology",
"systemOfRecord": "lsc",
"cutoverAt": "2026-11-11T06:00:00Z",
"rollbackTarget": "veeva-crm",
"legacyDeltaStopped": true
}
Testing and validation
- Flip a test country between legacy and LSC and confirm every downstream consumer keeps working with no code change.
- Load a wave with known duplicates and confirm Informatica merges them before LSC sees them.
- Run reconciliation against a deliberately dropped affiliation and confirm it is reported by record, not just by count.
- Roll a wave back and confirm writes made in LSC during the window are replayed to the legacy CRM.
Phased rollout
Phase 1 — Connect
- Build both System APIs against the neutral contract and move downstream consumers onto it.
- Stand up the routing table with every country pointing at the legacy CRM.
Phase 2 — Map and validate
- Run a pilot wave for one small country through extract, cleanse, load, and reconcile.
- Rehearse cutover and rollback in a full-copy sandbox before the pilot goes live.
Phase 3 — Production
- Move waves in the agreed order, with go/no-go on reconciliation results.
- Retire the legacy System API and delta sync once the last wave has run a full cycle.
Success metrics
- Downstream systems calling the CRM directly, falling to zero before wave 1.
- Reconciliation variance per wave inside the agreed tolerance.
- Rollback rehearsed and timed for every wave.
- Field downtime per wave measured in hours rather than days.
Troubleshooting
- A downstream report breaks at cutover — Likely cause: it still read the legacy CRM directly and was missed in the inventory. Fix: Move it onto the System API contract and add a check that flags direct legacy calls during coexistence.
- Records appear in both CRMs with different values — Likely cause: a two-way sync on an object only one CRM should own. Fix: Make the object one-way and enforce the system-of-record tag on every write.
- Country picklists fail to load in LSC — Likely cause: a country variant mapped with the global value set. Fix: Map picklist values per country in configuration and validate them before the wave extract.
Deliverable: A CRM-neutral System API layer over the legacy CRM and Life Sciences Cloud, a routing table that moves or rolls back a wave without a deployment, and a cleanse-and-reconcile pipeline with evidence per wave.