Switching from Salesforce to Velastria - CRM and enquiry migration

The problem isn't Salesforce. It's the gap beside it.

Salesforce is a genuinely capable CRM, and clinics that adopt it usually do so because their practice-management system's CRM was not good enough. That works — right up to the point where you want to answer an ordinary question: of the people who enquired about a procedure last year, how many had a consultation, how many went to surgery, and what did that cost us per enquiry?

Answering that means joining two systems that were never designed to be joined, usually by hand, usually in a spreadsheet, usually monthly. Meanwhile you are paying for Salesforce per seat, paying a consultant to maintain it, and your reception team is typing the same person's details into two places. Velastria holds the enquiry and the patient as the same record, so the question answers itself.

What we moved, and how long it took

A surgical group's live Salesforce org, mapped object by object and field by field before a line of import code was written, then migrated in a single overnight run. Start to finish, under 24 hours.

People and enquiries

18,960 CRM leads landing on 11,182 new enquirer records — because 7,945 of them turned out to be people the clinic already held, and were reconciled rather than duplicated.

Attribution that survived

13,086 leads arrived with a normalised procedure interest and 3,844 with their Google Ads attribution intact — so the clinic can follow an advert through to the procedure it produced, on day one.

Pipeline and commercials

Opportunities with their pipeline stages preserved verbatim, campaigns flattened onto the lead, and insurance policies and authorisation codes mapped to real records rather than notes.

The reason it runs in a night rather than a fortnight is that the hard part happens first: the org is mapped and the matching is settled before anything is created. The import itself is then mechanical.

And every enquiry kept its own date. The migrated history spans March 2024 to the day of the switch, because each lead carries the date it was actually created — not the date it was imported. That sounds obvious; it is one of the most common ways a migration quietly destroys the thing you migrated it for. A CRM where every enquiry happened on the same Tuesday cannot tell you anything about your marketing.

Three things a Salesforce migration gets wrong

These are findings from mapping a real clinic org. All three are invisible to a standard export, and any one of them quietly ruins the result.

Most of your activity history is archived out of sight. A normal Salesforce query returned 82,397 tasks on the last org we mapped. The true figure, including archived activity, was 213,090 — 61% of the history is invisible unless you know to ask for it. A migration that queries the ordinary way will move a third of your call and contact history and report complete success.
Your leads and your patients are the same people, twice. Clinics on Salesforce typically hold an enquirer as a Lead and the same person, after conversion, as a Person Account. Import both without reconciling them and you create thousands of duplicate patients. On the last org we moved, 7,945 of the leads were people the clinic already held — every one of them a duplicate patient with half a history, had we not matched them first. Getting this right is a matching problem that has to be solved before anything else is created.
Clinics on Salesforce hold patients as Person Accounts, not Contacts. It is an unusual configuration that most generic migration tooling does not expect, and tooling that assumes Contacts will find a few hundred records where there are several thousand people.

Your opt-outs come with you

On the last org we mapped, 2,177 people had opted out of email and 22 were marked do-not-call. Those preferences are not a nice-to-have detail of a CRM migration — they are the difference between a lawful marketing list and a regulatory problem, and they are exactly the sort of flag a field-by-field export tends to drop.

Contact preferences are carried across explicitly and checked after import. And as with every migration we run, no patient or enquirer receives any communication about any aspect of the import — enforced structurally, so that imported records stay invisible to automated campaigns and follow-up sequences rather than relying on someone remembering to pause them.

How the migration works

We connect to your org read-only and map it. Object by object, field by field, against your real data — so you find out what is actually populated rather than what the schema suggests. Most "fully populated" custom fields turn out to be formulas, not data.
We produce a match report before writing anything. It answers the question everything else depends on: how many of these people do you already hold in your clinical system? That report writes nothing and commits you to nothing.
De-duplication runs before any linking. Enquirers who never progressed, people who did, and their converted enquiry history are handled as three separate passes in a fixed order, because doing it any other way is what creates the duplicate-patient problem.
The import runs in one pass, usually overnight. Because the mapping and matching are settled in advance, the run itself is mechanical — the last one completed in under 24 hours from starting to finishing.
Then we keep syncing until you're ready to stop. After the snapshot you review it in Velastria, and we pull the changes since — repeatedly and cheaply — until you stop writing to Salesforce. You are never forced to drop it on a particular day.
You sign the migration report. What transferred, what didn't, and why. You sign it; then, and only then, billing starts.

Frequently Asked Questions

How long does it take?

The mapping and match report take days, because that is where the care is needed. The import itself runs in a single pass — the last one moved a full clinic CRM, 18,960 leads across 19,127 people, in under 24 hours. Your team is not waiting on it, because it happens behind you while you carry on working.

Do we have to stop using Salesforce on day one?

No, and we would advise against it. We take a snapshot, you review it in Velastria, and then we pull the delta — everything created or changed since — as often as you like until you are ready to stop. Catching up a month of activity takes minutes, so there is no cliff edge.

What about our custom fields and objects?

They are read and assessed individually. Anything with a proper home in Velastria is mapped to it; anything without one is kept verbatim on the migration ledger against the record it belongs to, so it is never lost and can be mapped later once you have decided what it should become.

Salesforce doesn't hold dates of birth. Is that a problem?

It's a known gap rather than a surprise — clinic Salesforce orgs generally don't carry a date of birth, so matching against your clinical system has to be done on other identifiers. We tell you the match rate before anything is created, not after.

Will our marketing attribution survive?

Yes. Campaign membership, lead source and Google Ads attribution come across and feed Velastria's own reporting, so you can follow an enquiry from the advert that produced it through to the procedure it became.

We use Salesforce alongside a clinical system.

That is the common case, and it is the one this is designed for. We migrate both and reconcile the two populations into single people, using whatever identifier your systems already share. You end up with one record per person instead of two halves — which is exactly what we did on the last one, alongside a full Clinic Office migration.

Switching from Salesforce