Veeva CRM Data Migration Checklist: What to Inventory, Clean and Prove

The short version: a Veeva CRM migration is mostly an inventory problem, and the data move is only finished when the numbers reconcile. Support for Veeva CRM on Salesforce ends on 31 December 2029, and every team running it has to move its data somewhere. This checklist is written for teams moving to Salesforce Life Sciences Cloud, but most of it applies just as well if you are heading to Vault CRM.

If you have not yet decided where to go, start with our guide to choosing between Vault CRM and Salesforce Life Sciences Cloud. The first step below is the same either way.

Key Takeaways

• Inventory before you map. Most of the effort sits in what your team built on top of the Veeva package, not in the package itself.
• Decide what history moves, what gets archived and who can still read the archive, before anyone writes a load script.
• Load in dependency order: accounts before addresses and affiliations, calls before the records that hang off them.
• Reconcile every object back to the source by count, and spot-check real records, before sign-off.
• If any records sit in a validated process, plan the validation evidence at the start.

1. Inventory what you have

You cannot plan a move until you know what is in the house. Walk the org and list:

The core Veeva data. Veeva’s own documentation describes the main objects. The ones most teams rely on are:

What it holds	Veeva object
Healthcare professionals and organisations	Account (person and business accounts)
Addresses for each account	Address_vod
Relationships between HCPs and HCOs	Child_Account_vod
Territory-specific account fields	TSF_vod
Calls, planned and submitted	Call2_vod
What was detailed, discussed and shown on each call	Call2_Detail_vod, Call2_Discussion_vod, Call2_Key_Message_vod
Samples and expenses recorded on calls	Call2_Sample_vod, Call2_Expense_vod
Sample lot numbers	Sample_Lot_vod

Add consent records, product catalog, events and medical inquiries if you use them.

What your team built. Custom objects and fields, Apex classes and triggers, flows, validation rules, page layouts, and any Lightning components. None of this moves on its own, whichever destination you pick.

What is connected. Reference data feeds for HCP and HCO records, your ERP, data warehouse, marketing tools, and anything that reads from or writes to the org. Each one needs a new connection or a decision to retire it.

What people actually use. Reports and dashboards with recent usage, and fields that are filled in versus fields nobody touches. The inventory is the cheapest point to leave things behind.

Who and where. Users, profiles, territories and alignments. Territory structure often changes more than anything else in a migration, so capture it as it is today.

2. Decide what moves

Not everything should make the trip.

• Active records (current HCPs, open alignments, recent calls) move.
• History is a choice. Decide how many years of call history the field team genuinely needs in the new system, and archive the rest somewhere it can still be read.
• Regulated records follow your retention rules, not your preferences. Ask your compliance team which records must be kept, for how long, and in what form, before you decide anything about samples or consent.
• Name the owner of the archive. An archive nobody can open, or nobody is responsible for, is a finding waiting to happen.

3. Map, object by object

Build a mapping sheet: every source object and field, where it lands in Life Sciences Cloud, and any transformation on the way. Two rules keep this honest:

• Do not assume matching names mean matching meaning. Read how each field is actually used before you map it.
• Write down every field you are deliberately not moving, and why. It saves a long argument six months after go-live.

4. Clean before you move

Moving dirty data just gives you dirty data on a new platform.

• Merge duplicate HCP and HCO records.
• Close out inactive accounts and addresses nobody has used in years.
• Fix orphaned records, such as addresses or affiliations pointing at accounts that no longer exist.
• Agree the cleanup rules with the business first, because every merge is a decision someone has to stand behind.

5. Load in dependency order

Parents before children, always. Veeva’s own loading guidance starts with accounts and then addresses, and call data spans several related objects. A typical order:

1. Reference data: products and sample lots
2. Accounts: HCPs and HCOs
3. Addresses
4. Affiliations between accounts
5. Territory and alignment data
6. Calls
7. Call details, discussions, key messages, samples and expenses
8. Consent and anything else that references the records above

Run the full load in a sandbox first, time it, and fix what breaks. A load order that only works on the second try in production is a cutover risk.

6. Reconcile, then reconcile again

A load job that reports success tells you it finished, not that it was right.

• Count every object in the source and the target, and explain every difference.
• Spot-check real records end to end: pick a handful of HCPs and follow each one through its addresses, affiliations, calls and samples.
• Check totals that matter, such as sample quantities by lot, not just record counts.
• Get sign-off from the business, not just the migration team.

We hold ourselves to this. On a recent client migration we published the numbers: 177 of 177 records reconciled against the source with zero mismatches before sign-off.

7. Validated records

If sample records, consent or anything else sits inside a validated process, plan the validation evidence at the start: requirements, test scripts, results and approvals. It adds steps, and they do not compress. Our guide to Salesforce validation and 21 CFR Part 11 covers what that involves.

8. Cutover

• Pick a window away from launches, national sales meetings and quarter-end.
• Freeze changes in the old system, then run a final delta load for anything created since the last full load.
• Keep the old system readable for a set period, so nobody is cut off from history they expected to have.
• Write a rollback plan, even if you never use it.

9. After go-live

• Train the field team on the new system before go-live, not after.
• Support users closely for the first few weeks.
• Retire the old integrations, confirm the archive works, and close out the Veeva org on a date you set, well before 31 December 2029.

The checklist on one page

Stage	Done when
Inventory	Veeva data, custom build, integrations, usage and territories are all listed
Decide	Every data set is marked move, archive or leave, with an owner for the archive
Map	Every source field has a target or a written reason it is not moving
Clean	Duplicates merged and cleanup rules agreed with the business
Load	The full load runs cleanly in a sandbox, in dependency order
Reconcile	Counts match per object, spot checks pass, business signs off
Validate	Validation evidence is complete where it applies
Cutover	Delta load done, old system read-only, rollback plan written
After go-live	Users trained, archive confirmed, old org retired

Sources

• Veeva CRM Help, Data Loading in CRM
• Veeva, More than 125 customers worldwide live on Vault CRM (3 March 2026), end-of-support date moved to December 2029

---

Estarei helps biotech and medtech teams move off Veeva CRM and onto Salesforce Life Sciences Cloud. If you want a second pair of eyes on your inventory, talk to us.